docs: the M13 milestone record — protocol 2.0 and what rode with it (#284)

[radiusred-wordy]

What this does

The M13 milestone document: docs/milestones/13-protocol-2-0-the-codecrew-layout-and-what-rides-with-it.md, synthesized from #254's own trail under the doc-synthesizer contract, in the house form of the M12 and M11 records.

M13 is the milestone that moved every CodeCrew-owned operational file under .codecrew/, and then decided in the open what else had to ride the protocol major. The record's spine is that second half: two fresh-context scans (Codex gpt-5.5 and Claude Opus) on one brief — what else would force a 3.0 if 2.0 shipped as the layout move alone — both attached to #254 in full, and the operator's Decision sorting all twenty findings into adopted, blessed permanent, or filed. Requirements R1 through R7 are those adoptions — R1 is the layout move, and the Decision lists it among them, because the scans widened it from roles/ to every CodeCrew-owned file including the pointer. R9 is two captures riding along. R8, the v2.0.0 release, was struck seven minutes after the milestone opened and moved to M14 (#269), so the record says plainly that nothing shipped in M13.

What it is drawn from

#254's nine requirements as opened and its single body edit (userContentEdits returns two versions, and the whole diff is the removal of M13-R8), its two scan comments, two Decision comments, one Deviation comment and three QA comments; the ten delivery and remedy task issues (#255–#262, #285, #288) plus #263 closed as moved; their ten merged PRs and descriptions; thirty-three Decision records and six Deviation records; all twenty-three review submissions, including the two on PR #278 whose bodies were edited after submission and the approval on PR #276 that a rebase dismissed; the three adopted captures the merges closed and the five the milestone filed; and #177, decided and deliberately left open. Every one was read from its issue, PR, review, commit or timeline directly — the gather from milestone close 13 --dry-run stops at OPEN_TASKS naming this task, as it has for every record since M8.

What it records that a reader would not otherwise reconstruct

• The two scans as a pair. Where they agreed independently — the pointer's location, migrate needing its own refusal code and its own exemption from the pointer check, the requirement-ID grammar — and where they diverged: Codex on namespace choices, Claude on behaviours that fail open. The Decision took both sides, and the record says so without claiming the divergence was weighed that way, because nothing on the trail says it was.
• The four blessings. The M<n>: title, task/<n>-<slug> branches, the cc: prefix, and ROADMAP.md at the root with docs/milestones/ under docs/ are now permanent by decision rather than by default. That is the only place on the trail where they are settled.
• The R6 story across three QA rounds. not satisfied at 15:01:59Z (a verdict in a four-space indented block still counted), remedy Verdicts inside indented Markdown code blocks do not count #285/PR fix(tracker): strip indented code blocks so a verdict quoted in one is content (#285) #286; not satisfied at 15:30:10Z (an indented block immediately after a heading), remedy Indented code blocks open after a heading, a thematic break or a fence close, not only after a blank line #288/PR fix(tracker): an indented code block opens wherever it would not interrupt a paragraph (#288) #289; satisfied at 16:02:49Z. Each re-verdict scopes itself "for this requirement only" — the supersession rule M13-R6 itself shipped, exercised by hand on its own requirement before any close ever read it. The status cells carry the standing verdict; the prose carries all three.
• The one scope question a seat did not answer itself, raised on PR gh codecrew migrate: the one-shot move from the 1.x layout to 2.0 (#256) #280 and settled by the operator, written up as a Decision on gh codecrew migrate: the one-shot 1.0 to 2.0 move #256 rather than through checkpoint — which is the mechanism the protocol provides for exactly that shape, in the milestone that tightened the grammar of the labels it uses.
• The PR The entry point: .codecrew/AGENTS.md, root pointer, and a line to add when AGENTS.md exists #278 review-body incident, recorded plainly as a coordination-layer tooling fault: two reviews submitted with a body consisting of an unexpanded @-prefixed file reference, both edited to the real verdict text about a minute later and before the merge. No verdict changed; the approval that gated the merge is the reviewer's own; nothing on the trail says how the fault was noticed.
• The reviewer-harness Deviation, and what it shows the protocol actually gates on: the routing table's harness and model are the coordination layer's preference, while the floor for independence is a clean-context session holding the contract, the task and the diff. All twenty-three reviews are radiusred-checky[bot], with the App-ID check recorded in the reviews of six of the ten PRs (The record grammar: gates per paragraph, Gate resolved only, per-comment verdicts, IDs match the milestone #275, Typed identities: ~, app:, user:, team: in the routing table (#258) #276, The 2.0 layout: .codecrew/ everywhere, LAYOUT_LEGACY, this hub migrated #277, Shims removed; the exit-code contract and the refusal-code table in SPEC (#261) #282, fix(tracker): strip indented code blocks so a verdict quoted in one is content (#285) #286, fix(tracker): an indented code block opens wherever it would not interrupt a paragraph (#288) #289).

Also in this PR

• ROADMAP.md gains the M13 row, already Done (the M10-R1 convention). No row was written at milestone new — M12-R1 shipped the verb that stopped writing one, and M13: Protocol 2.0: the .codecrew/ layout and what rides with it #254 is the first milestone opened under it, so unlike M10, M11 and M12 there is no discarded-row Decision on the trail.
• CHANGELOG.md gains ### The M13 record at the top of ## [Unreleased], in the shape of the ### The M12 record entry.
• docs/introduction.md keeps **Shipped:** v1.2.0 ... implementing protocol 1.0 — nothing was tagged — and gains one paragraph naming protocol 2.0 as on main and unreleased, pointing at M14 for the release. The reason is on the record as a Decision: the delivery tasks swept the rest of that page onto the 2.0 layout as they landed, so it names .codecrew/ paths, teaches the typed identity grammar and lists gh codecrew migrate in the install block — all true of main, none of it true of the binary the same page tells you to install.
• README.md gains the same dated paragraph, under its "Start now" block. Its gap needs no version number to exist: the block pairs gh extension install radiusred/gh-codecrew with gh codecrew init # writes and commits .codecrew/, …, and the released v1.2.0 init writes .codecrew.yml and roles/ instead. The reason is a follow-up Decision extending the first, which had rested the README half on the wrong test — "does this page name a version" rather than "would a reader who followed this page get what it describes". Both notes are written to be deleted by M14's release task, and the record says so.

Verification

• milestone evidence 13, from a build of this branch: all 8 cited links resolve across 13 issues — evidence is reachable.
• Every one of the record's 104 github.com URLs was resolved through the API, including each #issuecomment- and #pullrequestreview- anchor against its own issue or PR. Every relative link into a prior record was checked against that file's own headings, anchor by anchor.
• No Go is touched. gofmt -l $(git ls-files '*.go') silent, go vet ./... clean, go test ./... green in all four packages.
• One commit, conventional, lowercase after the type, 74 characters, referencing (#284); no body line over 100 characters.

For the reviewer

• Ordinal and superlative claims. The record makes two: that M13: Protocol 2.0: the .codecrew/ layout and what rides with it #254 is the first milestone opened under the binary that no longer writes a ROADMAP row (sourced to M12-R1 and to M12's own Decision comment calling M12: v1.2.0 and the field fixes behind it #241 "the last milestone opened under that binary", with all three prior records linked), and that gh codecrew migrate: the one-shot 1.0 to 2.0 move #256 carries the milestone's largest set of Decisions on one task (nine, countable on the issue). The placeholder-Gates observation links M8, M9, M10, M11 and M12, as the standard asks.
• The scans' cost is not in the record, and the "What the record does not contain" section says so. The essay M13: Protocol 2.0: the .codecrew/ layout and what rides with it #254's goal cites argues about exactly that cost; the milestone that cites it produced no figure of its own. That absence is stated rather than glossed.
• Harness attribution. Ten review submissions fall between the quota exhaustion and the reset, and the Deviation names only two rounds by number. The record says the identity is constant and verified throughout and that the harness behind each round is not reconstructable, rather than inferring one from prose style.
• The document quotes the @-prefixed review bodies' shape but not the path itself, which is a local dispatch directory outside the repository.

Round two

Six counted claims and one boundary claim corrected against review 5125962836; every finding was re-derived from the trail before it was applied, not taken on the review's word. Captures closed by the merges: three, not four (the paragraph always listed three — #253 and #250 by PR #274, #281 by PR #280 — and the count above it was wrong), fixed in the provenance paragraph and in the captures paragraph. The App-ID check: six PRs, not eight, and the record now names them. Mutations: five PRs, not six, likewise named. Reviews in the codex-out window: ten, not eleven — the eleventh is #280's 14:21:32Z approval, which the record itself calls the first after the reset. #285 opened seventy seconds after the round-one verdict, not four minutes. And the released v1.2.0 binary does not "print nothing at all" against this hub: downloaded and run at the repo root, status and roles show reviewer print codecrew: no .codecrew.yml found (not a CodeCrew repo?) and exit 1, version prints v1.2.0 (protocol 1.0) and exits 0 — a plain error with no refused[CODE]: in it, which is the stronger fact for that paragraph and is what the record now says.

Both nits taken. The PR #278 incident no longer asserts a human: both edits are recorded under the reviewer identity a minute after the second submission, and who or what noticed is marked as not on the record. And the goal-and-outcome sentence now reads "Requirements R1 through R7 are those adoptions", with a clause on why R1 is among them — the scans widened it from roles/ to every CodeCrew-owned file including the pointer.

Requirements

M13-R1, M13-R2, M13-R3, M13-R4, M13-R5, M13-R6, M13-R7, M13-R9 — the record covers all eight; M13-R8 is recorded as struck, with its verbatim text and the Decision that struck it.

Decisions recorded

• The boundary refresh of docs/introduction.md — a paragraph naming what is on main and unreleased, no version number changed; the trade-off, and the three alternatives rejected.
• The boundary note goes on README.md too — extending the first, which rested the README half on the wrong test: the claim at issue was never about a version but about what the page's first executable instruction produces. Round two, from review finding 7.

No deviations from the plan. No ask-the-human points arose.

Closes #284

[radiusred-checky]

Changes requested. The record is the right document: the shape follows M12's, every Decision and Deviation section I opened quotes its source faithfully, the R6 story is told in full with the standing verdicts verbatim, R8 is recorded as struck with its own text and nothing claims v2.0.0 shipped. I read the diff before the PR body, then #284, #254 (body, its one edit, all eight comments), the ten task issues and the ten merged PRs, and opened fifty-three of the record's anchored citations by id. Six of the record's counted claims do not survive that check, and one boundary-refresh claim does not survive running the released binary.

Findings

1. docs/milestones/13-protocol-2-0-the-codecrew-layout-and-what-rides-with-it.md — "Captures adopted and closed by the merges — four:" names three. The paragraph lists #253, #250 and #281, and that is all there is: closingIssuesReferences on the ten merged PRs returns exactly three backlog captures — #250 and #253 by PR #274, #281 by PR #280 (the rest are the ten task issues). The provenance paragraph repeats it: "the four adopted backlog captures the merges closed". Both should read three.

2. "the reviewer verified its own App ID against gh api /apps/radiusred-checky --jq .id on eight of the ten PRs" (Deviations) — six. The check appears in the reviews of #275, #276, #277, #282, #286 and #289. It appears nowhere in #274, #278, #279 or #280 — neither in their reviews nor in their PR comments, in any wording. "What the record does not contain" carries the same number ("the App ID check appears in eight of the ten PRs' reviews"), and so does the PR body ("with the App-ID check recorded on eight of the ten PRs"); all three need the same fix. The conclusion the sentence draws — the identity is constant and verified, so the gate holds — is unaffected: all twenty-three submissions are radiusred-checky[bot].

3. "in six of the ten PRs a mutation applied to the tree and then reverted" (The review rounds) — five. #275 (the compile-safe mutation of the two call sites), #278 (three init.go mutations plus the Kept: assertion), #279 (the fail-open restored in resolveRoles), #280 (the destination preflight removed in a worktree) and #289 (the nine-mutation sweep). #274, #276, #277, #282 and #286 approve on re-runs, a git range-diff, a source-versus-SPEC code-set diff and a built-binary roles show — no mutation in any of them.

4. "Eleven review submissions fall between the quota exhaustion at 12:35Z and 14:20Z" (What the record does not contain) — ten. 12:43:50Z and 12:49:10Z (#276), 13:05:44Z (#277), 13:22:44Z, 13:32:29Z and 13:38:37Z (#278), 13:30:33Z and 13:54:07Z (#279), 13:36:09Z and 14:13:04Z (#280). The eleventh submission in that stretch is #280's approval at 14:21:32Z, which the record itself names two paragraphs earlier as "the first round after" the reset.

5. "Remedy task #285 opened four minutes after the verdict" (QA: three rounds) — seventy seconds. The round-one verdict is 15:01:59Z; #285 was created 15:03:09Z. The "twenty-two minutes after that" for PR #286's merge at 15:25:01Z is right, and the round-two sentence ("#288 opened one minute later" — 15:30:10Z to 15:31:10Z) is exact, which is what makes this one read as a slip rather than a rounding.

6. "The released v1.2.0 binary prints nothing at all against this hub" (the dry-run section) — it refuses, with a code-free error line. I downloaded the v1.2.0 linux-amd64 release asset and ran it at the repo root: status and roles show reviewer both print codecrew: no .codecrew.yml found (not a CodeCrew repo?) and status exits 1; version prints v1.2.0 (protocol 1.0) and exits 0. The mechanism the sentence gives after the colon is exactly right; the claim before it is not what the binary does, and the true version is the stronger one for the paragraph's purpose.

7. The README half of the boundary refresh. The record says twice — the last protocol-discipline bullet and the PR body — that "README.md was read and left alone: it makes no release claim of its own and defers to the introduction for what is shipped". README.md:76 is gh extension install radiusred/gh-codecrew, and README.md:78 is gh codecrew init # writes and commits .codecrew/, AGENTS.md, CLAUDE.md, ROADMAP.md. Run in a scratch git repo, the released v1.2.0 init writes .codecrew.yml and roles/ — it prints wrote .codecrew.yml, wrote roles/coordinator.md and the rest. That is the same defect the #284 Decision names for docs/introduction.md ("all true of main, none of it true of the binary the same page tells you to install"), one page earlier in the funnel. Either README carries the same one-line note, or the record's sentence should say what was actually checked and why the install block is left (the choice is the doc-synthesizer's; resting it on "no release claim of its own" is what does not hold, since the claim at issue is about what init writes, not about a version).

Nits, non-blocking

• The PR #278 incident reads "a human noticed and repaired it a minute later". Both edits (13:39:34Z, 13:39:35Z) are recorded under radiusred-checky, and the record's own gaps section says "Nothing on the trail records the fault, how it was noticed". Consider marking the human as inferred there too, as the gaps section does for the rest of it.
• "Requirements R2 through R7 are those adoptions; R1 is the layout move itself" sits slightly against the adoption Decision, which lists R1 among the adoptions ("the whole CodeCrew-owned filesystem surface moves, pointer included (Codex 1, 2; Claude 5 on the pointer) — R1"). The scans section states it correctly; only the goal-and-outcome sentence reads as if R1 were outside the sort.

What I verified and found sound

The trail. #254 opened 11:22:12Z with nine requirements; userContentEdits totalCount is 2 and the single edit at 11:31:54Z removes M13-R8 and nothing else, which the record quotes verbatim; Decision 5558926520 at 11:31:55Z, #263 closed not_planned at 11:31:56Z, #269 opened 11:31:59Z. Nine tasks created 11:22:57Z-11:23:21Z (24s). Captures #264-#268 created 11:24:17Z-11:24:21Z, seconds before the 11:24:22Z Decision that names them, as the record says. Nothing anywhere claims a release.

Counts. Thirty-three Decision records and six Deviation records across #254 and the ten task issues — including the parenthetical **Decision (restating #285's boundary, unchanged):** on #288, which is what makes #288's "Two Decisions" and the 33 total correct; twenty-three review submissions, twelve change requests, eleven approvals of which ten stand and one was dismissed; ten merged PRs with the per-PR commit counts, merge times and merge commits all matching (b48ffb6, b49adb4, 07e4d0c, 1c989ed, c088717, 1004651, 5fbf14f, 3811ba4, 6c7ece5, c58a7df); 11:22:12Z to 15:58:34Z is four hours, thirty-six minutes, twenty-two seconds; #256's nine Decisions is the largest set on one task; eight observations under "Protocol-discipline observations".

QA. The three verdict comments say what the table and the prose say, word for word, including both supersession scopings ("for this requirement only") and the heading-boundary finding. The standing verdict per requirement is satisfied in all eight rows.

The review rounds. The #276 chronology is exact — change request 12:08:41Z, force-push 12:11:00Z, approval 12:29:16Z, rebase force-push 12:31:40Z dismissing it in the same second. PR #278's two review bodies: the edit history holds the unexpanded @-prefixed file reference submitted at 13:32:29Z and 13:38:37Z and the real verdicts at 13:39:34Z and 13:39:35Z, before the 13:40:43Z merge, exactly as described — and the record quotes the shape without the path, so nothing local leaks into a public file. The six PRs stating "no deviations" are exactly the six named.

The scans. Both are attached in full, both at 3f4de53, ten findings each with file-and-line evidence, each with a "not breaking, do not bundle" section and a verdict; both verdict quotes are verbatim; the finding numbers the Decision and the record cross-reference (Codex 1/2/3/4/5/6/7/8/9/10, Claude 1-10) line up with the headings in each scan.

Citations and links. All fifty-three #issuecomment- and #pullrequestreview- anchors resolve, and each belongs to the issue or PR it is cited under. All nineteen relative links resolve, including every anchor into a prior record. No absolute local path anywhere in the document.

Gates. No paragraph-initial **Gate raised:** or **Gate resolved:** exists anywhere in the milestone's issues or reviews; a repo-wide search for cc:needs-decision returns zero issues; all ten task Plans write "None" under Ask-the-human with a reason; all ten tasks were started by radiusred-cody[bot].

Repo and record mechanics. SPEC §10's table has 42 code rows; .codecrew/config.yml declares codecrew: "2.0"; the ROADMAP row's link resolves to the new file and matches the existing Done rows; the CHANGELOG entry is at the top of ## [Unreleased] and ends (#284); Closes #284 is in the PR body; the Decision is a comment on #284 at 16:20:44Z, before the single commit at 16:21:03Z; the commit is conventional, lowercase after the type, 74 characters, carries (#284), and is authored and committed by radiusred-wordy[bot]; no body line exceeds 100 characters; the diff is four files and no Go.

Executed. gofmt -l . silent, go vet ./... clean, go test ./... green in all four packages, go build -o ./gh-codecrew ./cmd/codecrew clean, with Go caches outside the clone. milestone evidence 13 from that build prints "all 8 cited links resolve across 13 issues — evidence is reachable"; milestone close 13 --dry-run stops at refused[OPEN_TASKS] naming #284, in the shape the record quotes. The installed extension reports dev-c58a7df (protocol 2.0), exactly as the record says of the operator's machine.

Identity. Reviewed as radiusred-checky: the local credential stub's App id matches gh api /apps/radiusred-checky --jq .id, and it differs from the PR author radiusred-wordy[bot].

Findings 1-5 are arithmetic against the trail and cost a line each; finding 6 is one clause; finding 7 is a sentence either way. Nothing in the record's judgement or its sourcing is in question.

[radiusred-wordy]

Round two — all seven findings fixed, both nits taken. Head is 43af96b, one commit, origin/main still c58a7df. Every finding was re-derived from the trail before it was applied; all seven hold.
1. Captures closed by the merges: three. closingIssuesReferences gives #250 and #253 by PR #274 and #281 by PR #280, and the paragraph always listed exactly those three — the count above it was wrong and the provenance paragraph repeated it. Both now read three.
2. The App-ID check: six PRs. Grepping the ten review files for apps/radiusred-checky / the id 4719924 returns hits only in #275, #276, #277, #282, #286 and #289, and none in #274, #278, #279 or #280. Fixed in the Deviations section, in the gaps section and in the PR body, and the record now names the six rather than only counting them, since a bare count is what failed here. The conclusion is untouched: all twenty-three submissions are radiusred-checky[bot].
3. Mutations: five PRs. #275, #278, #279, #280 and #289; the other five approve on re-runs, a git range-diff, a source-versus-SPEC set diff and a built-binary roles show. Named in the record too.
4. Ten review submissions in the codex-out window, not eleven — I listed them out (12:43:50Z, 12:49:10Z, 13:05:44Z, 13:22:44Z, 13:30:33Z, 13:32:29Z, 13:36:09Z, 13:38:37Z, 13:54:07Z, 14:13:04Z) and the eleventh is #280's 14:21:32Z approval, which the record names two paragraphs earlier as the first after the reset. That was the record contradicting itself, which is worse than the count.
5. Seventy seconds, 15:01:59Z to 15:03:09Z, and the record now gives the timestamp rather than a rounded phrase, so the sentence is checkable the way the round-two one beside it already was.
6. What the released binary actually does. I downloaded the v1.2.0 linux-amd64 asset and ran it at the repo root and reproduce your result exactly: status and roles show reviewer print codecrew: no .codecrew.yml found (not a CodeCrew repo?) and exit 1; version prints v1.2.0 (protocol 1.0) and exits 0. The record now says that, and adds the part I think earns its place: there is no refused[CODE]: in that line, because a 1.x binary has no vocabulary for a repository on the 2.0 layout. You are right that the true version is the stronger one for the paragraph.
7. The README half, and why the first Decision was wrong. I checked the README for a release claim, found none, and stopped — but the claim at issue was never about a version. Run in a scratch repo, the released init prints wrote .codecrew.yml, wrote roles/coordinator.md and the rest, so the page's first executable instruction does not produce what the line beside it says it produces. README.md gains the same dated paragraph under "Start now", written to be deleted by M14's release task alongside the introduction's, and a follow-up Decision on #284 records the correction. The record's protocol-discipline bullet no longer says the README "was read and left alone: it makes no release claim of its own"; it states what was checked on both pages and draws the general form — the test is not "does this page name a version" but "would a reader who followed this page get what it describes".
Nits, both taken. The #278 incident no longer asserts a human: both edits are recorded under the reviewer identity a minute after the second submission, "and an edit under an App identity says only which credential made it", with who or what noticed marked as not on the record — the same treatment the gaps section already gave the rest of it. And the goal-and-outcome sentence now reads "Requirements R1 through R7 are those adoptions", with the reason R1 is among them: the scans widened it from roles/ to every CodeCrew-owned file including the pointer.
Re-verified on this head. All 104 github.com URLs across the record, the README and the introduction resolve through the API, including every #issuecomment- and #pullrequestreview- anchor against its own issue or PR; all nineteen relative links and their anchors still resolve. gofmt -l $(git ls-files '*.go') silent, go vet ./... clean, go test ./... green in all four packages — no Go is touched. One commit, conventional, lowercase after the type, 76 characters, (#284), no body line over 100. Both required checks pass on 43af96b.
Thank you for opening fifty-three citations by id and for downloading the release asset rather than reasoning about it — findings 4 and 7 are the two I could not have caught by re-reading my own draft, and 4 in particular was the record disagreeing with itself two paragraphs apart.

[radiusred-checky]

Approved. Round two. All seven corrections and both nits from review 5125962836 are applied, and every one was re-derived from the trail here rather than read off the diff. The record is otherwise byte-identical to the round-one head, the ROADMAP row and the CHANGELOG entry are intact, and both checks are green.

Identity: this round ran under radiusred-checky, App ID 4719924 from the local credential stub, matching gh api /apps/radiusred-checky --jq .id; the PR author is radiusred-wordy[bot], a different App.

The nine, re-derived

1. Captures closed by the merges — three. Closes refs across all ten merged PRs give exactly three capture closures: #250 and #253 by PR #274 (both closed_at 11:57:45Z), #281 by PR #280 (closed_at 14:22:50Z). No fourth anywhere in the ten bodies. Both call sites now read "three" — the provenance paragraph and the captures paragraph — and the times in the prose match the API.
2. The App-ID check — six PRs. Grepping all twenty-three review bodies for apps/radiusred-checky: #275 (1), #276 (2), #277 (2), #282 (2), #286 (1), #289 (1); zero on #274, #278, #279, #280. Six of ten, and the record now names exactly those six, in both the review-rounds section and "What the record does not contain".
3. Mutations — five PRs. Reading the review bodies rather than their names: #275 (compile-safe mutation disabling the mismatch branches), #278 (three mutations of internal/cli/init.go), #279 (fail-open restored in resolveRoles in a throwaway copy), #280 (destination preflight removed in a separate worktree), #289 (the clause-by-clause sweep on internal/tracker/markdown.go). Nothing of the kind on #274, #276, #277, #282, #286. Five, named correctly.
4. Reviews in the codex-out window — ten. Submissions strictly between the Deviation at 12:35:48Z and 14:20Z: 12:43:50, 12:49:10, 13:05:44, 13:22:44, 13:30:33, 13:32:29, 13:36:09, 13:38:37, 13:54:07, 14:13:04. Ten. The eleventh, 14:21:32Z on PR #280, is the one the record itself names as the first round after the reset (lines 699–700), so counting it in the window contradicted the record's own prose; it no longer does.
5. #285 opened seventy seconds after the verdict. The standing R6 not satisfied is comment 5560084992 at 15:01:59Z; issue #285 created_at is 15:03:09Z. Seventy seconds, and the record now gives the timestamp alongside.
6. What the released binary prints. Downloaded the v1.2.0 linux-amd64 release asset and ran it at the repo root: status and roles show reviewer both print codecrew: no .codecrew.yml found (not a CodeCrew repo?) and exit 1; version prints v1.2.0 (protocol 1.0) and exits 0. No refused[CODE]: in either. The record's replacement paragraph says exactly this, and it is a stronger and more checkable fact than "prints nothing at all".
7. The README half of the boundary refresh. README.md gains the paragraph directly under the "Start now" block, in the same form the introduction got: same On main and not yet released: lead, same statement that no released version implements the layout, same M14 pointer, same two closing links (CHANGELOG.md and the M13 record). I checked the claim it rests on rather than the wording: run in a scratch git repository, the released v1.2.0 init writes .codecrew.yml, AGENTS.md, CLAUDE.md, ROADMAP.md and roles/*.md at the root — not .codecrew/ — so the block's first executable instruction does not produce what the comment beside it says. The Decision is extended on #284 as a comment (5560657883), it names the earlier Decision it corrects and why the earlier test was the wrong one, and it carries the trade-off and three rejected alternatives. The record's protocol-discipline bullet no longer says the README "was read and left alone"; it states what was checked on both pages. The CHANGELOG sentence was updated to match, which is right — the entry would otherwise have described a one-page refresh.
8. The #278 incident no longer asserts a human. userContentEdits on the two reviews: 5125452597 submitted 13:32:29Z, edited 13:39:34Z; 5125469797 submitted 13:38:37Z, edited 13:39:35Z; both edits by radiusred-checky. The record now says both edits are under the reviewer identity a minute after the second submission and marks who or what noticed as not on the record, with the reason an App-identity edit cannot settle it. That is what the trail supports.
9. R1 among the adoptions. The adoption Decision (#254 comment 5558890102) opens "Adopted into the requirements: the whole CodeCrew-owned filesystem surface moves, pointer included (Codex 1, 2; Claude 5 on the pointer) — R1". "Requirements R1 through R7 are those adoptions", with the clause on the scans widening R1 from roles/ to every CodeCrew-owned file including the pointer, now matches the Decision.

Nothing else moved

git diff between the round-one head and this one touches three files and nothing else. Every hunk in docs/milestones/13-protocol-2-0-the-codecrew-layout-and-what-rides-with-it.md maps to one of the nine above — ten hunks, no stray edits, no reflow. README.md is the new paragraph only; CHANGELOG.md is the three-line rewrite of the boundary sentence. ROADMAP.md and docs/introduction.md are unchanged since round one, and the ROADMAP M13 row is intact and points at the record.

Spot-checks on the counts round one had already cleared, to be sure the rewrites did not disturb them: twenty-three review submissions on the ten merged PRs, all radiusred-checky[bot], twelve CHANGES_REQUESTED and one DISMISSED; thirty-three Decision records and six Deviation records across #254 and the ten task issues.

Gates

gofmt -l . clean, go vet ./... clean, go build ./cmd/codecrew and go test ./... green — no Go is touched. milestone evidence 13 from a build of this branch: eight requirements counted, all nine cited links resolve across thirteen issues. Every relative Markdown link in the four changed docs resolves on disk. Both required checks pass on the head commit. Commit subject 74 characters, conventional, lowercase after the type, (#284); body lines all under 100. Closes #284 in the PR body — #284 adopts no capture, so there is no second Closes to expect. The Plan was on the issue before the commit, and the CHANGELOG entry sits at the top of ## [Unreleased] and ends (#284).

Two nits, neither blocking and neither in the repository

• The PR description's "What this does" paragraph still reads "Requirements R2 to R7 are those adoptions; R1 is the layout itself" — the sentence finding 9 corrected in the record, and the description's own "Round two" section contradicts it two screens later. Worth a touch if the body is edited again.
• The description's "Decisions recorded" section lists only the introduction Decision. The follow-up that extends it to README.md is linked from "Also in this PR" but not from the section that enumerates them.

Both are description hygiene; the record itself and the issue trail are right.