Plan and review files stop carrying the delivery record once the roadmap and the pull request do

outcome

Decide whether the Protocol retires its numbered plan files and its committed review files, reading its next work from the roadmap and keeping each arc's record in git and its pull request, and what replaces the gate that requires a current plan.

context

Plan files grew as the Protocol's working record: every arc adds one, the handbook keeps a status line for each, and the self-hosting gate requires the highest-numbered plan to carry a status header the handbook names. Review reports grew beside them under reviews/, with their prompts and assets. Since the graph-first planning arc, a plan is a thin pointer to its Pack and capture Specs, and the pull request description standard already asks each description for the arc's story, its rulings as tables, its acceptance as measured and a forward section. The owner asked whether plans can be replaced by Specs: no prose in the plan, but designed, grouped and prioritized roadmaps and sets of features or epics. The owner then retired both folders as carriers of the delivery record, leaving their removal or archival to a separate cleanup change.

decision

The Protocol reads its forward planning from its roadmap and keeps its delivery record in git and its pull requests; it adds no plan file and no review file, and plans/ and reviews/ stand as frozen history until a later arc removes or archives them. An agent opening the next work runs the roadmap recipe over the roadmap Pack the handbook names and follows each entry to its Packs and carrying Specs. Before an arc's first push its record is its branch, git being the event log: the arc's first commit message states the owner's working rules for the arc and the arc's Pack, each later message says what its unit did, and outstanding work is read from the arc's Pack, the backlogs and the open-question register; no record file is kept under reviews/ or anywhere else. The arc pushes and opens its draft pull request at its first coherent commit, normally the scaffold, so the window in which only local git holds the record stays short and a session restarted on another machine sees the work. The draft pull request description then holds the arc's narrative: its story, lanes, rulings with who made them, review findings as change proposals and their memos, acceptance as measured, deferrals and refusals. A review's findings against Specs travel as a change proposal whose base is the commit the reviewer read: the branch head, or, for a proposal composed in a preview, the merge commit its stamp names, checked against that base and posted to the pull request as its memo; a finding against code or another file is a review comment on its line; a finding left open becomes an open question with its decider, provisional reading and links. Evidence no test or recipe carries is committed on the arc's branch with the commands that made it, linked from the description at that commit, and removed before the merge; the Protocol merges its pull requests with merge commits, and GitHub keeps each pull request's head ref, so links at the evidence commit keep resolving. A squash or rebase merge would need the evidence published to a durable ref first. Briefs and prompts stay in the session. The handbook names the roadmap Pack and the roadmap recipe where it named the current plan, and the self-hosting gate checks that instead of a current plan.

rationale

• Hard to reverse: the handbook, the skills, the description standard and a gate point every session at the newest plan and at committed review files, and every session's first read changes. Surprising without context: a reader finds two folders that stopped. A real trade-off: one forward-planning carrier in the graph and one record per arc in git and its pull request, with nothing to keep in step, against review findings and pre-push state living in commit messages and pull request threads rather than in files a person can search in the tree.

alternatives

• Keep plan files for forward planning beside the roadmap: priority would live in two places, and the plan's copy would drift.
• Keep a thin plan file per arc for its execution record alone, with no status gate: the pull request description already carries the same record by the description standard, so the file would be a second copy that the next session must reconcile.
• Record an arc's execution in the graph, as an arc Spec or Pack fields: who ruled what and when is history that git and the description keep, and that a review happened is never a graph fact.
• A gate check that refuses a numbered plan past the last frozen one: the cleanup arc removes the folder, so the check would guard a short window, and refusing a kind of file polices the workflow, not conformance; the handbook saying the plans are frozen history is enough.
• Keep an arc's record in a file under reviews/ until its first push, then only its link: the file repeats what the commits already say, outlives the arc as a stub, and keeps reviews/ growing after its retirement.
• Keep review reports as committed files beside the change proposal: the proposal is the reviewable shape, an applied edit is git history and an open finding is an open question, so a report file repeats all three and goes stale with the next edit.
• Keep evidence no test or recipe carries in a committed evidence folder on the main line: the folder becomes a new store that grows with every arc, while a link pinned to the arc's commit already lasts after the merge.
• Link only the latest preview or an expiring CI artifact as evidence: a later run replaces what a historical description cites.

consequences

• The handbook drops its stack of plan statuses for a short pointer to the roadmap and its recipe. The self-hosting gate's current-record check refuses a handbook that does not name the roadmap Pack and recipe, and a roadmap Pack manifest that is missing or does not state priority order; its frozen historical checks, its green-gate legs and its ban on plan status in the registry and the glossary stay until the cleanup arc removes the folders they read. It adds no check of plan numbers, roadmap content, work order, freshness or review disposition.
• The graph-first planning Spec's plan-file rule narrows to a plan document a corpus chooses to keep, which points to its Packs and carrying Specs and confers nothing; an adopter keeps whatever planning documents it wants, and a roadmap is open to it as to the Protocol.
• The description standard renders its forward section with the roadmap memo; the pull request that completes an entry's selected work removes it from the roadmap in the same change, and entries join or move only on the owner's word.
• The owner's instruction that opens an arc authorizes commits on its branch, as a plan's commit strategy did, and its push; this record convention creates no authority of its own. The arc's first commit message records the owner's working rules and the draft description repeats them. A session that must stop with no clean boundary commits its work in progress on the arc's branch with a message saying what is incomplete, rather than accounting for it in a file; a session resuming without its predecessor reads the branch, its commits, the draft pull request and the graph, and never claims git kept what was never committed.
• The proposal schema still scopes Specs only: a finding that changes no Spec takes no invented Spec scope, and a review that proposes no Spec edit needs no empty proposal. An accepted change is an ordinary carrier edit, and whether a change was accepted stays in the pull request's discussion and git, never in the proposal or the graph.
• Tests and recipes carry repeatable evidence. A preview is the current human view of a branch, never an immutable acceptance record, so the description names the commit it measured and the commands that re-derive each number.
• The plan and review files stay as they are until a dedicated cleanup arc removes or archives them and updates the historical checks and links that read them; until then nothing is added to either, and a file in either changes only to correct the record it keeps. This decision sets no record convention for an adopter.

Verifier bindings

No verifier binding recorded.

Requirement drawing

• Declared verifying examples: no declared verifying example.
• Satisfying or referencing units: no recorded binding.
• Test or oracle bindings: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.