Home Mold

advance-galaxy-draft-step

Advance the gxformat2 draft by one step: pick the next drafty step, resolve a wrapper, implement the step, and validate.

reviewed

Mold health

ok
  • Source layout

    Every file beside index.md is one the mold kind declares.

  • Axis fields

    target-specific fields are coherent.

  • Eval plan

    Abstract oracle: the properties any cast of this Mold must satisfy.

    eval.md declares properties and check type.

    eval.md ↗
  • Scenarios

    Concrete cases bound to fixtures, run against the eval properties.

    scenarios.md declares cases bound to fixtures.

    scenarios.md ↗
  • Typed refs

    12 typed references; 0 resolver issues.

  • On-demand triggers

    All on-demand references describe triggers.

  • Evidence checks

    Hypothesis references include verification.

axis
target-specific
target
galaxy
name
advance-galaxy-draft-step
contract

Reference Loading

Typed references describe what casting consumes, and when the generated skill should load each artifact.

Schema galaxy-workflow-draft

Structured contract copied for validation or lookup.

Purpose
In/out contract: the draft this Mold reads and mutates one step per iteration conforms to [[galaxy-workflow-draft]]. Cast bundles the JSON Schema alongside the [[draft-validate]] CLI checks.
CLI Command draft-next-step

Command reference. Usually cast to a sidecar and loaded only when invoked.

Purpose
Deterministically pick the next drafty step (or report no remaining work). The orchestrator owns the loop oracle so the harness reduces to `while draft: invoke skill`.
Trigger
At the start of every iteration, before any per-step work.
Verify
Cast the skill, run on a multi-step IWC-derived draft, confirm the orchestrator picks one step per call and exits when draft: false.
CLI Command draft-validate

Command reference. Usually cast to a sidecar and loaded only when invoked.

Purpose
Validate the draft and its concrete subset with --concrete --strict-state --json; skipped tool-state checks must fail the gate.
Trigger
After implementing or modifying the chosen step in the draft.
Verify
Cast the skill, exercise on an IWC-derived draft, confirm both draft-contract diagnostics and concrete-projection diagnostics route back to the step the iteration touched.
CLI Command draft-extract

Command reference. Usually cast to a sidecar and loaded only when invoked.

Purpose
At loop endstate, extract the concrete gxformat2 workflow from the fully-concretized draft — drop drafty steps, strip `_plan_*` fields, promote `class` to `GalaxyWorkflow` — and write it as the runnable `galaxy-workflow.gxwf.yml`.
Trigger
When [[draft-next-step]] reports `draft: false` (no remaining drafty steps).
Verify
Cast the skill, run the loop to endstate on an IWC-derived draft, confirm draft-extract emits a `class: GalaxyWorkflow` file that passes terminal `gxwf validate` with no `_plan_*` fields or drafty steps.
CLI Command add

Command reference. Usually cast to a sidecar and loaded only when invoked.

Purpose
Cache the resolved wrapper for summarization and validation, using its confirmed tool version.
Trigger
After resolving the wrapper and version, if the shared cache lacks that pin.
Verify
Confirm add caches the resolved pin and draft-validate --concrete --strict-state --json validates its state using the same --cache-dir.
CLI Command list

Command reference. Usually cast to a sidecar and loaded only when invoked.

Purpose
Read a stock tool's cached version when the step plan has no version pin.
Trigger
In step 2, when the chosen step's tool is a bare/stock id and its concrete version isn't already known from a step-plan pin.
Verify
Cast the skill, populate a cache with a stock tool, run list --json, confirm the reported version is what add's --tool-version uses for that bare id.
CLI Command summarize

Command reference. Usually cast to a sidecar and loaded only when invoked.

Purpose
Regenerate the [[galaxy-tool-summary]] for a pin reused from a sibling step, from the populated cache, without re-running discovery.
Trigger
In step 3, when step 2 reused a sibling's `tool_id`/`tool_version` and no summary file for that pin is at hand.
Verify
Cast the skill, reuse a sibling pin on an IWC-derived draft, confirm summarize --output writes a manifest that validates against galaxy-tool-summary.
Schema galaxy-tool-summary

