Map a CWL summary into a Galaxy workflow interface design brief.
/plugin marketplace add galaxyproject/foundry
/plugin install foundry-skills@galaxy-workflow-foundryThen invoke as:
/foundry-skills:cwl-summary-to-galaxy-interfacecodex plugin marketplace add galaxyproject/foundry
codex plugin add foundry-skills@galaxy-workflow-foundryThen select with /skills or invoke explicitly as:
$cwl-summary-to-galaxy-interfaceProduces: 2 artifacts.
Consumes: 2 artifacts.
Reviewable Markdown brief: Galaxy workflow inputs, outputs, labels, exposed and checkpoint outputs, source provenance, confidence.
{
"id": "cwl-galaxy-interface",
"kind": "markdown",
"default_filename": "cwl-galaxy-interface.md",
"description": "Reviewable Markdown brief: Galaxy workflow inputs, outputs, labels, exposed and checkpoint outputs, source provenance, confidence."
}Carried obligations ledger re-emitted by this step: entries it appended or closed updated, every other entry passed through with its provenance intact.
{
"id": "open-requirements-ledger",
"kind": "yaml",
"default_filename": "open-requirements.ledger.yml",
"description": "Carried obligations ledger re-emitted by this step: entries it appended or closed updated, every other entry passed through with its provenance intact."
}Structured CWL summary emitted by [[summarize-cwl]]; the source-of-truth JSON for Galaxy interface choices.
{
"id": "summary-cwl",
"description": "Structured CWL summary emitted by [[summarize-cwl]]; the source-of-truth JSON for Galaxy interface choices.",
"inherited_schema": "[[summary-cwl]]",
"producers": [
"summarize-cwl"
]
}Carried obligations ledger [[open-requirements-ledger]]: the run's open, resolved, and surrendered entries with their provenance. Absent on the first Mold of a run; start an empty one.
{
"id": "open-requirements-ledger",
"description": "Carried obligations ledger [[open-requirements-ledger]]: the run's open, resolved, and surrendered entries with their provenance. Absent on the first Mold of a run; start an empty one.",
"producers": [
"advance-galaxy-draft-step",
"apply-galaxy-workflow-changeset",
"compare-against-iwc-exemplar",
"cwl-summary-to-galaxy-data-flow",
"cwl-summary-to-galaxy-interface",
"cwl-summary-to-galaxy-template",
"freeform-summary-to-galaxy-data-flow",
"freeform-summary-to-galaxy-interface",
"freeform-summary-to-galaxy-template",
"implement-galaxy-tool-step",
"interview-to-galaxy-workflow-changeset",
"nextflow-summary-to-galaxy-data-flow",
"nextflow-summary-to-galaxy-interface",
"nextflow-summary-to-galaxy-reference-data",
"nextflow-summary-to-galaxy-template",
"repair-galaxy-draft-topology"
]
}Keep source-faithful CWL facts separate from Galaxy-facing interface choices.
references/notes/component-cwl-workflow-anatomy.mdcontent/research/component-cwl-workflow-anatomy/index.md---
type: research
title: "CWL workflow anatomy"
tags:
- source/cwl
status: draft
created: 2026-05-10
revised: 2026-05-10
revision: 1
related_notes:
- "[[summary-cwl]]"
- "[[cwl-v1.2-schemas]]"
- "[[galaxy-collection-semantics]]"
related_molds:
- "[[summarize-cwl]]"
- "[[cwl-summary-to-galaxy-interface]]"
- "[[cwl-summary-to-galaxy-data-flow]]"
- "[[cwl-summary-to-galaxy-template]]"
sources:
- "https://www.commonwl.org/v1.2/Workflow.html"
- "https://cwltool.readthedocs.io/en/stable/"
- "https://github.com/common-workflow-language/cwl-utils#normalize-a-cwl-document"
- "https://pypi.org/project/cwl-utils/"
- "https://github.com/common-workflow-language/cwldep"
summary: "CWL structure relevant to summarize-cwl: normalized documents, steps, scatter, conditionals, requirements, and dependency handling."
---
# CWL Workflow Anatomy
CWL is a structured workflow language, not a pipeline framework that must be inferred from ecosystem conventions. The `summarize-cwl` Mold should therefore start from CWL's own validated object model and avoid recreating the heavy Nextflow extraction stack.
## Normalization Posture
Use `cwltool --validate` as the first gate. If validation fails, the summary should emit provenance plus validation diagnostics and stop before producing downstream-looking graph claims.
Use `cwl-normalizer` from `cwl-utils` as the default normalization surface. The cwl-utils README describes it as producing JSON CWL documents with dependencies packed together, upgrading to CWL v1.2 as needed, and optionally refactoring CWL expressions into separate steps. This is the right handoff for `summarize-cwl`: structured enough for extraction, still source-faithful, and not a Galaxy design.
Use `cwl-utils` for structured extraction when implementin
...Inherit open entries rather than re-deriving them, close the ones this brief's input, output, and label decisions settle, and append interface obligations the CWL summary leaves open — an unmapped secondaryFiles bundle, an unpinned parameter default, a collection shape the source types don't determine.
references/notes/open-requirements-ledger.mdcontent/research/open-requirements-ledger/index.md---
type: research
title: "Open-requirements ledger"
tags:
- target/galaxy
status: draft
created: 2026-06-16
revised: 2026-08-29
revision: 3
related_notes:
- "[[galaxy-workflow-draft-format]]"
related_molds:
- "[[advance-galaxy-draft-step]]"
- "[[repair-galaxy-draft-topology]]"
- "[[implement-galaxy-tool-step]]"
summary: "Carried unresolved-requirements artifact the source→Galaxy pipeline discharges or explicitly surrenders, autonomously."
---
# Open-requirements ledger
The `open-requirements-ledger` is a single artifact threaded through the source→Galaxy pipeline that records **obligations the pipeline has taken on but not yet met** — a declared output with no producer, a parameter whose value the source never pinned, a tool with no corpus exemplar — and **source work it decided not to carry**. Each Mold that surfaces one **appends** it; each Mold whose decision closes one **marks it resolved**; the terminal path **surrenders** whatever remains open, explicitly, into the final artifact.
## Framing: obligations the pipeline discharges, not questions a human answers
This is deliberately *not* an "open questions for the user" list. The pipeline is autonomous — no human-in-the-loop gate is assumed. The ledger's consumers are **Molds and the loop's convergence gate**, with human readout a secondary affordance. An entry is closed by a downstream Mold doing work (wiring a producer, picking a wrapper, settling a value), or — when nothing can close it — surrendered: written into the final draft as a known, labelled gap rather than silently dropped or fabricated around.
The distinction matters because a "questions for a human" framing leaks an operator's personal interaction style into a tool meant to run inside anyone's harness. The ledger must behave identically
...Read CWL workflow inputs, outputs, types, formats, secondary files, scatter, and requirement evidence before choosing the Galaxy interface.
references/schemas/summary-cwl.schema.jsonpackage://@galaxy-foundry/foundry#summaryCwlSchema{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "https://galaxyproject.org/foundry/schemas/summary-cwl.schema.json",
"$comment": "Canonical source: packages/foundry/src/schemas/summary-cwl/summary-cwl.schema.json in galaxyproject/foundry. Mold frontmatter cites this schema via [[summary-cwl]] wiki-links; the cast pipeline imports the `summaryCwlSchema` runtime export and serializes it into cast bundles.",
"title": "CWL Workflow Summary",
"description": "Structured per-source summary emitted by the summarize-cwl Mold. CWL is already a typed workflow language, so this schema records validated and normalized workflow/tool structure rather than inferred pipeline semantics.",
"type": "object",
"additionalProperties": false,
"required": [
"summary_version",
"source",
"documents",
"workflow_inputs",
"workflow_outputs",
"steps",
"tools",
"graph",
"tests",
"warnings"
],
"properties": {
"summary_version": {
"type": "string",
"enum": [
"1"
],
"description": "Summary schema major version."
},
"source": {
"$ref": "#/$defs/SourceRecord"
},
"documents": {
"$ref": "#/$defs/DocumentSet"
},
"workflow_inputs": {
"type": "array",
"items": {
"$ref": "#/$defs/WorkflowInput"
}
},
"workflow_outputs": {
"type": "array",
"items": {
"$ref": "#/$defs/WorkflowOutput"
}
},
"steps": {
"type": "array",
"items": {
"$ref": "#/$defs/WorkflowStep"
}
},
"tools": {
"type": "array",
"items": {
"$ref": "#/$defs/CommandLineTool"
}
},
"graph": {
"$ref": "#/$defs/WorkflowGraph"
},
"tests": {
"type": "array",
"items": {
"$ref": "#/$defs/TestCase"
}
},
"warnings": {
"type": "array",
"items": {
"$ref": "#/$defs/Warning"
}
}
},
"$defs": {
"SourceRecord": {
"type": "object",
"additionalProperties": false,
"required": [
"ecosystem",
"workflow",
"url",
"version",
"license",
"slug",
"cwl_version",
"entrypoint"
],
"properties": {
"ecosystem": {
"type": "string",
"enum": [
"cwl"
],
"description":
...Pick among the three honest Galaxy branching translations (paired_or_unpaired input, native pick_value step, sibling workflows) before drafting the interface.
Trigger: When summary-cwl has any steps[].when non-null OR any workflow output uses pickValue.
references/notes/cwl-when-pickvalue-to-galaxy-branching.mdcontent/research/cwl-when-pickvalue-to-galaxy-branching/index.md---
type: research
title: "CWL when:/pickValue → Galaxy branching translation"
tags:
- source/cwl
- target/galaxy
status: draft
created: 2026-05-11
revised: 2026-05-11
revision: 1
related_notes:
- "[[cwl-pickvalue-to-galaxy]]"
- "[[galaxy-paired-or-unpaired-collections]]"
- "[[galaxy-collection-semantics]]"
- "[[component-cwl-workflow-anatomy]]"
- "[[galaxy-data-flow-draft-contract]]"
related_molds:
- "[[cwl-summary-to-galaxy-interface]]"
- "[[cwl-summary-to-galaxy-data-flow]]"
- "[[cwl-summary-to-galaxy-template]]"
- "[[compare-against-iwc-exemplar]]"
summary: "CWL `when:`/`pickValue` → Galaxy. Three honest translations (paired_or_unpaired input, native pick_value step, sibling workflows) plus how to pick among them."
---
# CWL `when:`/`pickValue` → Galaxy branching translation
Audience: a Mold author looking at a `summary-cwl.json` whose steps carry `when:` predicates and/or whose workflow outputs use `pickValue`, deciding which Galaxy translation to recommend.
## The three honest translations
CWL has two related branching mechanisms with no 1:1 gxformat2 equivalent (until galaxy#22222 — see `cwl-pickvalue-to-galaxy`):
- **`when:` on a step** — execute conditionally on a JS predicate.
- **`pickValue:` on a step input or workflow output** — fan in N candidate sources and pick `first_non_null` / `the_only_non_null` / `all_non_null`.
Three Galaxy-idiomatic translations are available; each is honest for a different source shape.
### Translation A — `paired_or_unpaired` collection (preferred when the discriminator is paired-vs-single)
When the CWL `when:` predicates discriminate the **paired-vs-single mode of read inputs** (the seqprep-subwf pattern: `single_reads: File?` triggers single mode; absence triggers paired mode), the entire branchin
...Choose Galaxy collection input shapes from CWL arrays, scatter inputs, records, Directory values, and secondary-file contracts.
Trigger: When CWL types include arrays, records, Directory, secondaryFiles, or scatter over File-like inputs.
references/notes/galaxy-collection-semantics.mdcontent/research/galaxy-collection-semantics/index.md---
type: research
title: "Galaxy collection semantics"
tags:
- target/galaxy
status: draft
created: 2026-04-30
revised: 2026-05-05
revision: 3
license: MIT
license_file: LICENSES/galaxy.LICENSE
related_notes:
- "[[galaxy-xsd]]"
- "[[galaxy-collection-tools]]"
- "[[galaxy-apply-rules-dsl]]"
- "[[nextflow-to-galaxy-channel-shape-mapping]]"
- "[[nextflow-operators-to-galaxy-collection-recipes]]"
- "[[galaxy-tool-job-failure-reference]]"
- "[[galaxy-workflow-invocation-failure-reference]]"
- "[[iwc-transformations-survey]]"
- "[[galaxy-discover-datasets]]"
sources:
- "https://github.com/galaxyproject/galaxy/blob/7765fae934fbfdee77e3be5f5b235e43735273ae/lib/galaxy/model/dataset_collections/types/collection_semantics.yml"
companions:
- "galaxy-collection-semantics.yml"
summary: "Vendored formal spec of Galaxy dataset-collection mapping/reduction semantics, with labeled examples and pinned test references."
---
> **Vendored from upstream**, pinned at SHA `7765fae`. One file travels with this note:
>
> - `galaxy-collection-semantics.yml` — the structured source. **Agents and casting should consume this.** It carries the `tests:` blocks that pin concrete Galaxy test names; the rendered upstream view drops them.
>
> The Foundry also vendors Galaxy's auto-generated MyST/LaTeX rendering of the same YAML, which
> is what the human view below renders from. It is a site asset: casting does not carry it, so
> do not look for it beside this note in a skill bundle. Sync is manual.
>
> **When to consult:** authoring or reasoning about Molds and patterns that touch `data_collection` inputs, map-over / reduction shape changes, sub-collection mapping, `paired_or_unpaired`, or `sample_sheet`.
```vendored-myst
file: galaxy-collection-semantics.upstream.myst
source: h
...Choose Galaxy collection input shapes from CWL arrays, scatter inputs, records, Directory values, and secondary-file contracts.
Trigger: When CWL types include arrays, records, Directory, secondaryFiles, or scatter over File-like inputs.
references/notes/galaxy-collection-semantics.ymlcontent/research/galaxy-collection-semantics/galaxy-collection-semantics.yml- doc: |
# Collection Semantics
This document describes the semantics around working with Galaxy dataset collections.
In particular it describes how they operate within Galaxy tools and workflows.
:::{admonition} You Probably Don't Need to Read This
:class: caution
Any significantly sophisticated workflow language will have ways to collect data
into arrays or vectors or dictionaries and apply operations across this data (mapping)
or reduce the dimensionality of this data (reductions). Typically, this is explicitly
annotated with map functions or for loops. Galaxy however is designed to be a point
and click interface for connecting steps and running tools. It is important that steps
just connect and just do the most natural thing - and this is what Galaxy does.
This document just provides a mathematical formalism to that "what should just
intuitively work" that can be used to document test cases and help with implementation.
This is reference documentation not user documentation, Galaxy should just work.
:::
## Mapping
If a tool consumes a simple dataset parameter and produces a simple dataset parameter,
then any collection type may be "mapped over" the data input to that tool. The result of
that is the tool being applied to each element of the collection and "implicit collections"
being created from the outputs that are produced from those operations. Those implicit
collections have the same element identifiers in the same order as the input collection that is
mapped over. Each element of the implicit collections correspond to their own job and
Galaxy very naturally and intuitively parallelizes jobs without extra work from the user
and without any knowledge of the tool.
...Choose `paired_or_unpaired` (or `list:paired_or_unpaired`) shape when the CWL discriminator is paired-vs-single reads, instead of inventing a workflow-level `reads_mode` select parameter.
Trigger: When summary-cwl declares 2+ optional File? read-like inputs whose step bindings are gated by complementary `when:` predicates, OR workflow outputs use pickValue over branches keyed on input presence, OR an upstream `meta.single_end`-style discriminator surfaces in the summary.
references/notes/galaxy-paired-or-unpaired-collections.mdcontent/research/galaxy-paired-or-unpaired-collections/index.md---
type: research
title: "Galaxy paired_or_unpaired collection type"
tags:
- target/galaxy
status: draft
created: 2026-05-11
revised: 2026-05-11
revision: 1
related_notes:
- "[[galaxy-collection-semantics]]"
- "[[component-cwl-workflow-anatomy]]"
related_molds:
- "[[cwl-summary-to-galaxy-interface]]"
- "[[cwl-summary-to-galaxy-data-flow]]"
- "[[nextflow-summary-to-galaxy-interface]]"
summary: "Galaxy's `paired_or_unpaired` collection type: discriminated-union shape for paired-or-single reads, no workflow-level mode switch needed. Galaxy PR #19377."
---
# Galaxy `paired_or_unpaired` collections
Audience: a Mold author shaping a Galaxy workflow interface from an upstream (CWL / Nextflow / paper) source whose reads can be paired-end *or* single-end *or* a mixed batch of both.
## The shape
`paired_or_unpaired` is a Galaxy collection type modeling a **discriminated union of 1 or 2 elements**:
- **Unpaired variant** — one element with identifier `unpaired`.
- **Paired variant** — two elements with identifiers `forward` and `reverse`.
`list:paired_or_unpaired` lifts the same shape to a *heterogeneous* batch where some samples are paired and some are single-end — a representation that did not exist before this type. A `list:paired` forces every sample to be paired; a plain `list` of flat datasets loses pairing structure.
The type and rank `paired_or_unpaired` may occur at any rank within nested types (`list:paired_or_unpaired`, `list:list:paired_or_unpaired`) but **only at the deepest (innermost) rank** — the subtyping logic is implemented at the suffix level. See "Limitation: only deepest rank" below.
## When to reach for it (decision rule for translators)
Reach for `paired_or_unpaired` when the upstream workflow declares **either** of:
1. Two or more op
...Choose stable Galaxy workflow input/output labels and promoted checkpoint outputs.
Trigger: When deciding labels, public outputs, checkpoint outputs, or fixture-compatible collection inputs.
references/notes/galaxy-workflow-testability-design.mdcontent/research/galaxy-workflow-testability-design/index.md---
type: research
tags:
- target/galaxy
status: draft
created: 2026-05-03
revised: 2026-05-06
revision: 2
related_notes:
- "[[iwc-workflow-testability-survey]]"
- "[[iwc-test-data-conventions]]"
- "[[planemo-asserts-idioms]]"
- "[[iwc-shortcuts-anti-patterns]]"
- "[[planemo-workflow-test-architecture]]"
- "[[implement-galaxy-workflow-test]]"
- "[[gxformat2-schema]]"
- "[[gxformat2-workflow-inputs]]"
- "[[galaxy-datatypes-conf]]"
summary: "Design guidance for Galaxy workflow inputs, outputs, and checkpoints that make IWC-style workflow tests possible."
---
# Galaxy workflow testability design
Use this note when authoring or translating a Galaxy workflow **before** the `-tests.yml` file exists. It covers workflow structure choices that make later IWC-style tests meaningful: labels, promoted checkpoints, collection identifiers, and fixture-compatible inputs.
This is not a `content/patterns/` page. It is cross-cutting design guidance for Molds that need testable Galaxy workflows. Assertion syntax lives in [[planemo-asserts-idioms]]. Test YAML fixture shapes live in [[iwc-test-data-conventions]]. Accepted shortcut vs smell calls live in [[iwc-shortcuts-anti-patterns]]. Corpus evidence trail lives in [[iwc-workflow-testability-survey]].
## 1. Treat labels as API
Workflow input and output labels are not cosmetic. Planemo and IWC tests address workflow inputs and outputs by label, and the survey found exact label matches for every asserted output across 114 matched workflow/test pairs. A generated workflow should therefore pick stable, descriptive labels before test authoring starts.
Rules:
- Label every output that may need a test assertion.
- Treat input/output renames as breaking changes requiring sibling `-tests.yml` updates.
- Prefer stable doma
...
# cwl-summary-to-galaxy-interface
Follow the procedure below and use the artifact/reference sections as the runtime contract.
## When To Use
- Map a CWL summary into a Galaxy workflow interface design brief.
## Inputs
- Read artifact `summary-cwl`. Schema: summary-cwl. Produced by `summarize-cwl`. Structured CWL summary emitted by summarize-cwl; the source-of-truth JSON for Galaxy interface choices.
- Read artifact `open-requirements-ledger`. Produced by `advance-galaxy-draft-step`, `apply-galaxy-workflow-changeset`, `compare-against-iwc-exemplar`, `cwl-summary-to-galaxy-data-flow`, `cwl-summary-to-galaxy-interface`, `cwl-summary-to-galaxy-template`, `freeform-summary-to-galaxy-data-flow`, `freeform-summary-to-galaxy-interface`, `freeform-summary-to-galaxy-template`, `implement-galaxy-tool-step`, `interview-to-galaxy-workflow-changeset`, `nextflow-summary-to-galaxy-data-flow`, `nextflow-summary-to-galaxy-interface`, `nextflow-summary-to-galaxy-reference-data`, `nextflow-summary-to-galaxy-template`, `repair-galaxy-draft-topology`. Carried obligations ledger open-requirements-ledger: the run's open, resolved, and surrendered entries with their provenance. Absent on the first Mold of a run; start an empty one.
## Outputs
- Write artifact `cwl-galaxy-interface` as `cwl-galaxy-interface.md`. Format: `markdown`. Reviewable Markdown brief: Galaxy workflow inputs, outputs, labels, exposed and checkpoint outputs, source provenance, confidence.
- Write artifact `open-requirements-ledger` as `open-requirements.ledger.yml`. Format: `yaml`. Carried obligations ledger re-emitted by this step: entries it appended or closed updated, every other entry passed through with its provenance intact.
## Required Tools
- None declared. Procedure should not assume external CLIs are present.
## Load Upfront
- `references/notes/component-cwl-workflow-anatomy.md`: Research note copied verbatim into the bundle. Keep source-faithful CWL facts separate from Galaxy-facing interface choices.
- `references/notes/open-requirements-ledger.md`: Research note copied verbatim into the bundle. Inherit open entries rather than re-deriving them, close the ones this brief's input, output, and label decisions settle, and append interface obligations the CWL summary leaves open — an unmapped secondaryFiles bundle, an unpinned parameter default, a collection shape the source types don't determine.
- `references/schemas/summary-cwl.schema.json`: Schema file copied verbatim into the bundle. Read CWL workflow inputs, outputs, types, formats, secondary files, scatter, and requirement evidence before choosing the Galaxy interface.
## Load On Demand
- `references/notes/cwl-when-pickvalue-to-galaxy-branching.md`: Research note copied verbatim into the bundle. Pick among the three honest Galaxy branching translations (paired_or_unpaired input, native pick_value step, sibling workflows) before drafting the interface. Use when: summary-cwl has any steps[].when non-null OR any workflow output uses pickValue.
- `references/notes/galaxy-collection-semantics.md`: Research note copied verbatim into the bundle. Choose Galaxy collection input shapes from CWL arrays, scatter inputs, records, Directory values, and secondary-file contracts. Use when: cWL types include arrays, records, Directory, secondaryFiles, or scatter over File-like inputs.
- `references/notes/galaxy-collection-semantics.yml`: Companion file copied verbatim into the bundle. Sibling of `references/notes/galaxy-collection-semantics.md`; read it where that note directs.
- `references/notes/galaxy-paired-or-unpaired-collections.md`: Research note copied verbatim into the bundle. Choose `paired_or_unpaired` (or `list:paired_or_unpaired`) shape when the CWL discriminator is paired-vs-single reads, instead of inventing a workflow-level `reads_mode` select parameter. Use when: summary-cwl declares 2+ optional File? read-like inputs whose step bindings are gated by complementary `when:` predicates, OR workflow outputs use pickValue over branches keyed on input presence, OR an upstream `meta.single_end`-style discriminator surfaces in the summary.
- `references/notes/galaxy-workflow-testability-design.md`: Research note copied verbatim into the bundle. Choose stable Galaxy workflow input/output labels and promoted checkpoint outputs. Use when: deciding labels, public outputs, checkpoint outputs, or fixture-compatible collection inputs.
## Validation
- None declared.
## Procedure
Read a CWL summary and emit a reviewable Markdown interface brief for a Galaxy workflow. Preserve CWL input/output intent while choosing Galaxy-facing labels, data shapes, exposed outputs, checkpoint outputs, provenance, confidence, and open questions.
The output is a design handoff, not gxformat2 and not a rich workflow schema.
Prefer direct mappings when they are honest: CWL scalar inputs become Galaxy parameter inputs, `File` inputs become dataset inputs, `File[]` plus scatter commonly becomes a `list` collection, and declared formats seed Galaxy datatype choices. Surface `Directory`, records, expression-shaped defaults, and secondary-file-heavy outputs as review notes rather than flattening them silently.
## Feedback Mode
- Feedback mode is off unless the caller explicitly enables `--feedback` or supplies a feedback-ledger path.
- When enabled, read `_feedback.md` before doing the work and use its registered `foundry-feedback.ledger.yml` protocol.
- Preserve harness-owned run and phase state. Append only concrete observations about a canonical Foundry source asset or a related project that this run showed to be at fault; do not put ordinary workflow requirements in this ledger.
- Before reporting completion, make one explicit pass over the work you just did. Do not ask yourself whether anything was unclear — recall what happened: where you guessed at something the instructions should have settled, needed information this bundle does not carry, hit an instruction that contradicted another or contradicted the artifacts in front of you, used a packaged reference that did not cover your case, or did something the procedure never describes.
- Append an entry for each such event that clears the protocol's bar. If none do, append nothing and report `no feedback` explicitly. Silence and a clean pass are not the same thing, and nothing downstream can tell them apart unless you say which one it was.
- Pass the same ledger path to any subagent used for this work, and merge updates serially so one writer cannot overwrite another.
## Runtime Notes
- Do not read Foundry source files at runtime; use only files packaged in this skill bundle and user-supplied artifacts.
- Preserve declared artifact filenames unless the user or harness supplies explicit paths.
- Carry unresolved assumptions into the output artifact instead of silently inventing missing source evidence.