From 90512d5d8956d7371500268e325204ed430597dc Mon Sep 17 00:00:00 2001 From: Brummel Date: Tue, 12 May 2026 09:46:56 +0200 Subject: [PATCH] brainstorm: re-dispatch grounding-check on any post-PASS spec edit MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 | 16 ---------------- skills/brainstorm/SKILL.md | 17 +++++++++++++++-- 2 files changed, 15 insertions(+), 18 deletions(-) diff --git a/docs/roadmap.md b/docs/roadmap.md index 34e4251..f3bca06 100644 --- a/docs/roadmap.md +++ b/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 diff --git a/skills/brainstorm/SKILL.md b/skills/brainstorm/SKILL.md index de19fbb..1e80f8d 100644 --- a/skills/brainstorm/SKILL.md +++ b/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 -to the next step after approval. +file in place (still uncommitted), **re-run Step 7 AND re-dispatch +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: `). 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