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; on that terminal call the Mold 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
- Pick. Run draft-next-step. If
draft: false, the loop is done: 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.
- Resolve a wrapper. First 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.
- Summarize the wrapper. Invoke summarize-galaxy-tool on the resolved wrapper to produce a galaxy-tool-summary for the next phase.
- Implement. Invoke implement-galaxy-tool-step with the summary 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, tool_state, and wrapper-determined port names.
- Check computability. Inspect the open-requirements-ledger for a new
open blocking entry implement-galaxy-tool-step appended against this step — a declared output that can’t be computed from its wired inputs. draft-validate cannot catch this: 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 repair (insert a producer/sub-path or honestly narrow the output); it marks the entry resolved, or surrendered when no producer is reachable. Each escalation must strictly reduce the open blocking-entry count, under a hard escalation cap; track both in the ledger’s topology_repair block (increment escalations, append the post-repair open count to open_history, surrender once escalations reaches cap). A surrendered entry stays open and is written into the final draft as a labelled gap rather than fabricated. Then return — the next iteration resumes the loop, realizing any draft-tier steps the repair inserted. With no new blocking entry, continue to validation.
- Validate. Run draft-validate
--concrete over the mutated draft. On green, return; the next iteration starts at step 1. On red, route per the failure-routing rules below.
Failure routing
draft-validate --concrete failures fall into three buckets:
- Local to the just-implemented step (sentinel violation, wrong port name, malformed
tool_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) — flag to the user. The orchestrator does not unwind prior iterations on its own; cross-step rework belongs at the harness level. Open question: at what threshold should this Mold attempt to re-enter implement-galaxy-tool-step for an earlier step versus always escalating?
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.