Prompt: Translate Workflow for Harness

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

Before sending this prompt, prepare:

• one selected project pack under projects/
• one concrete target scope for the run
• one dedicated writable run root or harness workspace identifier
• the harness facts and operational startup/load-order guidance listed in AGENTS.md
• any pack-local staged support material under projects/<selected-project>/references/
• verified render/toolchain prerequisites for the selected pack

Required substitutions and context:

• replace <selected-project> with the actual repo-relative pack path you selected
• keep the target scope and run root concrete, not placeholder text
• attach or preload the selected pack and reusable repo materials named below

Expected result and next step:

• this prompt must return a ready-to-run handoff for the selected pack and scope
• keep that handoff in the same thread/session, or paste it above the next prompt, then run prompts/run-selected-project.md

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

Load these operator-provided run facts before planning execution:
- selected project pack under `projects/`
- target scope
- run workspace or run root
- verified render/toolchain prerequisites for the selected pack
- any staged pack-local support material under `projects/<selected-project>/references/`
- the operational startup/load-order guidance in `AGENTS.md`

Load these repo 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>/`
- `AGENTS.md`, treating it as operational startup/load-order guidance to translate into harness-native execution setup

Your job is translation, not redesign.

## First, gather the harness facts you will translate against

State the exact native mechanism this harness will use for each of these:
- controller primitive
- stage execution primitive
- role brief delivery
- gate/checkpoint mechanism
- recursive correction mechanism
- evidence artifact workspace
- public deliverable workspace
- escalation path
- repo-file loading method

If any item is unknown, stop and ask for that fact before claiming the workflow is translated.

## 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.
2a. Translate `AGENTS.md` operational startup/load-order guidance into this harness's own execution model before execution. Treat it as run-shaping guidance, not as something to ignore or copy verbatim without translation.
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.
9a. If this harness needs a native workflow/config object, staged prompt bundle, job graph, or equivalent runtime representation, generate or configure it explicitly before first execution and describe that representation in the handoff.
10. Treat the selected target scope, run root, and verified prerequisite state as required run facts. Do not invent or silently replace them.

## 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,
- `AGENTS.md` operational guidance translated into harness-native startup/execution ordering,
- any native workflow/config artifact or equivalent runtime configuration required before stage execution,
- 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.
If this harness requires a native workflow/config artifact or equivalent runtime configuration before it can run stages, include that generated representation or the exact configuration it must instantiate before the first execution step.
This handoff is required context for `prompts/run-selected-project.md`, so keep it structured enough to paste above that prompt in a fresh thread if needed.
The handoff must name, at minimum:
- selected project pack,
- target scope,
- run workspace or run root,
- evidence workspace path,
- public workspace path,
- verified render/toolchain prerequisites,
- controller primitive,
- stage execution primitive,
- the first execution step,
- any native workflow/config artifact or equivalent runtime configuration required before execution, or an explicit statement that none is needed,
- and the escalation condition that stops the run.

## Short worked example of the expected specificity

This example is illustrative of output shape only. Replace the primitive names and paths with the real harness facts you gathered.

### Example harness facts
- controller primitive: one orchestrator session that can dispatch stage-specific worker prompts
- stage execution primitive: one worker task per contract stage
- role brief delivery: each worker prompt includes repo-relative files to read before acting
- gate/checkpoint: a stage result with `PASS` or `FAIL`, produced artifact paths, and a named root-fault artifact when failing
- recursive correction: the controller re-dispatches the earliest faulty stage, then only the affected downstream stages
- evidence artifact workspace: `<run-root>/evidence/`
- public deliverable workspace: `<run-root>/public/`
- escalation path: the controller stops and emits `BLOCKED` to the operator with the missing fact or contradiction
- repo-file loading method: workers are told which repo files to read in order before writing outputs

### Example translation excerpt
1. Native primitive map
   - controller -> orchestrator session
   - stage execution unit -> worker task
   - gate/checkpoint -> controller-reviewed stage result
   - evidence artifact workspace -> `<run-root>/evidence/`
   - public deliverable workspace -> `<run-root>/public/`
   - recursive correction loop -> targeted re-dispatch from the controller

2. Stage wiring sample
   - `claim-ledger`
     - executor: draft-author worker task
     - reads: `run-brief`, `context-packet`, `source-map`, optional `source-scout-report`
     - writes: `<run-root>/evidence/claim-ledger.md`
     - promotion gate: every claim has authority class, source anchor, status, and public-section impact
     - failure route: if evidence is missing, return to `source-map` or `source-scout`; if evidence exists but claims are malformed, re-run `claim-ledger`

3. Ready-to-run handoff example
   - selected_project_pack: `projects/fossil/`
   - target_scope: `document:delta`
   - run_root: `/tmp/fossil-delta-run`
   - evidence_dir: `/tmp/fossil-delta-run/evidence`
   - public_dir: `/tmp/fossil-delta-run/public`
   - verified_prerequisites: `kramdown-rfc` and `xml2rfc` available
   - controller: orchestrator session
   - stage_execution: worker task per contract stage
   - first_step: load `workflow.contract.yaml`, then `core/`, then required reusable briefs/toolchains/templates, then `projects/fossil/`, then dispatch `scope`
   - escalate_when: a required harness fact is missing, a required source is absent, or any gate returns `FAIL` without a repairable root artifact

## 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.