pi-gauntlet 7.36.1 → 7.37.0

package/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## v7.37.0 - 2026-10-27
+
+### Changed
+
+- Brainstorming favors changes to an existing shared path over caller-side copies, names the shared helper and its gap, and orders each approach's `Removes:` before `Adds:`. The chosen removals and additions become Design imperatives, and round two maps each acceptance observable and Design edge or error clause to a test.
+- Code review flags a test that proves no spec-named observable with a `[Moderate]` `delete:` finding citing the spec section. Acceptance rows and Design clauses, including preservation obligations, justify tests; task-summary-only behavior does not. Without a supplied spec, the check reports unverified rather than recommending deletion on spec grounds.
+
 ## v7.36.1 - 2026-10-27
 
 ### Fixed

package/agents/code-reviewer.md

@@ -15,6 +15,7 @@ You are a code reviewer. You find issues before they ship. You **do not edit cod
 
 1. **Correctness** — Does the change do what it claims? Are edge cases handled? Off-by-one, null/undefined, empty input, concurrency.
 2. **Tests** — Is the new behavior covered? Are tests meaningful, or do they only assert type shape? Name any missing behavior worth a test concretely; never a reflexive "add edge cases". Then check added **and changed** tests for economy - each of these is a `[Minor]` finding the implementer may decline with a reason, except the last:
+   - Read the supplied spec's `## Acceptance criteria` and `## Design` sections first, from the requirements block or its named spec path. Report a test proving no observable those sections name as `[Moderate]` `delete:`, overriding the Minor default, and cite the spec section searched. Exempt a test only on a justification citing the approved acceptance row or Design clause it proves, including a `Keep:` preservation obligation or edge rule; treat summary-only behavior as uncommitted and route genuinely new behavior through the existing scope decision. Preserve the single smoke test or `assert`-based self-check exemption. With no spec supplied, report `unverified: no spec supplied`, keep the existing economy checks, and never treat the missing spec as an empty observable set.
    - several new tests repeat one setup and operation with the assertions split across them -> `shrink:` to one test with the assertions together.
    - a new test repeats an existing test's assertions -> `delete:`.
    - equivalent cases written as separate tests -> `shrink:` to one table with named rows.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-gauntlet",
-  "version": "7.36.1",
+  "version": "7.37.0",
   "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

@@ -138,15 +138,15 @@ Recommendation: B - the owning schema already exists.
 
 In a separate message after the premise note, restate each implicit dependency recorded as missing or not checkable, with its lookup and result, before presenting any approaches.
 
-Propose 2-3 genuinely distinct approaches and name what separates them (the axis), comparing them on explicit trade-offs. Consider two candidates in every set: the minimal reuse-only option (no new construct) and an option that drops an assumption the ask makes which the framing reply, if any, did not settle; list each when viable, otherwise state in one sentence with evidence why not (`reuse-only: not viable - the only existing path is the one identified as debt`); a non-viable candidate is not an approach and does not count toward the 2-3. End each approach with `Pattern: <what it follows or cuts across, cited to a repo location>` - judge against sound engineering practice first, then repo rules; when the repo's own convention is the debt, say so, and never recommend an approach that extends it - unless the framing reply or an adopted ticket decision kept the ask as framed: then recommend the best as-framed approach and name the debt in its `Pattern:` line. A `Pattern:` line names things like a band-aid over a shared contract, a second settings path beside the owning one, or a layer bypassed for one caller - the judgment comes from the repo and your own engineering knowledge, not a list. Lead with the recommendation and end with the condition that would flip it. Use conversational prose unless the user asks for a table.
+Propose 2-3 genuinely distinct approaches and name what separates them (the axis), comparing them on explicit trade-offs. Consider two candidates in every set: the minimal reuse-only option (no new construct) and an option that drops an assumption the ask makes which the framing reply, if any, did not settle; list each when viable, otherwise state in one sentence with evidence why not (`reuse-only: not viable - the only existing path is the one identified as debt`); a non-viable candidate is not an approach and does not count toward the 2-3. End each approach with `Pattern: <what it follows or cuts across, cited to a repo location>` - judge against sound engineering practice first, then repo rules; when the repo's own convention is the debt, say so, and never recommend an approach that extends it - unless the framing reply or an adopted ticket decision kept the ask as framed: then recommend the best as-framed approach and name the debt in its `Pattern:` line. A `Pattern:` line names things like a band-aid over a shared contract, a second settings path beside the owning one, or a layer bypassed for one caller - the judgment comes from the repo and your own engineering knowledge, not a list. Lead with the recommendation and end with the condition that would flip it. Use conversational prose unless the user asks for a table. Ground reuse-only in the shared paths the gather step verified: when one nearly fits the ask, name that path and the behaviors it lacks, and propose changing it; a parameter, branch, or discriminant on that construct is a reuse-only change under `Adds:`. A nearly-fitting path with other callers stays the reuse-only candidate; disclose its blast radius in the trade-offs and `Pattern:` line. Evidence nonviability with path+gap or searched paths/why none fits, never size/line-count alone. List moving parts (files, types, helpers, signatures, settings, test files, inline copies, call sites) as `Removes: <parts or none>` then `Adds: <parts or none>`, separate lines directly before `Pattern:`.
 
 ### 5. Design for clarity and isolation
 
