a8986c2c8a
Beyond the mechanical conflicts (provider capability lines vs master's new inheritsParentContext field; generated catalogs regenerated rather than hand-merged; knip/lockfile), three master-side reworks required semantic adaptation of this branch: - The persona rework removed AgentOptions.systemPrompt, which was the structured-output instruction's channel. The instruction now rides the SAME final-request enforcement listener that injects the schema'd tool: appended per request to final.system (per-request wire state, not agent prompt state). Tests assert the wire request (adapter.requests) instead of child.options; the bare-direct-dispatch test pins the no-system arm. - Tool guidance moved out of deployment prompts into per-tool prompt sections; the examples' workflow paragraph became a tool:<toolName> section contributed by dsh-tool-workflow (explicit-ask-only policy), and both example personas resolve to master's minimal identity+behavior form. tool-workflow gains inject: systemPrompt (+ peer dep, tsconfig ref); the export-shape guard updated. - The uniform-RFC-format gate: the dynamic-workflows RFC restructured to the implemented/ skeleton (bare Status line; Proposal -> Decision; What-was-rejected -> Alternatives considered; new Consequences), and the overall-run-timeout deferral is now recorded in the RFC's Deferred list. The doc-graphs atlas classification gains the workflows seam (workflow-vm implementation, tool-workflow consumer). Master's harness-identity section made "empty assembled prompt" states unreachable through the loop, so the instruction-append is a plain undefined-ternary and the structured tests assert append-not-replace. All snapshot goldens (including workflow-run) replay unchanged. Full local CI-equivalent gate sequence green on the merged tree.
RFCs
One kind of design doc lives here. An RFC records a decision or proposal that shapes this codebase — the why and what we gave up, the parts code and docs can't carry. The full list is the generated INDEX.md; this file is the contract — where RFCs live, when to write one, and the in-file format.
Layout and naming
Every RFC has two axes, both encoded in its path — {lifecycle}/{class}/yyyy-mm-dd-topic-title.md:
- Lifecycle (the top-level folder) is the RFC's status, and an RFC moves between folders as that status changes:
proposed/— proposals reviewed before implementation; not yet built (or only partly).implemented/— the decision shipped. The file records what was decided and what was rejected, and is kept current with what actually shipped: when the code later moves a file, renames a package, or changes a key/default, the RFC is updated in the same change to match (facts only — paths, names, structure — not the decision itself). See implemented/AGENTS.md.rejected/— the proposal was considered and declined. Kept for the record so the rejection isn't re-litigated.
- Class (the nested folder) is the kind of decision — see Classification below.
The date in the filename is when the topic was first proposed (per git history). Cross-references between RFCs use relative markdown links ([topic](../../implemented/architecture/2026-…-….md)) — never bare prose or numbers — so they are mechanically checkable and survive moves between folders.
Classification
Each RFC is filed under exactly one class — the kind of decision it records. The class is encoded in the path (the folder is the label, so a file's location declares its class) and the set is closed: scripts/rfc-index.ts owns the canonical set, scripts/verify-rfc-classification.ts rejects any folder outside it, and INDEX.md is generated from the tree in full (pnpm run gen-rfc-index rewrites it from each RFC's path, H1 title, and filename date; the gate fails when it is stale, and rejects an index-shaped row in this file). Adding a new class means amending that const and this section, not just dropping a new folder. See the classification RFC for why the taxonomy is path-encoded and gated, and the index-generation RFC for why the index is generated while this prose stays curated.
| Class | What it covers |
|---|---|
feature |
A new user- or model-facing capability. |
bug-fix |
Corrects a defect or closes a gap a postmortem surfaced. |
simplification |
Removes code, behavior, or surface area without adding a capability. |
architecture |
A structural decision about the shipped source — how packages relate, what the runtime vocabulary is. |
process |
Tooling, policy, or workflow around the code — gates, the package manager, vendoring — not runtime behavior. |
testing |
Test infrastructure and strategy. |
The architecture / process line: architecture is about the source we ship; process is the surrounding tooling and workflow. (refactor is deliberately absent — it overlaps simplification, whose discriminator, "does observable behavior change?", already covers it.)
When to write one
Write an RFC when a decision is durable (it shapes the codebase beyond a single function or package), contested (there was a real alternative a reasonable engineer might have chosen), and surprising (a future reader would otherwise ask "why on earth is it done this way?"). A proposal for substantial future work starts in proposed/; a decision already made starts in implemented/. Pick the class folder that matches the decision (see Classification).
Do NOT write one for a mechanical or local choice (a variable name, a one-file refactor), for anything already enforced and explained by a gate or a convention in AGENTS.md, or for a still-provisional decision tagged TODO(...) in the code — record those as TODOs and promote to an RFC only once they settle. An RFC is never edited into a different decision: supersede it with a new one and cross-link. (Editing an implemented/ RFC to track where its already-made decision now lives — a moved file, a renamed package — is not a different decision and is required, not forbidden; see implemented/AGENTS.md.)
The file format
Every RFC follows one in-file format, enforced by pnpm run verify-rfc-format (scripts/verify-rfc-format.ts, part of doc-sync); the rationale for the format — and the alternatives it rejected — is the uniform-format RFC.
The header block
The first three lines of every RFC are exactly:
# RFC: <title>
Status: <status>
followed by a blank line. The Status: value is one of three forms, and must agree with the lifecycle folder the file sits in — the gate cross-checks them:
Status: proposedStatus: implementedStatus: rejected — <why, in one line>
The status carries no dates and no parentheticals: the filename holds the first-proposed date, git holds everything else, and an "accepted in amended form" note is body content (state the amendment where the decision is stated). The rejection reason is the one status with content, because a rejected RFC's verdict is the fact readers come for.
The body skeleton
Every RFC opens its body with ## Problem — the motivation, written to stand without the solution. What follows depends on the lifecycle; recurring sections use these canonical names and nothing else, while genuinely bespoke technical sections (package topology, wire contracts, schemas) remain free-form between the required ones.
proposed/
## Problem
## Proposal
…bespoke sections…
## Alternatives considered
## Acceptance criteria
## Risks
## Proposal is the intended change and may legitimately speak in the future tense — plans, migration steps, and open questions belong here while the work is unbuilt. ## Acceptance criteria says what observable state means done. ## Risks covers both what could go wrong and what the change knowingly gives up.
implemented/
## Problem
## Decision
…bespoke sections…
## Alternatives considered
## Consequences
## Decision describes shipped reality in the present tense, and the whole file is kept current with it per implemented/AGENTS.md. ## Consequences records what the trade-off cost and bought. Proposal-era headings are spec-speak here and the gate rejects them: ## Proposal, ## Plan, ## Migration plan, and ## Acceptance criteria may not appear in an implemented RFC (the slop checklist names why). A ## Testing, ## Deferred, or ## Related section is fine where it states present-tense fact.
rejected/
A rejected RFC is the proposal, frozen: it keeps whatever proposal-time sections it had (including ## Acceptance criteria or ## Plan), and the verdict lives on the Status: line. Only the header block, the ## Problem opener, a ## Proposal section, and the Alternatives-considered mandate below apply.
Alternatives considered — mandatory
Every RFC carries an ## Alternatives considered section: each genuine alternative and why it lost, one bold-led paragraph per alternative or a ### Why not <X>? subsection per contested one. A decision recorded without what it beat invites re-litigation — the failure RFCs exist to prevent.
Alternatives are recorded, never invented. An RFC dated before 2026-07-05 whose alternatives are not reconstructible from the record carries this exact comment in place of the section, which the gate accepts for pre-format files only:
<!-- rfc-format: alternatives-not-recorded (pre-format RFC) -->
Moving between lifecycles
Moving a file between lifecycle folders means updating the Status: line and re-satisfying that folder's skeleton in the same change — the gate fails the move otherwise. Concretely, proposed/ → implemented/ rewrites ## Proposal into a present-tense ## Decision, folds ## Acceptance criteria and ## Risks into ## Consequences (or a present-tense ## Testing/## Verification section for what now pins the behavior), and drops plans in favor of what shipped — the rewrite implemented/AGENTS.md requires, made mechanical. proposed/ → rejected/ only adds the reason to the Status: line and freezes the file.
Chinese counterparts
A .zh.md counterpart mirrors its English sibling's structure section-for-section under the i18n contract; the machine-checked header tokens (# RFC: and the Status: line) stay in English verbatim. The format gate skips .zh.md files — the pairing gate owns their consistency.