Structured contract copied for validation or lookup.

Purpose
Bind the chosen step against the deterministic tool summary manifest emitted by [[summarize-galaxy-tool]] — read `parsed_tool` for ports/datatypes and `input_schemas.workflow_step_linked` for valid step `state` shape.
Trigger
After a wrapper has been resolved for the chosen step and before implementing it.
Schema parsed-tool

Structured contract copied for validation or lookup.

Purpose
Field-level shape of the `ParsedTool` payload under the summary's `parsed_tool`, which [[galaxy-tool-summary]] leaves as a placeholder: port names, datatypes, and a conditional's `whens[]` (`discriminator`, `is_default_when`) in declaration order.
Trigger
When reading a field of `parsed_tool`, including a conditional's case index or default case.
Research galaxy-tool-job-failure-reference

Background synthesis loaded by explicit progressive-disclosure metadata.

Purpose
Classify [[draft-validate]] diagnostics against wrapper-defined runtime failure semantics so the iteration routes back to the right authoring surface (implementation vs. wrapper choice).
Trigger
When draft-validate fails after a step has been implemented, or when a selected wrapper has explicit failure semantics that may surface at runtime.
Research galaxy-user-tool-workflow-binding

Background synthesis loaded by explicit progressive-disclosure metadata.

Purpose
Pass an authored `GalaxyUserTool` straight to implementation.
Trigger
When step 2 falls through to [[author-galaxy-tool-wrapper]], or when the draft already contains a step whose `run:` is a `GalaxyUserTool`.
Verify
Promote after a loop run reaches `draft: false` with an authored tool embedded, and the extracted workflow imports into Galaxy with the tool resolved.
Research open-requirements-ledger

Background synthesis loaded by explicit progressive-disclosure metadata.

Purpose
Read the ledger for an open blocking entry against the picked step, or any open blocking entry once no drafty step is left, count the open blocking entries the convergence gate reads, and maintain the topology_repair escalation budget the loop's termination guard depends on.
Verify
Promote after a run where a blocking entry appended by implement is detected here and drives an escalation that leaves fewer open blocking entries than it found.

Cast artifacts

  • Claude skill advance-galaxy-draft-step — Advance the gxformat2 draft by one step: pick the next drafty step, resolve a wrapper, implement the step, and validate.

How to install →

Artifact handoffs

/ pipeline contract

Produces

advance-galaxy-draft-step

Orchestrator Mold for the per-step Galaxy authoring loop. One invocation advances the gxformat2 draft by one step: pick → resolve a wrapper → summarize the wrapper → implement the step → validate. The harness loop reduces to while (gxwf draft-next-step <wf>).draft: invoke skill.

This Mold is single-entry, single-exit: it owns the loop oracle (draft-next-step) and the per-step validator (draft-validate --concrete). Iterations terminate when the draft has no remaining drafty steps; the call that leaves no drafty step (or a call that finds none) extracts the concrete galaxy-workflow.gxwf.yml (via draft-extract) — that promoted-class workflow, not the -draft file, is what downstream Molds test and run — and the harness then drops out of the loop and proceeds to terminal validation via validate-galaxy-workflow.

Sequence

