brainstorm: re-dispatch grounding-check on any post-PASS spec edit

Closes the P1 todo from earlier today: Step 7.5 PASS report is
bound to the exact bytes of the spec at dispatch time. Any
subsequent edit — wording polish, user-requested change, anything
— invalidates the report and forces a fresh dispatch before the
Step 8 commit.

Three edits:
- Step 7.5 gets a 'Re-dispatch on any post-PASS edit' subsection
  stating the rule and explaining why (PASS attests to bytes).
- Step 8 wording: '... edit in place, re-run Step 7 AND re-dispatch
  Step 7.5, then return here. Only proceed after approval AND a
  fresh Step 7.5 PASS.'
- Common Rationalisations + Red Flags gain matching entries
  ('just polishing wording, no need to re-dispatch' / 'Editing the
  spec after PASS without re-dispatching').

Roadmap P1 todo retired with this commit.

docs/roadmap.md

@@ -49,22 +49,6 @@ context. Pick the next milestone from P1.)_
   has neither instance by design; polymorphic helpers at Float fire
   Float-aware `NoInstance` per DESIGN.md §"Float semantics".
 
-- [ ] **\[todo\]** Brainstorm Step 7.5 — Grounding-check is the *last*
-  step before the spec is committed. Any post-PASS edit to the spec
-  (Boss-side polish, user-requested change, anything) must
-  re-dispatch `ailang-grounding-check` before the commit. Today the
-  skill's Step 7.5 + Step 8 wording allows a "fix issues inline and
-  re-run Step 7" loop *without* re-running Step 7.5 — closes the
-  loop on linguistic self-review only, not on grounding. Update
-  `skills/brainstorm/SKILL.md`: any change to the spec file after
-  the grounding-check PASS report invalidates that report and
-  requires a fresh dispatch before Step 8 commit.
-  - context: surfaced 2026-05-12 during iter rt.1 planning — Boss
-    edited the roundtrip-invariant spec to add acceptance #7
-    ("tests are pure readers") *after* the PASS report from
-    `ailang-grounding-check`, then committed the spec without a
-    re-dispatch. User flagged the skill gap that allowed this.
-
 - [ ] **\[milestone\]** Post-22 Prelude — Show + print rewire — ship
   `Show` typeclass with `Show Int/Bool/Str/Float` instances; rewire
   `print` through `Show.show`. Gated on heap-`Str` ABI runtime work

skills/brainstorm/SKILL.md

@@ -197,6 +197,15 @@ There is no Step 8, no Step 9. The idea is parked until the
 dependency ships, at which point a fresh brainstorm session
 re-derives the spec from scratch.
 
+**Re-dispatch on any post-PASS edit.** The grounding-check PASS
+report is bound to the exact bytes of the spec at dispatch time.
+Any subsequent edit to the spec file — Boss-side polish, a
+user-requested change in free chat, a wording tighten, anything —
+invalidates the PASS report and requires a fresh dispatch of
+`ailang-grounding-check` before Step 8 commit. Step 7.5 is the
+*last* step that touches the spec file; nothing slips between it
+and the commit.
+
 ### Step 8 — User-review gate
 
 The spec sits in the working tree as an unstaged file. Tell the user:
@@ -206,8 +215,10 @@ The spec sits in the working tree as an unstaged file. Tell the user:
 > plan. The Boss will commit it once you approve.
 
 Wait for the user's response. If they request changes, edit the
-file in place (still uncommitted) and re-run Step 7. Only proceed
+file in place (still uncommitted), **re-run Step 7 AND re-dispatch
-to the next step after approval.
+Step 7.5** (the previous PASS report no longer covers the edited
+bytes), then return here. Only proceed to the next step after
+approval AND a fresh Step 7.5 PASS.
 
 The Boss commits the approved spec after the user signs off
 (suggested commit subject: `spec: <milestone> <topic>`). The
@@ -242,6 +253,7 @@ Hand off carries:
 | "User is busy, present my own design without Q&A" | Reactive deference disguised as decisiveness. The Q&A surfaces constraints the user hasn't articulated; skipping it means shipping the user's defaults, not their intent. |
 | "Spec exists from previous milestone, append to it" | New milestone = new spec file. The architect agent reads spec files per milestone; mixing scopes makes drift review unreadable. |
 | "Approaches A, B, C are all bad — proceed with A" | This is exactly the moment to surface "the problem is mis-framed" rather than ratify a known-bad shape into DESIGN.md. JOURNAL the impasse, escalate to user. |
+| "Just polishing a wording after PASS, no need to re-dispatch" | The grounding-check report attests to specific bytes. A polish edit changes the bytes; the previous attestation no longer covers them. Re-dispatch is cheap; the alternative is a commit with an attestation that doesn't match the file. |
 
 ## Red Flags — STOP
 
@@ -250,6 +262,7 @@ Hand off carries:
 - "User said it's clear, who am I to push back"
 - "The 2-3 approaches all suck, just pick one"
 - Skipping Step 7 self-review because "I wrote it carefully"
+- Editing the spec file after a Step 7.5 PASS without re-dispatching
 - Jumping straight from spec to `implement` (must go via `planner`)
 - Inventing a design rationale that's actually about effort, not
   semantics