pi-gauntlet 7.8.0 → 7.8.2

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # Changelog
 
+## v7.8.2 - 2026-10-11
+
+### Changed
+
+- Spec council `over-spec` review covers unrelated extras and sufficient in-scope simplifications, while protecting human-selected mechanisms and indispensable coverage.
+
+## v7.8.1 - 2026-10-11
+
+### Changed
+
+- `brainstorming`: the checklist now instructs same-turn continuation after a user answer or completed side task, advancing only when required decisions and approvals are satisfied. Unanswered questions, pending human approvals, explicit pauses, and required-tool/resource blockers still stop progress.
+
 ## v7.8.0 - 2026-10-09
 
 ### Changed

package/README.md

@@ -100,7 +100,7 @@ Run by a human against pi-cohort >= 7.1.0, before a pi-gauntlet release claims t
 | Term | Meaning |
 | --- | --- |
 | Gate | A machine-enforced checkpoint between phases (e.g. within a brainstorming-entered flow, `complete verify` is blocked until conformance review has run). Not a suggestion. |
-| Spec council | Multi-model critique of the spec before you see it (`roasting-the-spec`); members also name spec clauses nobody asked for and nothing needs (`over-spec`) so they are cut before planning, every member closes with a `lean:` line - "nothing to cut" is a first-class answer - and the chair tallies them (`lean: <k> of <n> members found nothing to cut`). Falls back to a single-model critique if no council is configured. |
+| Spec council | Multi-model critique of the spec before you see it (`roasting-the-spec`); members also flag unrelated extras or sufficient in-scope simplifications (`over-spec`) for cuts or replacements before planning, every member closes with a `lean:` line - "nothing to cut" is a first-class answer - and the chair tallies them (`lean: <k> of <n> members found nothing to cut`). Falls back to a single-model critique if no council is configured. |
 | Conformance gate | The closing check: does the delivered code + docs match your *original prompt*, not the derived plan? Compatible executable recommendations auto-fix first; anything still open renders as a dense one-line-per-decision list with each recommended choice inline. Reply `1` to accept all recommendations or `2:` with per-item overrides; a current `CONFORMS` / no-concerns handoff goes straight to branch options with no extra sign-off. |
 | Wave | A batch of plan tasks that don't touch the same files, dispatched to implementers in parallel. |
 | Overrides file | `.pi/gauntlet-overrides.md` - where you put project-specific detail the generic skills don't know (CI command, worktree wrapper, routing rules). |

package/agents/spec-council-member.md

@@ -63,9 +63,9 @@ lean: nothing to cut | <N> over-spec findings above
 
 **`over-spec`.** Flag a clause only when all three are true:
 
-1. It is clearly outside the stated problem.
-2. Nothing in the `Human input` block of your task asks for it. Never flag text that appears in that block.
-3. The feature ships correctly without it. Needed-but-unasked is not a finding.
+1. Identify an unrelated extra or name a simpler implementation or proof alternative and show why it preserves the requirements. Cost or style alone does not establish sufficiency.
+2. Match the proposed removal or replacement against the supplied `Human input`: protect explicitly required mechanisms and proof techniques, not an agent's choice of mechanism for a requested outcome.
+3. Show that the proposed cut or replacement preserves required behavior, coverage, and safety. Retain a needed clause without an adequate smaller replacement.
 
 Any test fails -> not a finding. Unsure on 2 -> not a finding. `Human input` block missing or empty -> no over-spec findings, `lean: nothing to cut`. One line per finding:
 
@@ -73,7 +73,7 @@ Any test fails -> not a finding. Unsure on 2 -> not a finding. `Human input` blo
 - [major|minor] over-spec @ "<quoted spec clause>" — no human input requires this (closest human input: "<quote>" | none); adds: <M> files / <N> tests / <K> ACs; if cut, unprotected: <failure | nothing> → cut | shrink to <replacement>
 ```
 
-`major` = buys >= 1 new file or >= 3 tests; else `minor`; never `blocker`. `adds:` = your estimate of the surface the clause forces. `unprotected:` = the failure nobody catches once the clause is gone; `nothing` is a valid answer. `closest human input:` quotes the `Human input` block, never the spec.
+`major` = buys >= 1 new file or >= 3 tests; else `minor`; never `blocker`. `adds:` = your estimate of the surface the clause forces. `unprotected:` = the remaining uncovered failure after the proposed cut or replacement; `nothing` is a valid answer. `closest human input:` quotes the `Human input` block, never the spec.
 
 Finding: spec says "S6: compute a `checksum` over child names, expose `meta.checksum`, add a reconciliation job flagging mismatches"; the human input said "return the folder tree as JSON like the HTML view"; nothing else in the spec depends on S6 -> `- [major] over-spec @ "S6 ... reconciliation job" — no human input requires this (closest human input: "return the folder tree as JSON like the HTML view"); adds: 2 files / 6 tests / 1 AC; if cut, unprotected: nothing → cut`. Non-finding: spec adds `format: false` on three compliance route mounts; nobody asked, but without it `.json` suffixes 404 on those mounts, so the JSON view cannot be delivered - leg 3 fails, not over-spec.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-gauntlet",
-  "version": "7.8.0",
+  "version": "7.8.2",
   "description": "Opinionated, gated workflow skills, subagent personas, and runtime extensions for the pi coding agent.",
   "author": "Jacek Juraszek",
   "type": "module",

package/skills/brainstorming/SKILL.md

@@ -32,7 +32,7 @@ Treat the flag as discovery control, not harness authorization. The command reli
 
 ## Checklist
 
-Work through the items below **in order**. This is your own checklist to follow, not a `plan_tracker` plan — brainstorming is open-ended exploration, and `plan_tracker` is execution-only (the implement phase). The terminal state is the user review gate; after approval the **only** next skill is `/skill:writing-plans`. Do not jump to implementation, and do not silently drop the critique pass.
+Work through the items below **in order**. After a user answer or completed side task, resume the current checklist step and perform the next authorized action in the same turn, advancing once that step's required decisions and approvals are satisfied. Continue until a required question is unanswered, an existing approval is pending, the user explicitly pauses, or a failed required tool or unavailable required resource blocks progress. This is your own checklist to follow, not a `plan_tracker` plan — brainstorming is open-ended exploration, and `plan_tracker` is execution-only (the implement phase). The terminal state is the user review gate; after approval the **only** next skill is `/skill:writing-plans`. Do not jump to implementation, and do not silently drop the critique pass.
 
 1. **Start brainstorm tracking (fresh epoch)** - as the first action on authorized fresh entry, before reading code, the worktree, or answering the user, reset both trackers and start the phase. A new brainstorm owns a clean slate, so stale phases and tasks from earlier work are cleared; re-entering mid-brainstorm is safe (nothing to lose, same clean slate):