Choose a writable tool-cache directory for the run. Pass the same --cache-dir <dir> to cache commands, wrapper summarization, and validation.

  1. Pick. Run draft-next-step. If draft: false, the loop is done: apply step 5 to any open blocking entry, then run draft-extract to emit the concrete galaxy-workflow.gxwf.yml (drafty steps dropped, _plan_* stripped, class promoted to GalaxyWorkflow), then return. Otherwise carry the chosen step id forward. If an open blocking entry against it already records the wrapper as confirmed absent, the author branch as ruled out, or why its wired inputs can’t supply the step, go to step 5. Tool Shed misses and a tool version missing from a cache don’t record that.

  2. Resolve a wrapper. First check for an existing pin:

    • Already resolved in this draft — find a concrete step with the tool_id named by the chosen step’s _plan_* context or identity pin. Reuse its tool_id and tool_version, skipping discover-shed-tool for Tool Shed wrappers or cache/version lookup for stock tools. An embedded user-defined tool has no tool_id: match a sibling whose run: carries the authored definition the plan calls for, by its id and version, and reuse that definition instead of authoring it again. Continue to step 3.

    Otherwise, split on whether the step’s tool is a built-in / stock Galaxy tool — a bare id with no owner/repo path (Filter1, sort1, Cut1, Show beginning1, collection ops, __APPLY_RULES__):

    • Built-in / stock — the bare id is the wrapper identity; it does not route through discover-shed-tool (Tool Shed search) or author-galaxy-tool-wrapper. Only its concrete version needs resolving: the shed serves stock tools by bare id, but its TRS version-list endpoint can’t auto-resolve the version, so read it from a populated cache via galaxy-tool-cache list or take a known pin from the step plan — never hand-guess a stock version. summarize-galaxy-tool then performs the bare-id add/summarize with that explicit --tool-version.

    • Tool Shed wrapper — branch on whether the template already pinned wrapper identity (see the tiers in galaxy-workflow-draft-format):

      • Identity-pinned — tool_id is concrete and tool_version is TODO. Treat the pin as a strong seed: confirm it via discover-shed-tool and resolve the changeset, correcting the tool_id only if discovery contradicts the pin (a pinned id is high-confidence template evidence, not a guess to re-derive from scratch).
      • Deferred — tool_id is TODO. Search fresh: run discover-shed-tool against the step’s _plan_* context.

      Either way, if no acceptable shed candidate emerges, fall through to author-galaxy-tool-wrapper.

    If the resolved pin is absent from the cache, run add <tool_id> --tool-version <v> --cache-dir <dir> before summarization. In @galaxy-tool-util/cli 1.10.0, validation also fetches and caches missing metadata unless --offline is set; offline validation requires a populated cache.

  3. Summarize the wrapper. If step 2 reused a sibling’s pin, reuse that pin’s galaxy-tool-summary: use the file an earlier iteration wrote, or regenerate it from the cache with galaxy-tool-cache summarize <tool_id> --tool-version <v> --cache-dir <dir> --output <file>. If step 2 fell through to author-galaxy-tool-wrapper or reused an embedded definition, skip summarization: the authored galaxy-user-tool.yml is not in any toolbox or cache, and its own inputs and outputs are the port contract. Otherwise, invoke summarize-galaxy-tool to produce the summary.

  4. Implement. Invoke implement-galaxy-tool-step with the summary, or the authored galaxy-user-tool.yml, and the draft. It resolves the chosen step’s remaining TODO_* / _plan_* slots into a concrete tool_id (confirming or correcting any pinned identity), tool_version, state, and wrapper-determined port names. For an authored tool it embeds the definition under the step’s run: instead, as galaxy-user-tool-workflow-binding describes.

  5. Check the ledger. Inspect the open-requirements-ledger for an open blocking entry against this step: one that implement-galaxy-tool-step appended, or one an earlier call or Mold raised. Once no drafty step is left, any open blocking entry counts, including one on a realized step or with no step. draft-validate cannot catch a computability gap: the connection graph knows ports connect, not what they carry, so the draft validates green even though the step can’t run. If such an entry is present, escalate to repair-galaxy-draft-topology for a bounded structural edit, then update the ledger’s topology_repair budget as the ledger note directs — each repair must leave fewer open blocking entries than it found, under a hard cap, and surrender rather than retry once the cap is reached. Then run draft-next-step: if it reports draft: false, the repair removed the last drafty step, so continue at step 6, which validates and extracts. Otherwise return — the next iteration resumes the loop, realizing any draft-tier steps the repair inserted. With no such entry, continue to validation.

  6. Validate. Run draft-validate <draft> --concrete --strict-state --json --cache-dir <dir>. --strict-state makes skipped tool-state checks fail validation; draft structure and topology checks still run. If metadata is unavailable, resolve the cache or fetch error and retry. On exit 0, run draft-next-step again: if it now reports draft: false, no drafty step is left, so apply step 5 to any open blocking entry, then run draft-extract to emit galaxy-workflow.gxwf.yml before returning, because a while draft harness never invokes the skill again. Route other failures using the JSON diagnostics and the rules below.