-Prefer clear testable boundaries, YAGNI, existing conventions when they are sound - when the convention is the debt, say so and do not extend it - the owning schema/contract rather than parallel state, and explicit errors and edge cases. Retain every existing user-approved design detail in approaches and design, including supplied presentation details in the design recap and when drafting or replacing the spec.
+Prefer clear testable boundaries, YAGNI, existing conventions when they are sound - when the convention is the debt, say so and do not extend it - the owning schema/contract rather than parallel state, and explicit errors and edge cases. Retain every existing user-approved design detail in approaches and design, including supplied presentation details in the design recap and when drafting or replacing the spec. Value removal equally with addition; recommend viable reuse-only unless naming an approved requirement it cannot meet. Never recommend copying a nearly-fitting shared path beside the caller, cited or not, unless section 4's as-framed decision applies; then name the duplication in that approach's `Adds:` and `Pattern:` lines.
 
 ### 6. Present the design in two rounds
 
-Use two rounds, targeting 300-500 words each, with one approval each; revisions remain within that approval point. Ask once per round; round-1 approval without correction confirms the predecessor. Round 1 covers architecture, responsibilities, data flow, and `supersedes <path>, <scope>` when applicable. Round 2 covers errors, edges, tests, and `## Documentation impact`. In round 2, read and apply [Documentation impact](reference/documentation-impact.md), including its verbatim template; cite that portable relative path in the spec; do not restate its categories. Ask the user when doc impact is unclear. Unreadable -> stop the step with a blocking error. Cite the draft's `Docs touched:` entries as candidates for "Materially amended existing docs"; admit or drop each by that owner's materiality bar, never list them automatically.
+Use two rounds, targeting 300-500 words each, with one approval each; revisions remain within that approval point. Ask once per round; round-1 approval without correction confirms the predecessor. Round 1 covers architecture, responsibilities, data flow, and `supersedes <path>, <scope>` when applicable. Round 2 covers errors, edges, tests, and `## Documentation impact`. In round 2, read and apply [Documentation impact](reference/documentation-impact.md), including its verbatim template; cite that portable relative path in the spec; do not restate its categories. Ask the user when doc impact is unclear. Unreadable -> stop the step with a blocking error. Cite the draft's `Docs touched:` entries as candidates for "Materially amended existing docs"; admit or drop each by that owner's materiality bar, never list them automatically. In round 1, carry chosen `Removes:`/`Adds:` into Design as exhaustive `Remove:`/`Add:` imperatives naming every moving part; route unlisted parts through `reference/amendment-surface.md`. In round 2, write `## Tests`: one `<observable> - <test name or file>` per acceptance row and Design edge/error clause; `<observable> - none: <why>` for untestable.
 
 ## Ticket Handling