Harness Pipelines

Harness pipelines for the Galaxy Workflow Foundry. Each named pipeline phase corresponds to one atomic, harness-step-sized Mold. The union of phases is not the Mold set: leaf Molds invoked inside an orchestrator are independently castable without appearing as a phase. content/molds/ is the membership; molds owns the axes and the boundary.

Framing

A harness is hand-authored orchestration glue. Harnesses sequence Molds, manage user-approval gates, and maintain run state. They are not cast from Molds and live outside the Foundry’s casting pipeline. Some harnesses are heavyweight (Archon-style); some are simple orchestration skills.
Each phase below is intended to be a Mold — atomic, cast from the Foundry, LLM-driven content, reusable across harnesses where the phase recurs.
“atomic” means atomic relative to harness pipeline phases, not necessarily small. summarize-nextflow and implement-tool-step are both atomic at this tier even though they differ in LOC.

Translation and lifecycle pipelines

The original Pipelines are translation pipelines: their names and tags identify a source shape and a target workflow system, such as NEXTFLOW → GALAXY. They produce a workflow in the target format, so source/* and target/* are the relevant browse facets.

Some journeys instead operate on an existing workflow after construction. These are lifecycle pipelines. Use lifecycle/* to classify their purpose:

lifecycle/review — evaluate an existing workflow or submission and emit advisory findings;
lifecycle/publication — mature, package, and hand an existing workflow to a publication destination.

The lifecycle facet is orthogonal to source and target. A Galaxy workflow review can carry source/galaxy + lifecycle/review; a Galaxy publication journey can carry source/galaxy + target/galaxy + lifecycle/publication when it preserves Galaxy as the workflow system. Lifecycle tags classify the journey’s purpose. They do not change Mold source: / target: frontmatter, redefine the cast target, or move harness-level state and external mutations into Molds.

CWL as intermediate (one option, not the path)

CWL is unofficially positioned as a low-level, high-structure interchange format — suitable as an intermediate target between an unstructured/loosely-structured source (a paper, a Nextflow pipeline) and Galaxy. The Foundry must support both direct and composed paths as first-class options:

PAPER → GALAXY (direct), INTERVIEW → GALAXY (interview-normalized direct Galaxy path), and PAPER → CWL → GALAXY (composed) are valid.
NEXTFLOW → GALAXY (direct) and NEXTFLOW → CWL → GALAXY (composed) are both valid.
Direct paths are simpler to run and debug. Composed paths buy a structured checkpoint (CWL) at the cost of running two harnesses.
Whether composition is reliable enough to prefer over direct is a longer-term research question. For now: both paths must be possible from the Mold inventory; the harness picks.

Mold-inventory parity. Structured source summarizers emit per-source schemas (NF, CWL each different by design). Paper and interview sources now converge on a shared freeform-summary Markdown handoff before source-target design. Interface and data-flow handoffs are source-target Molds that produce reviewable Markdown design briefs rather than rich workflow schemas. This avoids pushing all polymorphism into one target Mold while keeping direct/composed pipelines explicit.

Harness-level concerns (not Molds)

Some recurring pipeline activities are harness-level, not Mold-shaped, and are therefore not in the Mold inventory. They are listed here so the boundary is visible.

Approval gates / scope confirmation / plan presentation. Whether and when to pause for user confirmation (after planning, before authoring, after a partial cast) is a property of the harness’s autonomy posture, not of any individual Mold. Different harnesses (interactive vs. batch vs. fully autonomous) want different gates around the same Molds; baking gates into Molds would either constrain that or duplicate logic. Harnesses own gates.
Tool-discovery routing. “Try discover-shed-tool (find an existing wrapper via the Tool Shed); if nothing acceptable, fall through to author-galaxy-tool-wrapper” is a routing decision the harness makes; the two underlying capabilities are clean Molds. (discover-shed-tool is named for the mechanism — the Galaxy Tool Shed — leaving room for siblings like discover-tool-via-galaxy-api or discover-tool-on-github if other discovery paths get wrapped.)
State and resumption. Persisting harness state across phases, resuming a partial run, and managing run history are harness concerns.
Feedback-mode lifecycle. When --feedback is enabled, the harness initializes the registered feedback ledger from its complete _assembly.json phase roster and owns run/phase status transitions. Skills preserve that state and append only observations. An empty ledger counts as a clean run only after the harness marks the run complete.

Runtime tooling

The Foundry distinguishes:

Design time: gxwf — workflow validation, tool discovery, schema, conversion. Used by Molds that author or validate workflow content.
Run time: Planemo — executes Galaxy and CWL workflows. Used by run-workflow-test, debug-galaxy-workflow-output, debug-cwl-workflow-output.

Validation posture: schema, not caveats

gxwf provides static schema validation for gxformat2 workflows and tool steps that catches the failure modes prior-art skills (e.g., the existing nf-to-galaxy skill in SKILLS_NF.md) had to enumerate as prose caveats — UUID validity, tool-ID/owner/+galaxyN suffix mismatches, input_connections parameter-name mismatches, conditional-selector branches in tool_state, etc. The Foundry does not maintain a parallel “caveat catalog” of these failure modes; gxwf’s schema is the source of truth and the validation loop is the enforcement mechanism.

This shifts the per-step loop from “author and hope” to author → validate → fix with validation running inline after each step is implemented, not only as a terminal phase. For Galaxy paths the orchestrator Mold advance-galaxy-draft-step owns one full iteration end-to-end (pick next drafty step → resolve a wrapper → summarize → implement → gxwf draft-validate --concrete); CWL paths keep validate-cwl inline inside the per-step loop.

Orchestrator-as-contract: per-step loop body

Galaxy-targeting pipelines below use a single orchestrator Mold (advance-galaxy-draft-step) as the per-step loop body. The orchestrator owns the loop oracle (gxwf draft-next-step), the discover-or-author routing, the per-iteration sequencing of leaf Molds (summarize-galaxy-tool, implement-galaxy-tool-step), and the per-step validator (gxwf draft-validate --concrete). The harness loop reduces to while draft: invoke skill.

Leaf Molds (discover-shed-tool, author-galaxy-tool-wrapper, summarize-galaxy-tool, implement-galaxy-tool-step) stay independently castable for ad-hoc invocation but no longer appear as pipeline phases. CWL-targeting pipelines retain the leaf-shaped per-step body until a parallel orchestrator emerges (see Tracked Follow-Up).

Pipelines

Each pipeline is presented as an ordered list of phases. Phases marked [loop] run once per step in the workflow being constructed. Phases marked [branch] are harness-level routing — binary branches with fallthrough, or N-step fallback chains. They are not Molds; they reference Molds. The discover-or-author branch in Galaxy-targeting per-step loops is [branch] routing between two underlying capabilities.

Other inline phase annotations may be coined as needs surface — e.g., [gate] for an approval / scope-confirmation checkpoint that pauses for user input. None appear inline in the pipelines below today, so we don’t pre-enumerate. [branch] and [gate] are unrelated behaviors; they don’t share an umbrella tag.

PAPER → GALAXY

summarize-paper — extract methods, named tools/algorithms, sample data, metrics, references to existing pipelines; emit freeform-summary.
freeform-summary-to-galaxy-interface — Galaxy workflow interface design brief.
freeform-summary-to-galaxy-data-flow — Galaxy abstract data-flow design brief from the summary plus interface brief.
compare-against-iwc-exemplar — structural diff of the design briefs against nearest IWC exemplar(s); guidance feeds template authoring.
freeform-summary-to-galaxy-template — gxformat2 skeleton with per-step TODOs from free-form source evidence, the interface and data-flow briefs, and exemplar comparison notes.
[loop] advance-galaxy-draft-step — one full iteration: pick next drafty step via gxwf draft-next-step, route through the discover-or-author branch (try discover-shed-tool, fall through to author-galaxy-tool-wrapper), summarize the wrapper, implement the step, validate via gxwf draft-validate --concrete. Loop terminates on draft: false.
[branch] test-data resolution chain: try paper-to-test-data → on failure, find-test-data → on failure, harness gates to user-supplied data.
implement-galaxy-workflow-test — assemble test fixtures and assertions.
validate-galaxy-workflow — terminal schema/lint pass on the assembled workflow.
run-workflow-test — execute via Planemo.
debug-galaxy-workflow-output — triage failures, propose fixes.

PAPER → CWL

summarize-paper
freeform-summary-to-cwl-design
summary-to-cwl-template — CWL Workflow skeleton with per-step TODOs from source evidence and prior handoffs.
[loop] summarize-cwl-tool — derive a CommandLineTool description for each candidate (container, baseCommand, inputs/outputs).
[loop] implement-cwl-tool-step — concrete CommandLineTool and Workflow step.
[loop] validate-cwl — schema-validate the just-implemented step; on red, the harness loops back to (5).
[branch] test-data resolution chain: try paper-to-test-data → on failure, find-test-data → on failure, harness gates to user-supplied data.
implement-cwl-workflow-test
validate-cwl — terminal cwltool --validate / schema lint.
run-workflow-test — execute via Planemo.
debug-cwl-workflow-output — triage failures, propose fixes.

NEXTFLOW → CWL

summarize-nextflow — enumerate processes, channels, conditionals, containers, test data; emit a structured summary (NF-specific schema).
nextflow-summary-to-cwl-interface
nextflow-summary-to-cwl-data-flow
summary-to-cwl-template
[loop] summarize-cwl-tool
[loop] implement-cwl-tool-step
[loop] validate-cwl — inline schema validation per step; loop back on red.
nextflow-test-to-cwl-test-plan — translate NF test data and expectations into a CWL workflow test plan.
validate-cwl — terminal pass on the assembled workflow.
run-workflow-test — execute via Planemo.
debug-cwl-workflow-output

NEXTFLOW → GALAXY

summarize-nextflow
nextflow-summary-to-galaxy-reference-data — decide Galaxy-side shape of external reference data (iGenomes key, per-asset, compute-if-missing) before interface and data-flow choices pin workflow inputs.
nextflow-summary-to-galaxy-interface
nextflow-summary-to-galaxy-data-flow
compare-against-iwc-exemplar — structural diff of the design briefs against nearest IWC exemplar(s); guidance feeds template authoring.
nextflow-summary-to-galaxy-template
[loop] advance-galaxy-draft-step — one full iteration (pick → discover-or-author → summarize → implement → gxwf draft-validate --concrete). Loop terminates on draft: false.
[branch] test-data resolution chain: try nextflow-to-test-data → on failure, find-test-data → on failure, harness gates to user-supplied data.
nextflow-test-to-galaxy-test-plan — translate NF test data and expectations into a Galaxy workflow test plan.
implement-galaxy-workflow-test — assemble test fixtures and assertions from the translated test plan.
validate-galaxy-workflow — terminal pass on the assembled workflow.
run-workflow-test — execute via Planemo.
debug-galaxy-workflow-output

CWL → GALAXY

CWL is already structured; the upstream extraction work is much lighter.

summarize-cwl — read CWL Workflow + referenced CommandLineTools, identify inputs/outputs, scatter, conditional logic.
cwl-summary-to-galaxy-interface — choose Galaxy workflow interface from CWL inputs/outputs.
cwl-summary-to-galaxy-data-flow — re-shape into Galaxy-shaped data-flow idioms from a CWL summary that’s already nearly a DAG.
compare-against-iwc-exemplar — structural diff of the design briefs against nearest IWC exemplar(s); guidance feeds template authoring.
cwl-summary-to-galaxy-template
[loop] advance-galaxy-draft-step — one full iteration (pick → discover-or-author → summarize → implement → gxwf draft-validate --concrete). Loop terminates on draft: false.
[branch] test-data resolution chain: try cwl-to-test-data → on failure, find-test-data → on failure, harness gates to user-supplied data.
cwl-test-to-galaxy-test-plan — translate CWL test fixtures into a Galaxy workflow test plan.
implement-galaxy-workflow-test — assemble test fixtures and assertions from the translated test plan.
validate-galaxy-workflow — terminal pass on the assembled workflow.
run-workflow-test — execute via Planemo.
debug-galaxy-workflow-output

INTERVIEW → GALAXY

The interview path is a Galaxy-targeting pipeline, named to match the other → GALAXY pipelines. Unlike them it starts from workflow intent gathered in an interview rather than an existing technical artifact, normalized into the shared freeform-summary handoff.

interview-to-freeform-summary — normalize a user interview transcript or interactive session into the shared freeform-summary handoff.
freeform-summary-to-galaxy-interface
freeform-summary-to-galaxy-data-flow
compare-against-iwc-exemplar
freeform-summary-to-galaxy-template
[loop] advance-galaxy-draft-step — one full iteration (pick → discover-or-author → summarize → implement → gxwf draft-validate --concrete). Loop terminates on draft: false.
[branch] test-data resolution chain: try find-test-data → on failure, harness gates to user-supplied data.
implement-galaxy-workflow-test
validate-galaxy-workflow
run-workflow-test
debug-galaxy-workflow-output

UPDATE-INTERVIEW → GALAXY

The Foundry’s first GALAXY → GALAXY (edit) pipeline: it consumes an existing Galaxy gxformat2 workflow and modifies it according to interview intent, rather than generating one from a non-Galaxy source. The workflow is both an input and the output. The approach is diff-and-patch: the workflow enters already concrete, untouched regions stay byte-stable, and only the regions the change-set names change. Its key reuse insight — an edit is a drafty region — lets it inject tool-introducing edits as drafty steps and drain them with the existing per-step loop, so it needs only four new Molds: three front-half plus a dedicated test-plan producer for the tail.

summarize-galaxy-workflow — read the existing workflow (convert .ga → gxformat2 first if needed), emit a structured summary-galaxy-workflow that anchors the interview.
interview-to-galaxy-workflow-changeset — turn the interview into a reviewable, step-anchored change-set (the human approval gate).
apply-galaxy-workflow-changeset — apply the change-set to the concrete workflow: direct edits inline, tool-introducing/replacing edits injected as drafty steps; emit a galaxy-workflow-draft.
[loop] advance-galaxy-draft-step — drains any injected drafty steps and extracts the concrete workflow. A change-set of purely direct edits leaves the draft concrete, so the loop is a no-op.
changeset-to-galaxy-test-plan — carry the existing tests (the regression baseline captured in the phase-1 summary) forward and augment them for the change-set’s behavioral deltas, emitting the galaxy-test-plan.
implement-galaxy-workflow-test — author the final tests from that plan.
validate-galaxy-workflow
run-workflow-test — runs the carried-forward tests as the regression check.
debug-galaxy-workflow-output

summarize-galaxy-workflow also serves compare-against-iwc-exemplar, which previously lacked a structured view of the exemplar it diffs against — closing the Galaxy-as-source summarizer gap tracked in content/research/gxy-sketches-alignment/index.md §5.

Test-plan handoff: like every Galaxy-targeting pipeline, this one places a dedicated *-to-galaxy-test-plan producer before implement-galaxy-workflow-test. The update case gets its own — changeset-to-galaxy-test-plan — rather than reusing the freeform one, because its inputs and semantics are update-specific: it carries the existing workflow’s tests forward as a regression baseline (source.derived_from: mixed) and only augments for the change-set’s deltas, where the freeform Mold synthesizes a plan from scratch. test-data-refs come from the baseline’s existing fixtures, with find-test-data reached only when a change-set-added input needs new data.

GALAXY WORKFLOW MATURATION

The Foundry’s first lifecycle/publication journey, and the first pipeline whose change driver is a published policy checklist rather than user intent or a source workflow. An existing Galaxy workflow enters, the pinned IWC contributor and reviewer checklist is applied to it, and the matured result is validated and run before a human reads it. The workflow is both input and output, as in UPDATE-INTERVIEW → GALAXY — but the change driver is a published checklist rather than an interview, so the name carries no source-to-target arrow. IWC-Lab is a publication profile and destination, not a workflow target format.

summarize-galaxy-workflow — read the existing workflow (convert .ga → gxformat2 first if needed) and emit the normalized substrate plus a summary-galaxy-workflow the checklist pass can cite instead of re-deriving.
mature-galaxy-workflow-for-iwc — walk the pinned IWC checklist item by item, apply the evidence-supported corrections, keep the workflow and its test labels aligned, prepare the ordinary IWC companions, and emit an iwc-maturation-report recording what passed, what changed, and what still needs a human decision.
validate-galaxy-workflow — terminal structural validation of the matured workflow, because checklist edits rename interface labels and promote hard-coded values into inputs.
run-workflow-test — run the updated test. A red result is retained evidence attributed back to the checklist edit that likely caused it, never a reason to weaken the test.

Entry is deliberately an existing workflow rather than a construction run: a workflow that never came from a Foundry pipeline is a first-class input, and a prior workflow-test-result is optional enrichment that turns a red phase-4 into a named regression rather than a first observation.

Two contract gaps are open. Phases 3 and 4 declare no input_artifacts, so nothing in the artifact graph binds them to phase 2’s output — the binding is a harness_notes obligation judged by the pipeline’s eval.md. And galaxyproject/foundry#491 is adding a result artifact to validate-galaxy-workflow, which narrows the evidence gap without closing the binding one.

GALAXY WORKFLOW REVIEW

The Foundry’s first lifecycle/review journey, and the first pipeline whose output is a report rather than a workflow. An existing Galaxy workflow — normally the subject of a pull request — is summarized, structurally validated, and actually run, and only then reviewed against the pinned upstream IWC review command. The name carries no source-to-target arrow because review emits advisory findings, not a new workflow format.

summarize-galaxy-workflow — normalize the descriptor and inventory the interface, steps, labels, and existing tests, so the reviewer cites a summary instead of re-extracting one.
validate-galaxy-workflow — terminal structural validation, now emitting a citable galaxy-workflow-validation-result handoff rather than leaving its findings as prose.
run-workflow-test — execute the test via Planemo and hand on an honest result, including the test-definition-missing and not-run states that keep a review possible when nothing could run.
review-galaxy-workflow — apply the pinned IWC policy item by item, citing the preceding evidence wherever it answers a checklist question, and emit one advisory recommendation.

Only phase 4 is new. The three ahead of it already produced exactly the evidence a review needs, and the two small additive changes to phases 2 and 3 close different gaps. validate-galaxy-workflow declared no artifacts at all, so its change is what makes its findings citable rather than merely spoken. run-workflow-test already emitted its result; its change is about honesty, adding the test-definition-missing and not-run states so a run that could not execute hands on that fact instead of nothing.

Two harness-owned gates sit ahead of phase 3, and both stop the run rather than degrading it: the local worktree commit must equal the reviewed head SHA, and the caller must explicitly confirm the checkout is trusted for Planemo execution. There is no privileged hosted execution of arbitrary fork heads in v1. A red phase 2 or phase 3, by contrast, does not stop the journey — losing the review because the evidence was bad would discard the finding a reviewer most needs.

The pipeline is read-only end to end. It cannot approve, comment, push, mark ready, or merge, and it cannot edit the workflow it reviews. An accepted edit belongs to the maturation harness proposed in galaxyproject/foundry#492, not to this journey, and is routed through apply-galaxy-workflow-changeset where applicable.

Cross-pipeline observations

Source-specific (one per source): summarize-paper, interview-to-freeform-summary, summarize-nextflow, summarize-cwl, summarize-galaxy-workflow. Paper and interview share the freeform-summary handoff; Nextflow, CWL, and Galaxy-as-source keep structured source-specific schemas (summarize-galaxy-workflow reads an existing Galaxy workflow for the edit pipeline).
Edit-in-place (Galaxy → Galaxy): interview-to-galaxy-workflow-changeset (interview → reviewable change-set anchored to existing steps), apply-galaxy-workflow-changeset (change-set → galaxy-workflow-draft, direct edits inline, tool edits as drafty steps), and changeset-to-galaxy-test-plan (existing tests carried forward as a regression baseline + change-set deltas → galaxy-test-plan). Downstream reuses the per-step loop and test/validate/run tail unchanged.
Source × target interface/data-flow: nextflow-summary-to-galaxy-interface, nextflow-summary-to-galaxy-data-flow, cwl-summary-to-galaxy-interface, cwl-summary-to-galaxy-data-flow, freeform-summary-to-galaxy-interface, freeform-summary-to-galaxy-data-flow, nextflow-summary-to-cwl-interface, nextflow-summary-to-cwl-data-flow. The free-form Galaxy path is split to match the Nextflow/CWL pairs; the CWL target keeps a combined freeform-summary-to-cwl-design Mold until free-form examples justify a split.
Source × target template generation (Galaxy): nextflow-summary-to-galaxy-template, cwl-summary-to-galaxy-template, freeform-summary-to-galaxy-template. Each consumes its source-specific or freeform design briefs.
Target-specific (one per target):
- Templates: summary-to-cwl-template.
- Per-step orchestrator (Galaxy): advance-galaxy-draft-step — single entry in Galaxy pipelines’ per-step loop; internally sequences the leaves below.
- Per-step leaves (Galaxy, no longer pipeline phases but still independently castable): discover-shed-tool, summarize-galaxy-tool, author-galaxy-tool-wrapper, implement-galaxy-tool-step.
- Per-step (CWL): summarize-cwl-tool, implement-cwl-tool-step.
- Validate: validate-galaxy-workflow, validate-cwl. (Per-step Galaxy validation moved into advance-galaxy-draft-step via gxwf draft-validate --concrete.)
- Debug: debug-galaxy-workflow-output, debug-cwl-workflow-output.
Lifecycle (post-construction): GALAXY WORKFLOW MATURATION and GALAXY WORKFLOW REVIEW each needed exactly one new Mold — summarize-galaxy-workflow plus the validate/run tail are reused unchanged in both. Maturation adds a corrective pass (mature-galaxy-workflow-for-iwc, landed by #496) and runs the tail afterwards, to check its own edits; review adds a Mold that only reads (review-galaxy-workflow) and runs the tail first, as evidence producers. A lifecycle pipeline needs no new spine; it needs one action and a reason to run the existing tail on one side of it.
Cross-target (Planemo-backed): run-workflow-test.
Source × target (test-plan translation): nextflow-test-to-galaxy-test-plan, cwl-test-to-galaxy-test-plan, nextflow-test-to-cwl-test-plan. These produce reviewable test plans, not final test artifacts.
Test data extraction (source-specific, target-agnostic): paper-to-test-data derives fixtures from a paper-origin freeform-summary; nextflow-to-test-data and cwl-to-test-data resolve the source’s own declared fixtures (test_candidates[].inputs[] / tests[]) into test-data-refs. Each is the first leg of its pipeline’s test-data-resolution chain, falling through to find-test-data (search) then user-supplied data. Interview starts skip directly to find-test-data / user-supplied data until a real interview-specific fixture derivation Mold exists.

Pattern pages, not Molds

Per the architecture, the design-* knowledge skills (collection manipulation, tabular manipulation, conditional handling, …) are Foundry pattern pages, not Molds. They are wiki-linked from action Molds (especially implement-galaxy-tool-step and the source-specific Galaxy template Molds) and pulled into generated skills via casting’s link resolution.

Custom-Galaxy-tool authoring is split: a pattern page (reference and guidance) plus a companion action Mold (author-galaxy-tool-wrapper) that performs the authoring. The Mold links to the pattern page; the pattern page is consumed by the generated skill via link resolution.

Tracked Follow-Up

Composed paths (PAPER -> CWL -> GALAXY, NEXTFLOW -> CWL -> GALAXY) reuse the existing Mold inventory. Track whether they become distinct pipeline notes or remain runtime compositions in issue #200.
Whether the CWL per-step loop should collapse into a parallel advance-cwl-draft-step orchestrator (mirroring Galaxy’s advance-galaxy-draft-step) is open — wait for evidence from Galaxy orchestrator walkthroughs before extending the pattern.