Design a Claude dynamic-workflow projection for Foundry Pipelines

> _Posted by Claude (AI assistant) on behalf of @jmchilton — not personally authored._

## Context

PR #307 adds `content/research/component-claude-dynamic-workflows.md`, evaluating Anthropic's dynamic workflows (Claude Code, GA 2026-05-28) as a Foundry harness substrate. Its conclusion: dynamic workflows is the more natural first substrate to pilot, because it natively provides the per-item sub-DAG loop Archon could only fake (the Ralph pattern) and because its `agent({schema})` step handoffs mirror the Foundry's Mold IO schemas.

This issue tracks the **next research step**: how to turn a Foundry Pipeline description into a runnable dynamic workflow script.

## Question

Given a `content/pipelines//` note — its machine-readable `phases:` spine plus the per-Mold `summary`/`loop_endstate` and `harness_notes` — what is the right way to project it into a Claude dynamic workflow JS script (a saved `/` under `.claude/workflows/`, or a new cast/assemble target)?

This is a sibling to the existing `foundry-build assemble-pipeline ` path, which projects the same spine into a lightweight `SKILL.md` harness. A dynamic-workflow assembly would be a second projection of the same source — not a hand-authored script.

## Phase-kind → script mapping to work out

- **Mold-shaped phase** → an `agent()` stage that invokes the Mold's cast (generated skill); typed I/O via `agent({schema})` from the Mold's IO schema.
- **`[loop]` phase** → `while` (Galaxy spine, collapsed to the `advance-galaxy-draft-step` orchestrator) or multi-stage `pipeline()` (CWL spine: `summarize-cwl-tool → implement-cwl-tool-step → validate-cwl`).
- **`[branch]` phase** → native JS `if`/`else` over a schema-validated `agent()` result (e.g. discover-or-author; test-data-resolution chain).
- **`[gate]` phase (reserved)** → **the hard one.** Dynamic workflows forbids mid-run user input — a gate cannot pause a running workflow. It forces splitting the journey into multiple workflows with user sign-off *between* them. Need a design answer for how the spine expresses that boundary.

## Open questions

- Where does this live — a new `foundry-build` subcommand (assemble-dynamic-workflow), a cast target, or a one-off research prototype first?
- How do Mold IO schemas flow into per-stage `agent({schema})` calls at assembly time?
- Casting boundary: agents invoke casts; casting stays outside the workflow (same as Archon). Confirm nothing leaks.
- Drift gate: assemble-pipeline has a byte-diff check (`make check-assemble-pipelines`); a dynamic-workflow projection would need an equivalent.
- Pilot on the CWL spine first — its per-step loop is genuinely multi-stage and exercises `pipeline()` for real (Galaxy's is a plain `while`).

## Suggested deliverable

A research/design note (and possibly a throwaway prototype workflow script for one pipeline) establishing the phase-kind → script mapping, the gate-as-workflow-boundary story, and whether this becomes a real assemble/cast target.

## Refs

- `content/research/component-claude-dynamic-workflows.md` (PR #307)
- `content/research/component-archon.md`
- `docs/HARNESS_PIPELINES.md`, `docs/COMPILATION_PIPELINE.md`
- Existing `assemble-pipeline` skill / `foundry-build assemble-pipeline`