pi-gauntlet 7.36.0 → 7.37.0

package/CHANGELOG.md

@@ -1,5 +1,18 @@
 # 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
+
+- Claude Code marketplace installs no longer register pi-only personas. A versionless plugin manifest disables default agent discovery while the marketplace retains the six portable skills and owns the release version. Real Claude startup and cached-upgrade tests gate releases; pi persona files and installation behavior are unchanged.
+
 ## v7.36.0 - 2026-10-26
 
 ### Added

package/README.md

@@ -229,7 +229,9 @@ Invocation: `/gauntlet:shape-ticket` (or bare `/shape-ticket` when unambiguous).
 
 Updates: the plugin's marketplace `version` equals the npm version; the release
 script writes it on every release, so Claude Code sees each release as a new
-plugin version. Third-party marketplaces do not auto-update by default - run
+plugin version. `.claude-plugin/plugin.json` intentionally omits `version`, so
+it cannot override the marketplace's release version. Third-party marketplaces
+do not auto-update by default - run
 `claude plugin update gauntlet@pi-gauntlet` or turn on auto-update for the
 marketplace in `/plugin`. `claude update` updates Claude Code itself, not plugins.
 
@@ -246,6 +248,20 @@ exact repo folder* in interactive Claude Code. Trusting a parent folder,
 
 ### Smoke test
 
+`npm test` runs the pinned Claude Code development dependency against disposable
+Git marketplaces and isolated homes. It checks actual session inventories for
+fresh installs and cached upgrades: zero gauntlet agents, exactly the six skills,
+and native helper availability. Negative controls reproduce the agent leak,
+manifest conflict, and full-skill scan. No credentials or model responses are
+used; artifacts remain under the printed temp directory. Run it separately with
+`node scripts/claude-plugin-smoke.test.mjs`; `CLAUDE_BIN` selects another binary
+for compatibility testing. This test gates local releases and CI publication.
+
+Use the interactive smoke below to check model-driven skill behavior and helper
+execution before a Claude packaging release. For a candidate that is not yet
+published, add its local marketplace checkout in an isolated `CLAUDE_CONFIG_DIR`
+instead of the GitHub source. Stop before tracker writes.
+
 1. Create a scratch repo and add the marketplace config:
 
        mkdir -p /tmp/cc-smoke/.claude && cd /tmp/cc-smoke && git init
@@ -289,8 +305,12 @@ exact repo folder* in interactive Claude Code. Trusting a parent folder,
     pi-gauntlet (strict mode if available). Expected: no schema errors.
 11. Agent check: type `@gauntlet:` in the mention typeahead (or open the
     plugin's details). Expected: the plugin registers no agents - `"agents": []`
-    in the marketplace entry suppresses the default `agents/` scan of the
-    repo's pi personas.
+    in `.claude-plugin/plugin.json` suppresses the default `agents/` scan of the
+    repo's pi personas. The marketplace uses `strict: true` so its skill allowlist
+    can coexist with that manifest. Keep the skill allowlist in the marketplace:
+    a manifest `skills` field adds to the default scan rather than restricting it.
+    Direct `--plugin-dir` loading of the repository bypasses the marketplace's
+    skill allowlist and is not the supported installation path.
 
 ## Project-specific overrides
 

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.0",
+  "version": "7.37.0",
   "description": "Opinionated, gated workflow skills, subagent personas, and runtime extensions for the pi coding agent.",
   "author": "Jacek Juraszek",
   "type": "module",
@@ -68,6 +68,7 @@
     "yaml": "^2.9.0"
   },
   "devDependencies": {
+    "@anthropic-ai/claude-code": "2.1.309",
     "esbuild": "0.28.2"
   }
 }

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