Prompt: Translate Workflow for Harness

Use this prompt when a dynamic workflow harness needs to run this repository without a checked-in adapter.

You are translating a neutral RFC workflow pack into this harness's native primitives.

Load these inputs before planning execution:
- `workflow.contract.yaml`
- the neutral workflow docs under `core/`
- any reusable role briefs under `briefs/`
- any reusable mechanics under `toolchains/`
- any templates needed for active stages
- the selected project pack under `projects/<selected-project>/`

Your job is translation, not redesign.

## Translation rules

1. Treat `workflow.contract.yaml` as authoritative for stage IDs, stage order, entry criteria, outputs, role visibility, backpressure, and the public/evidence split.
2. Preserve workflow semantics exactly. Translate the workflow into native primitives such as jobs, tasks, workers, agents, lanes, or staged prompts, but do not change what the stages mean.
3. Preserve the workflow's evidence discipline: public RFC text is drafted from accepted evidence, not from memory, orientation summaries, or project-pack overview text alone.
4. Preserve the separation between public deliverables and evidence artifacts.
5. Preserve recursive correction: when a gate fails, route the fix to the earliest faulty artifact and then re-run only affected downstream stages.
6. Preserve the late-stage review shape: review lanes, reader-facing gates, clean-room proof, and final packaging remain distinct stages unless the contract explicitly combines them.
7. Do not create repo-local harness adapter files, command stubs, or hidden policy layers unless the operator explicitly asks for them outside this repo.
8. Keep `core/` source-agnostic. Any source-specific behavior belongs only to the selected project pack.
9. If the harness lacks a native primitive the contract expects, emulate it with the smallest explicit mechanism and record that mapping.

## Produce a translation plan with these sections

### 1. Native primitive map
Map each neutral concept to a harness primitive:
- controller
- stage execution unit
- role brief delivery
- gate/checkpoint
- evidence artifact workspace
- public deliverable workspace
- recursive correction loop
- escalation path

### 2. Stage wiring
For each contract stage, state:
- which native primitive will execute it,
- which inputs it reads,
- which outputs it must produce,
- which gate blocks promotion to the next stage,
- and how failures route backward.

### 3. Runtime loading order
State the exact repo load order for this run:
- contract,
- neutral core docs,
- reusable briefs/toolchains/templates needed,
- selected project pack,
- then execution.

### 4. Harness gaps and compensations
List any harness limitation that affects the workflow and the explicit workaround you will use without changing workflow semantics.

### 5. Ready-to-run handoff
End with a concise run handoff that this harness can execute immediately for the selected project pack.

## Translation guardrails

- Do not collapse evidence-building, drafting, review/correction, and clean-room proof into one undifferentiated pass.
- Do not promote project-pack summaries into authoritative technical behavior.
- Do not replace stage gates with best-effort suggestions.
- Do not expose prompts, tool transcripts, internal IDs, or workflow archaeology in public RFC output.
- Do not assume a harness-specific path, command name, plugin, or installation model that is not present in the loaded inputs.