go-live 8/9: post-swap docs, labels, boards, and integration hygiene

[cliffhall]

Phase 8 of 9 in the v2 go-live runbook — see #1804 (§10). Depends on phase 4. Reversible.

Everything that silently inverts when main becomes v2.

Tasks

• Closes #N starts working. Closing keywords only auto-close on the default branch, so v2 PRs targeting v2/main never auto-closed. After the swap, PRs into main do. Update AGENTS.md and drop the manual close-and-move-to-Done ritual.
• Docs churn: AGENTS.md and every README name v2/main as the base branch and describe main as legacy. All of it inverts; the board-conventions section needs a full pass.
• AGENTS.md board table is already stale — it documents a SDK V2 + New Spec status (1bbb6f57) that no longer exists on Add tab and approval flow for server -> client sampling #28. Re-verify the whole option table while in there.
• Labels and boards: the v2 label becomes noise — retire it, or invert to a v1 label. Archive project get tools working #11; Add tab and approval flow for server -> client sampling #28 becomes the only board.
• Dependabot / CodeQL / any workflow or integration pinned to a branch name.
• External permalinks: blob/main/... links will silently resolve to the v2 tree. Re-pin anything that must keep pointing at v1 to the 1.0.1 tag or v1/main.
• Release notes must call out the Node engine bump (>=22.7.5 → >=22.19.0) — a real, if mild, breaking change.
• Announcement: GitHub release notes, MCP community channels, and the docs site landing together.

[cliffhall]

Two items for this phase, found during phases 1–4

1. Branch protection requires a reviewer the project does not have

Both default-branch rulesets (2749948, 3187937, each targeting ~DEFAULT_BRANCH) require:

required_approving_review_count: 1
require_code_owner_review:       true

and there is no CODEOWNERS file anywhere in the repo (CODEOWNERS, .github/CODEOWNERS, docs/CODEOWNERS all absent). The same shape was cloned onto v1/main in phase 1 (19858989).

The consequence is that every merge goes through --admin bypass: #1827, #1828, #1829 on v1/main and #1830, #1831, #1832 on main all did. A required check that nothing can satisfy is worse than no check — it reads as protection while making bypass the routine path.

⚠️ Note the fix is not a CODEOWNERS file. GitHub forbids approving your own PR, so for a single maintainer required_approving_review_count: 1 is unsatisfiable regardless of who the code owner is — naming yourself in CODEOWNERS changes nothing, and dropping require_code_owner_review alone still leaves the count. The options are:

1. A second reviewer with write access — the only path that satisfies the rule as written. Organizational, not technical.
2. Align the rulesets with reality — drop the approval requirement on the default branch and rely on the required build check plus admin discipline. Honest, but weaker.
3. Leave it and accept routine bypass — the current de facto state, which should at least be a decision rather than an accident.

Deliberately not changed during phases 1–4: editing rulesets immediately before an irreversible npm publish adds risk without removing the need to bypass. Recording it here so it is resolved as a considered choice.

2. Dependabot backlog — deferred, with reasoning

72 open alerts as of 2026-07-28:

Scope	Count	Severities
runtime (ships to users)	38	14 high, 21 medium, 3 low
development (never ships)	34	3 critical, 22 high, 5 medium, 4 low

Why they do not block the 2.0.0 release (#1818): 2.0.0 ships the same dependency tree v2/main has carried all along. The swap changed nothing about it — main simply began reporting alerts it had never scanned before. Nothing regressed; visibility changed.

On the three criticals: all are @vitest/browser, development scope. The published files allowlist is clients/*/build + clients/web/dist + scripts/install-clients.mjs, so dev dependencies are never in the tarball. They are not user-facing.

One was investigated properly rather than triaged by severity — GHSA-frvp-7c67-39w9 (@hono/node-server, path traversal in serve-static), because the Inspector calls that exact function in its prod web server. Result: the advisory blocks .. escapes, so it only reaches files inside the static root by bypassing prefix-mounted middleware; here that root is the public SPA bundle and the only prefix middleware (/api/*) is a separate route, not a subdirectory. No auth bypass, no arbitrary read, Windows-only. Upgraded anyway in #1832 since it proved free.

The plan:

1. Ship 2.0.0 (go-live 5/9: publish 2.0.0 (rc under next first; rollback plan written first) #1818) on the current tree — no dependency changes in the release PR, so the publish diff stays minimal and reviewable.
2. After the release, let Dependabot open its own PRs and land the transitive bumps in batches. Most of these are lockfile-only and resolve together.
3. Re-audit the runtime-scope set specifically once the noise clears — those are the ones that reach users via npm install. Current runtime offenders: fast-uri (12), hono (15), @hono/node-server (fixed), qs, ip-address, yaml, body-parser, postcss.
4. Treat dev-scope alerts as low priority by policy, and consider documenting that so future criticals in test tooling do not trigger a fire drill.

The general lesson worth keeping: severity alone was a poor triage signal here. The three criticals were unshippable dev tooling; the one alert genuinely worth reading in full was a medium.