# RFC Workflow Agent Entry
Use this repo as a neutral workflow pack, not as a harness-specific runner.
## Load order
1. Read `workflow.contract.yaml` first. It is the canonical source for stage order, gates, outputs, role visibility, and the public/evidence split.
2. 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`
3. Read any reusable role briefs under `briefs/`, toolchain guidance under `toolchains/`, and templates needed for the active stage.
4. Select exactly one project pack under `projects/` and read that pack's `README.md` plus its suite, corpus, references, metadata, document briefs, and examples.
5. Run `prompts/translate-workflow-for-harness.md` to map the neutral contract into the active harness's own primitives.
6. 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.