Prompt: Run Selected Project

Use this prompt only after prompts/translate-workflow-for-harness.md has returned a ready-to-run handoff.

Before sending this prompt:

• keep the translation handoff in the same thread/session, or paste it immediately above this prompt if you are starting fresh
• replace the selected project pack, target scope, and run workspace fields with concrete values
• keep the translated primitive map and escalation rules intact; do not re-translate implicitly here
• confirm the selected pack's render/toolchain prerequisites were already verified during startup

Expected next step:

• the harness executes the run using the retained translation mapping
• the final report names public artifacts, evidence artifacts, gate outcomes, and any escalations or residual risks

Run the neutral RFC workflow for one selected project pack using the already-prepared translation handoff from `prompts/translate-workflow-for-harness.md`.

If that handoff is not still in context, paste it immediately above this prompt before execution. Do not substitute a fresh translation from memory.

Translation handoff context: <retain from the same thread/session or paste the ready-to-run handoff here>
- This must carry the selected project pack, target scope, run root, primitive map, first execution step, and escalation condition from the translation step.
- If the translation handoff is missing, stop and ask for it before executing.

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>
- The canonical repo-local default is `projects/<selected-project>/runs/<run-id>/`.
- This must resolve to one dedicated writable run root for this execution, not the repo root, not the selected project-pack root, and not the bare `projects/<selected-project>/runs/` directory.
- The tracked `projects/<selected-project>/runs/README.md` file is only the pack-local placeholder; the actual run root is the sibling `<run-id>/` directory you create for this execution.
- 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.
- Keep the run tree segregated: use one per-run subdirectory and do not mix artifacts from different executions.
- The workspace is run-owned: stages may create, overwrite, and retain artifacts there without polluting reusable pack content.

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`, the selected pack's suite, corpus, `references.md`, any staged support material under `projects/<selected-project>/references/`, metadata, document briefs, examples, and `projects/<selected-project>/runs/README.md` if you are using the repo-local pack path.
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.