docs: flip the changelog, the introduction and the README to v2.0.0 (#272)

[radiusred-cody]

Part A of #272; not a closing PR for that task. #272 stays open until Part B — the annotated tag, release.yml, the five assets — and the operator's own verification are done, so this PR carries no auto-close reference and deliberately spells none anywhere in this body.

M14-R3, first half. As #242's PR #246 did for v1.2.0, with the one thing a major earns that a patch does not: a block a 1.x adopter can act on, at the top of the section rather than four hundred lines into it.

What changed

CHANGELOG.md — ## [Unreleased] becomes ## [2.0.0] — 2026-09-06, with a fresh empty ## [Unreleased] (Nothing yet.) above it. The nineteen entries that were under Unreleased — M13's protocol-2.0 work, M14's bookkeeping, and the M12 and M13 records — move into 2.0.0 unchanged but for the tidy below. Link definitions: [Unreleased] now compares v2.0.0...HEAD; [2.0.0] added as v1.2.0...v2.0.0. No entry for this task itself, as with #186 and #242 (Decision).

The lead block — a new ### What broke, and what to do opens the 2.0.0 section: the .codecrew/ move in one paragraph, that a 2.0 binary refuses a 1.x repo with refused[LAYOUT_LEGACY] and there is no dual read, then the migration as five numbered steps (upgrade the extension; gh codecrew migrate --dry-run then migrate in each repo, hubs before their spokes, because a spoke reads the hub's .codecrew/config.yml and refuses HUB_UNREADABLE while the hub is still on 1.x; git show to read the commit; push and open the PR yourself, since migrate never pushes; paste the action needed lines into a kept root AGENTS.md or CLAUDE.md). A final paragraph names the other breaks — typed identities, routing failing closed, the entry point's move, the three deleted 1.0 shims, and the record grammar that reclassifies text already written on GitHub — each pointing at its own entry below rather than restating it. The heading form follows 1.0.0's ### What 1.0 promises, the other section in this file that summarises rather than records. Decision, including the deliberate overlap with the older "Moving a repo forward" block.

The one tidy — the cc: labels entry's third bullet still ended on the sentence SPEC §4 stopped saying in dd5913d ("migrate runs once, on a repository whose labels nobody chose; init reruns, on one whose labels somebody may have"), while the fourth bullet, edited in that same commit, already carried the corrected reading. The third now uses §4's own wording. Its own commit, so the flip diff stays readable.

docs/introduction.md — "What exists": **Shipped:** v1.2.0 … protocol 1.0 → v2.0.0 … protocol 2.0, and the version example → v2.0.0 (protocol 2.0). The verb list gains migrate, checked against internal/cli/cli.go's dispatch: the verb shipped in #256 while 2.0 sat on main unreleased, so a paragraph headed Shipped: was right to omit it until now (Decision). The dated "On main and not yet released" paragraph #284 added is deleted — what it described is what this release ships.

README.md — the matching "On main and not yet released" block under "Start now" is replaced by one short paragraph for an adopter already running CodeCrew: v2.0.0 is the current release, a 1.x repo is refused rather than read, gh codecrew migrate moves it forward hubs before spokes, and the changelog's lead has the steps.

What deliberately did not change

ROADMAP.md's M12 row (v1.2.0 and the field fixes behind it) is the only 1.2.0 left outside CHANGELOG.md history and docs/milestones/, and it records which milestone shipped that release — flipping it would make it false, the same call #242 recorded for docs/extensions.md and docs/platform-interop.md.

The docs/introduction.md and README.md links to the M13 record went with the paragraphs that carried them; the record itself is unchanged, and the changelog is where 2.0's break is now documented for a reader who is not archaeology-minded.

version is ldflags-stamped from the tag, so there is nothing to bump in Go; the protocol version 2.0 has been in internal/config since #255.

Checks

Docs only, no Go touched. gofmt -l . silent, go vet ./... clean, go test ./... green as the boundary check. git grep 'not yet released' outside docs/milestones/ finds nothing; git grep '1\.2\.0' outside CHANGELOG.md and docs/milestones/ finds only the ROADMAP row above. Commit subjects measured: 80, 71, 75 characters.

After the merge

Part B, on the coordination layer's word: the annotated tag v2.0.0 with message v2.0.0 (protocol 2.0) cut on the merge commit by the implementer identity, release.yml (gh-extension-precompile) watched to success, the five platform assets confirmed, and the evidence posted on #272 as #242's was. If the tag slips past 2026-09-06 the date in the ## [2.0.0] heading is amended before tagging. The operator's own verification — gh extension upgrade codecrew → v2.0.0, status clean on this migrated hub, migrate --dry-run reporting already 2.0 — and the twelve-repo migration are the operator's to run and record on #269.

[radiusred-checky]

Requesting changes.

• PR body, first line: the body says this is "deliberately not Closes #272", but the literal closing keyword is still present. GitHub is parsing it as an auto-close reference: gh pr view 298 --json closingIssuesReferences reports #272. That violates the task/dispatch requirement that this Part A PR leave #272 open until Part B and the operator verification finish. Please remove the literal closing phrase, for example by saying "not a closing PR for #272" without a GitHub closing keyword.

Checks run: gofmt -l ., go vet ./..., go test ./..., go build -o ./gh-codecrew ./cmd/codecrew, ./gh-codecrew help, and GH_TOKEN=... ./gh-codecrew migrate --dry-run. The code checks passed, and the built dry run reports this hub is already on protocol 2.0 with labels at the defaults.

[radiusred-cody]

Thanks — the body is fixed, and the second half of the finding turns out to be structural rather than editorial.
Done: every closing-keyword phrase is gone from the body. The first line now reads "Part A of #272; not a closing PR for that task." I also reworded two incidental uses elsewhere ("One closing paragraph" → "A final paragraph"; "still closed with the sentence" → "still ended on the sentence") so no keyword word sits anywhere near a ref. grep -Ei 'clos(e|es|ed)|fix(e[sd])?|resolv(e|es|ed)' over the body now matches only prose with no reference after it.
Still true, and not fixable here: gh pr view 298 --json closingIssuesReferences still lists #272. The link is not from the body. gh codecrew task start creates the working branch with gh issue develop (internal/tracker/github.go:230) — a linked branch on the issue's development panel — and GitHub converts that branch link into a linked pull request when the PR is opened. Evidence on both sides: removing the keyword produced no DisconnectedEvent and did not clear the reference; and gh issue develop 272 --list and the linkedBranches GraphQL connection are both empty, the branch link having been consumed by this PR. The public schema has createLinkedBranch and deleteLinkedBranch but nothing that unlinks a pull request, and the surviving ConnectedEvent is not deletable.
So merging #298 will close #272 regardless of the body. That is how every task in this hub has closed: task finish does not close the task issue itself — its only CloseIssue call is for adopted captures (internal/cli/task.go:689) — it relies on this link. M12 went the same way: #242 was closed by its merge and Part B's tag, the release evidence and the operator's verification were all posted on the closed issue.
I have recorded the finding and the three options I can see — accept the close and run Part B on a closed #272 as M12 did; reopen #272 after the merge and close it again after the operator's verification; or replace this PR with one opened after the branch link was consumed, which would clear the reference at the cost of this PR's number, URL and your review — as a Deviation on #272. Which one to take is the coordination layer's call, not mine, so I have made no commit and no push and have not run task finish.

[radiusred-checky]

Approved.

Round-two body check passes: the PR body says "Part A of #272" and I found no close/fix/resolve closing keyword immediately before #272. GitHub still reports #272 through the linked branch, and the Decision recorded on #272 accepts that flow for Part B and operator verification, so I am not holding the PR on that reference.

I rechecked the release flip against M14-R3. The accumulated origin/main Unreleased entries are present under ## [2.0.0], with only the recorded label-entry tidy plus the new lead block; the fresh ## [Unreleased] is empty; and the compare refs are in the requested shape, with v2.0.0 expected to resolve after the Part B tag. README.md and docs/introduction.md no longer carry the interim "main and not yet released" paragraphs and read consistently for the v2.0.0/protocol 2.0 release.

Verification run: gofmt -l ., go vet ./..., go test ./..., go build -o ./gh-codecrew ./cmd/codecrew, ./gh-codecrew help, and ./gh-codecrew migrate --dry-run. I also checked gh extension upgrade codecrew --dry-run; the command form is accepted by gh, and this checkout fails only because the installed extension is local. No Go files are touched, the task and milestone record have the required Decisions, and the commit subjects meet the convention and reference (#272).