Use this prompt after the harness has translated the neutral workflow into its own native primitives.
Run the neutral RFC workflow for one selected project pack.
Replace the placeholders below before execution.
Selected project pack: `projects/<selected-project>/`
- Use the exact repo-relative directory under `projects/`, including the trailing slash.
- Example: `projects/fossil/`
- The selected pack must contain its own `README.md` plus the suite/corpus/metadata/reference files and the per-document brief files needed by the chosen scope.
Target scope: <document:<brief-name> | subset:<brief-name>,<brief-name>,... | suite:all>
- `document:<brief-name>` runs one per-document brief. Example: `document:delta`
- `subset:<brief-name>,<brief-name>,...` runs a named subset of per-document briefs. Example: `subset:artifact,delta`
- `suite:all` runs the entire selected pack suite.
- Every `<brief-name>` must match a per-document brief file in `projects/<selected-project>/briefs/` without the `.md` suffix.
Run workspace: <absolute run-root path or harness workspace identifier>
- This must resolve to one dedicated writable run root for this execution, not the repo root and not the project-pack directory.
- The harness may use a logical workspace identifier instead of a filesystem path only if every stage can still read and write stable paths beneath one run root.
- The workspace is run-owned: stages may create, overwrite, and retain artifacts there without polluting the repository.
Expected workspace layout and artifacts:
- `public/` for public deliverables only
- `evidence/` for proof-chain artifacts only
- `gates/` or an equivalent stage-results area for PASS/FAIL records and rerun boundaries
- optional `logs/` for harness-local execution notes that are not public deliverables
- By the end of the run, the workspace must contain:
- in `public/`: the public draft source and rendered public output for each selected document, plus `public-manifest`
- in `evidence/`: `run-brief`, `context-packet`, `source-map`, any `source-scout-report`, `claim-ledger`, `capability-matrix`, `section-map`, `example-report`, `mechanical-report`, `review-report`, `reader-report`, `prose-report`, `cleanroom-packet`, `cleanroom-report`, any `correction-log` or `escalation-log`, and `evidence-manifest`
## Load order
1. Read `workflow.contract.yaml`.
2. Read the neutral workflow docs under `core/`.
3. Read the reusable role briefs, toolchain notes, and templates needed for the selected scope.
4. Read `projects/<selected-project>/README.md` and the selected pack's suite, corpus, references, metadata, document briefs, and examples.
5. Apply the already-prepared harness translation so execution uses native primitives without changing workflow semantics.
## Execution rules
- Follow the contract's stage order and gates.
- Start with scope, corpus, and context loading, not public prose.
- Build evidence artifacts before drafting public RFC text.
- Admit no public technical or normative claim unless it satisfies the contract's evidence and source-authority rules.
- Keep public deliverables separate from evidence artifacts at every stage.
- Use validated examples or explicitly mark examples as illustrative-only in evidence artifacts.
- When a gate fails, repair the earliest faulty artifact first, then re-run only affected downstream stages.
- Keep source-specific behavior inside the selected project pack. Do not push it back into `core/`.
## Minimum stage intent
Execute the contract so the run covers these workflow responsibilities:
- define scope and target deliverables,
- load orientation/context materials,
- gather and confirm source evidence,
- build claim/evidence and capability-coverage artifacts,
- draft from accepted evidence only,
- validate examples and mechanical consistency,
- run review lanes and reader-facing gates,
- apply recursive corrections,
- run clean-room proof,
- package public outputs separately from evidence.
## Required run outputs
Produce, at minimum:
- the public deliverables named by the selected scope,
- the evidence artifacts required by the contract for those deliverables,
- gate results or validation records for the executed stages,
- and a final packaging summary that keeps public artifacts distinct from evidence artifacts.
## Escalation rules
Stop and escalate instead of guessing when:
- required source evidence is missing or contradictory,
- a required claim cannot be accepted under the source-authority rules,
- a required example cannot be validated,
- a review or clean-room gate exposes unresolved blocking ambiguity,
- or the selected scope depends on materials absent from the project pack.
## Final handoff
At completion, report:
- selected project pack,
- target scope,
- public artifacts produced,
- evidence artifacts produced,
- gates passed or outstanding,
- and any residual risks or escalations.