Scope-gate release-board attachment; follow-ups default post-release

Context

Operator friction→gold item (@tobiu, 2026-06-10 night shift, verbatim): "if close to all PRs get 'approve and follow up', and all follow up tickets get added into v13 (the board), we might never reach v13."

The mechanism is structural, not behavioral: pr-review §9 offers Approve+Follow-Up to unblock merge momentum, and ticket-create §4 mandates every agent ticket onto Project 12 during the release cycle. Composed, every merge that spawns a follow-up GROWS the release scope — the faster the swarm merges, the further the release recedes.

Live latest-open sweep: checked the latest 20 open issues at 2026-06-10T20:2xZ — no equivalent. A2A claim sweep (last-step): no competing claims in the herd window; this conversion is operator-routed to the lead.

Board evidence (V-B-A, gh project item-list 12, 2026-06-10T20:25Z): 849 items total — 828 Done, 14 Todo, 7 In Progress. The 21 open items match the operator's "20–30 left" estimate, so the board is currently tight — the problem is the derivative: tonight alone the swarm filed 4 board-attached tickets in ~2 hours (#12851, #12856, #12861, #12862), with a 5th follow-up spawned by a fresh Approve+Follow-Up review. Inflow ≈ drain rate → asymptote. The standing exhibit: #10321 — titled "deferred until v13 ships" — sits ON the v13 board.

Release classification: ON the board — this ticket changes how the release board converges, so it blocks the release process by definition (the classification test applied to itself).

The Problem

"Created during the v13 cycle" ≠ "required for v13". ticket-create §4's unconditional attachment conflates the two. Follow-up refinements, hypothesis validations, post-release hardening — none are release blockers, yet all land on the board. The invariant that resolves it cleanly:

A follow-up that must land before release contradicts the Approve+Follow-Up verdict that spawned it. The verdict certifies "shippable without it" — so its follow-ups are post-release by construction. If the gap is release-blocking, the correct verdict was Request Changes.

The Architectural Reality

• .agents/skills/ticket-create/references/ticket-create-workflow.md §4 — "Project attachment is MANDATORY on every ticket during the v13 release cycle." The rule already carries its own revision anticipation: "Sunset condition: once v13 ships, this rule needs disposition review." This ticket IS that review, arriving early because the rule's failure mode arrived early.
• .agents/skills/pr-review/references/pr-review-guide.md §9 verdict 2 (Approve+Follow-Up) — names "better-tracked-separately" but is silent on WHERE the follow-up tracks (board vs backlog).
• First applied instance (filed minutes before this ticket): #12864 — Approve+Follow-Up-born hardening from PR #12859's review, deliberately filed boardless with its classification stated in-body.

The Fix

1. ticket-create §4 rewrite — from unconditional mandate to a scope judgment with two named defaults:
   • Attach to the release board IFF the ticket blocks or belongs to the release (bugs in release-scoped subsystems, ship-hardening, release-process work).
   • Approve+Follow-Up-born tickets, hypothesis validations, and post-release hardening default boardless, with a one-line Release classification: statement in the ticket body (greppable; reviewable; reversible by the operator).
2. pr-review §9 verdict-2 addition (one sentence + the invariant): follow-ups born of Approve+Follow-Up default off the release board; a release-blocking gap means the verdict was wrong — use Request Changes.
3. One-time board triage (operator-owned, lead-assisted): a pass over the current 21 open items reclassifying deferred/post-release entries off the board (e.g. #10321). Board mutations are visible and reversible.

Decision Record impact

none (no ADR governs release-board mechanics; §4's own sunset note anticipated this revision).

Acceptance Criteria

• AC1: ticket-create-workflow.md §4 carries the scope-gate (judgment + two named defaults + the Release classification: body line), replacing the unconditional mandate; the §4 anti-pattern table row updated to match.
• AC2: pr-review-guide.md §9 verdict 2 carries the post-release default + the contradiction invariant (≤2 sentences).
• AC3: Implementing PR includes the §1.1 slot-rationale (both files are skill substrate; net-bytes ≈ neutral — the §4 rewrite replaces existing prose).
• AC4 (operator-owned, post-merge): one-time triage pass over current open board items; deferred-class entries (e.g. #10321) moved off.

Out of Scope

• Removing board attachment generally (the board stays the release SSOT).
• Tooling enforcement (a create_issue-side lint on the classification line) — revisit if judgment-drift appears.
• The #12856 dedup-gate lineage (separate concern, same file).

Avoided Traps

• ❌ A "post-v13" status column on the board — keeps the noise visible on the release surface; boardless + greppable classification line is cleaner and reversible.
• ❌ Taxonomy of ticket classes — two named defaults + judgment beats a category system nobody maintains.
• ❌ Auto-classification by label — labels describe content, not release intent; the intent statement belongs to the creator's judgment, reviewable in the body.

Related

• #12864 — first applied instance (boardless Approve+Follow-Up follow-up).
• #12856 / PR #12858 — the sibling §1a gate shipped tonight (same file, different section).
• #10321 — the standing exhibit.
• PR #12859 review PRR_kwDODSospM8AAAABCoKPBg — the live Approve+Follow-Up that triggered the operator's observation.

Origin Session ID: 00ab373d-0219-4093-948b-f9d30ecd4c7b

Retrieval Hint: "release board scope-gate Approve+Follow-Up post-release default v13 asymptote"