Failure routing

draft-validate --concrete --strict-state --json failures, after resolving metadata availability, fall into three buckets:

  • Local to the just-implemented step (sentinel violation, wrong port name, malformed state) — re-enter implement-galaxy-tool-step with the diagnostic.
  • Wrapper-choice mismatch (selected wrapper cannot satisfy the step’s _plan_* contract — wrong datatype, missing parameter, incompatible collection shape) — back out to step 2 and pick a different wrapper, either via discover-shed-tool with refined criteria or by escalating to author-galaxy-tool-wrapper.
  • Earlier-step defect surfaced by the growing concrete projection (e.g. a connection that looked fine in isolation breaks once a downstream step pulls a previously-deferred port into scope) — when a structural edit closes it, append a blocking entry naming the defect and escalate as in step 5. Otherwise flag it to the user. The orchestrator does not unwind prior iterations on its own.

These are red-draft-validate buckets. The fourth escalation path — a step output uncomputable from its wired inputs — is not one of them: the draft validates green there, so it is detected from the ledger in step 5 above, not from a validation failure.

Consult galaxy-tool-job-failure-reference when the wrapper has explicit failure semantics that affect routing — strict-shell behavior, dynamic outputs, or non-default stdio rules can present as wrapper-choice mismatches even when the static shape validates.

Why orchestrator-shaped

Prior pipelines expressed the iteration as four entries: a discover-or-author branch plus summarize-galaxy-tool, implement-galaxy-tool-step, and validate-galaxy-step. Collapsing them into one orchestrator keeps the per-iteration narrative — including the discover-or-author branch and the failure-routing rules — in a single procedural surface that the cast skill can render coherently. Leaf Molds stay independently castable for ad-hoc invocation; only the pipeline shape changes.

Incoming References (11)

  • apply-galaxy-workflow-changeset related mold — Apply a reviewed change-set to a concrete Galaxy workflow: untouched regions preserved, tool-introducing edits injected as drafty steps.
  • CWL → GALAXY phase of pipeline — Translate a CWL Workflow into a Galaxy gxformat2 workflow, then assemble and run a Galaxy workflow test.
  • INTERVIEW → GALAXY phase of pipeline — Interview-driven path to a Galaxy gxformat2 workflow through the shared freeform-summary handoff.
  • NEXTFLOW → GALAXY phase of pipeline — Direct path from a Nextflow pipeline to a Galaxy gxformat2 workflow.
  • PAPER → GALAXY phase of pipeline — Direct path from a paper to a Galaxy gxformat2 workflow. No Workflow Brief or CWL intermediate.
  • UPDATE-INTERVIEW → GALAXY phase of pipeline — Interview-driven, edit-in-place modification of an existing Galaxy gxformat2 workflow via a reviewable change-set, reusing the per-step draft loop.
  • WORKFLOW BRIEF → GALAXY phase of pipeline — Consume an expert-reviewed, unchanged Workflow Brief directly through the Galaxy design and implementation chain.
  • Galaxy data-flow draft contract related mold — Defines the proposed boundary between Galaxy data-flow drafts, gxformat2 templates, and concrete step implementation.
  • Binding a workflow step to a user-defined tool related mold — How a workflow step uses an authored GalaxyUserTool: embedded under run:, never by tool_uuid, tool_id or content_id; registering via /api/unprivileged_tools.
  • Galaxy workflow draft format related mold — gxformat2 draft superset: wrapper-tier TODOs (tool_id, state, port names) plus _plan_state / _plan_context / _plan_in / _plan_out per tool step.
  • Open-requirements ledger related mold — Carried workflow-run knowledge artifact for obligations, discoveries, decisions, brief-change recommendations, and convergence state.