Rfc Resolve

RFC Resolve Workflow

Use this skill only after the RFC's implementation program is complete or its remaining direction has been explicitly superseded. Scripts are executable; invoke them directly (no cargo +nightly -Zscript prefix).

Required Flow

1. Confirm Program Readiness

Confirm completed implementation tasks have passed their tests, review, and behavior verification. Confirm every phase is completed or belongs to an explicitly superseded remainder, and confirm every linked task issue is closed.

2. Synchronize Phase Outcomes

Update Implementation Phases from the linked task documents:

• replace all implemented phase placeholders with concrete Task Doc and Task Issue values;
• set each completed Phase Status;
• write a concise, concrete Implementation Summary;
• preserve phase Related Backlogs that are completion inputs and must be resolved before the strict precheck;
• ensure every linked task has non-empty Implementation Notes.

Keep every completed phase parseable by tools/rfc.rs. Keep still-open deferred follow-ups in Future Work rather than adding them to phase Related Backlogs, because the strict precheck expects phase-related backlogs to be resolved.

For a superseded program, retain completed phases as parseable entries. Remove unimplemented TBD.md or #0 phase entries and summarize them under a non-phase heading such as ### Superseded Remainder, including the reason and replacement RFC.

3. Compact and Synchronize the RFC

Edit the RFC directly. Preserve its frontmatter, title, and required modern sections from docs/rfcs/0000-template.md, but rewrite the content as a concise historical record of the final program rather than an implementation guide.

Before removing design-phase detail, inspect the completed task documents and capture material implementation outcomes, deviations, review findings, verification evidence, deferred work, and supersession decisions.

Preserve:

• issue metadata and final implemented or superseded status;
• material [D#], [C#], [U#], and [B#] evidence with no dangling references;
• source and related backlog paths;
• task documents, task issues, phase status, implementation summaries, and replacement RFC links;
• durable architecture, public contracts, correctness and safety invariants, compatibility boundaries, rationale, consequences, and unresolved work.

Do not renumber retained evidence tokens unless every retained use is updated.

Compact each section according to its historical purpose:

• Summary: retain the original problem, final direction, delivered outcome, and implemented or superseded boundary.
• Context: retain durable motivation, constraints, and program history.
• Goals and Non-Goals when present: retain delivered objectives and meaningful program boundaries.
• Design Inputs: retain only material documents, code, conversation decisions, and source backlogs cited by the compacted record. Preserve at least the evidence categories required by strict validation.
• Decision: replace implementation instructions with the final architecture, interfaces, data flow, invariants, compatibility rules, and material rationale.
• Alternatives Considered: retain only alternatives useful to future design, with a ### heading, explicit Why Not Chosen rationale, and evidence references.
• Unsafe Considerations: retain final unsafe boundaries, invariants, and validation outcomes when applicable.
• Implementation Phases: retain concise phase boundaries and all parseable tracking fields; remove task-level mechanics already recorded in task docs.
• Test or validation sections: retain actual coverage categories, material results, and accepted gaps; remove exhaustive planned cases, routine command lists, and raw output.
• Consequences: retain observed positive and negative outcomes.
• Open Questions: retain only unresolved questions.
• Future Work: retain actionable follow-ups with backlog or replacement RFC links.
• References: retain the live sources needed by the compacted record.