RFC Workflow Agent Entry

Use this repo as a neutral workflow pack, not as a harness-specific runner.

Load order

1. Select exactly one project pack under projects/.
2. Choose the target scope for this run:
   • document:<brief-name>
   • subset:<brief-name>,<brief-name>,...
   • suite:all
3. Choose or create one dedicated writable run root outside this repo for the execution.
4. Verify the selected pack's required render/toolchain prerequisites before translation or execution.
5. Read workflow.contract.yaml first. It is the canonical source for stage order, gates, outputs, role visibility, and the public/evidence split.
6. Read the neutral workflow docs under core/ in this order:
   • core/controller.md
   • core/source-authority.md
   • core/deliverables.md
   • core/style-and-provenance.md
   • core/validation-gates.md
   • core/context-engineering.md
7. Read any reusable role briefs under briefs/, toolchain guidance under toolchains/, and templates needed for the active stage.
8. Read the selected pack's README.md plus its suite, corpus, references.md, draft metadata, document briefs, examples, and any staged support material under projects/<selected-project>/references/ that the run needs.
9. Run prompts/translate-workflow-for-harness.md to map the neutral contract into the active harness's own primitives.
10. Keep the translation output in context as the required run handoff, then run prompts/run-selected-project.md to execute the selected project pack.

Non-negotiable operating rules

• Do not reinterpret workflow semantics during translation. Map names and mechanics into native primitives; preserve the contract.
• Do not draft public RFC prose from memory, orientation notes, or project summaries alone.
• Do not admit public technical or normative claims without accepted evidence according to the workflow contract and source-authority rules.
• Keep public deliverables separate from evidence artifacts.
• Keep provenance, prompts, agent names, tool transcripts, and internal IDs out of public RFC text.
• Keep core/ reusable. Put source-specific material only in the selected project pack.

Harness expectation

A compatible harness should be able to:

• load repo files as instructions,
• allocate native execution units for the contract's roles and stages,
• enforce or emulate stage gates and recursive correction,
• and keep run-local output outside the reusable repo surface.

Harness translation checklist

Before running prompts/translate-workflow-for-harness.md, make the startup facts concrete:

• Selected project pack — one exact repo-relative pack path under projects/.
• Target scope — document:<brief-name>, subset:<brief-name>,..., or suite:all.
• Dedicated run root — one writable run-owned workspace outside the reusable repo surface.
• Verified render/toolchain prerequisites — the selected pack's required render/build mechanics are available before execution starts.
• Pack-local staged source references — if the run needs extra support material, stage it under projects/<selected-project>/references/. Keep references.md as the authoritative curated pack reference note.

Then write down the active harness answers to all of the following:

1. Controller primitive — what native unit acts as the run controller, owns stage order, and decides whether the run advances or recurses.
2. Stage execution primitive — how one workflow stage becomes runnable work in this harness (task, job, worker, agent, prompt, pipeline step, or equivalent).
3. Role/lane + visibility mapping — how contract roles, review lanes, and visibility boundaries map onto native execution units or permissions so the harness does not collapse distinct responsibilities together.
4. Gate/checkpoint mechanism — how the harness blocks advancement until the required artifacts, reviews, or approvals for a stage exist.
5. Recursive correction mechanism — how a failed review or clean-room check routes work back to the earliest faulty artifact/stage instead of patching only the latest draft.
6. Evidence workspace — where internal evidence artifacts live during the run: claim ledgers, notes, review packets, matrices, validation captures, and other non-public outputs.
7. Public-output workspace — where public drafts and final publishable outputs live, separate from the evidence workspace.
8. Escalation path — how blocked workers raise questions or failures to the controller/operator, and how those decisions return to the blocked stage.
9. Repo-file instruction loading — exactly how the harness loads repo files as instructions (ordered file bundle, prompt attachments, injected text, staged context, or similar) so workflow.contract.yaml, core/, reusable materials, and the selected project pack remain authoritative inputs.

If any item above is still vague, stop and resolve it before translation. The translation prompt should receive concrete answers, not placeholders. The translation output must end in a ready-to-run handoff and remain in context for prompts/run-selected-project.md; if you change threads or sessions, paste that handoff above the run prompt.