RFC Workflow Agent Entry

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

Load order

1. Select exactly one reusable project pack under projects/ (never a pack's runs/ subtree).
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 for the execution.
   • The canonical repo-local default is projects/<selected-project>/runs/<run-id>/.
   • Keep each execution in its own run-owned subdirectory; do not reuse one run directory for unrelated runs.
4. Verify the selected pack's required render/toolchain prerequisites before translation or execution.
5. Read workflow.contract.yaml first. Use schemas/workflow-contract.schema.json when the harness needs the machine-checkable contract shape for validation or native workflow generation.
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 stage artifacts under 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. If no suitable pack exists yet and the suite boundaries are not already fixed, first run prompts/discover-rfc-suite-shape.md against the real source corpus and review its final Pack scaffold inputs block. Then scaffold the pack with projects/PROMPT-GENERATE-PROJECT-PACK.md, using projects/template-ietf/ as the reusable IETF starter pack. If the pack inputs are already concrete, you can scaffold directly. If you want the new pack's references/README.md placeholder tracked, explicitly add/promote it because the default ignore glob matches projects/*/references/*.
10. Run prompts/translate-workflow-for-harness.md so the harness translates AGENTS.md, the neutral contract, core rules, reusable materials, and the selected pack into its own execution model and any native workflow or configuration representation it needs before execution.
11. Keep the translation output and any generated or configured harness-native workflow machinery in context, 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 AGENTS.md, workflow.contract.yaml, core/, reusable materials, and one selected project pack as instructions,
• allocate native execution units for the contract's roles and stages,
• translate that neutral input into its own workflow/stage representation before execution when the harness uses a native config language or adapter layer, or into a concrete primitive map plus ready-to-run handoff when it does not,
• enforce or emulate stage gates and recursive correction,
• and keep run-local output in a dedicated run-owned workspace such as projects/<selected-project>/runs/<run-id>/, adjacent to but separate from the reusable pack inputs.

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/; its runs/ subtree is reserved for run-owned output, not reusable pack input.
• Target scope — document:<brief-name>, subset:<brief-name>,..., or suite:all.
• Dedicated run root — one writable run-owned workspace, normally projects/<selected-project>/runs/<run-id>/, with one subdirectory per execution.
• 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.
• Native workflow/config language, schema, or DSL — name the exact harness-native representation the translation must target when one exists (for example, Ultracode) and the form the emitted runnable artifact should take, or state explicitly that this harness has no separate native workflow/config artifact.
• Native workflow/config authoring references — when the harness expects native workflow/config text, supply the schema, reference docs, example configs, templates, or validator-facing shape needed to emit it. If those inputs are unavailable, translation must escalate instead of fabricating native config; if no separate native artifact exists, none required is acceptable.

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. Native workflow/config language, schema, or DSL — the exact native representation name this harness expects for runnable workflows or config (for example, Ultracode) and what form the emitted artifact must take, or an explicit none/not supported.
10. Native workflow/config authoring references — the concrete schema, reference material, example configs, templates, or validator-facing shape the model will rely on to emit valid native workflow/config text when native syntax is required, none required when it is not, or an explicit statement that the needed inputs are unavailable and the run must escalate before translation can finish.
11. Repo-file instruction loading + generation target — exactly how the harness loads AGENTS.md, workflow.contract.yaml, core/, reusable materials, and the selected pack as instructions, and whether translation yields staged context, generated native config, or another harness-native workflow representation for the run.

If any item above is still vague, stop and resolve it before translation. The translation prompt should receive concrete answers, not placeholders. For the native workflow/config fields, an explicit none/not supported is concrete for harnesses that run directly from a primitive map and handoff. The translation output must end in a ready-to-run handoff and preserve or generate whatever harness-native workflow/stage configuration is required before prompts/run-selected-project.md; when the harness requires native workflow/config text or an object in a named language/schema/DSL, include that actual generated representation instead of a prose-only description. If the harness expects native syntax but the required schema/reference/examples/templates are missing, escalate rather than substituting generic session/controller prose. If you change threads or sessions, paste that handoff above the run prompt and keep the generated configuration available.