specpi 0.31.0 → 0.32.0

package/CHANGELOG.md

@@ -1,5 +1,18 @@
 # Changelog
 
+## 0.32.0 - 2026-09-23
+
+- Send less on every request. SpecPi's first request was 14,022 characters against Pi's 5,521, and that overhead rides every turn and is never removed by compaction. Measured again with all eight pins, the interactive default is now 11,119. A headless session drops the two tools below as well, which the measured parts put at about 8,300: SpecPi's overhead falls from 8,501 characters to about 2,800.
+- Trim the installed working agreement from about 2,400 characters to 1,300, keeping the rules that shape ordinary work, including the restraint that wins `sanitize-git-repo` on Terminal-Bench. The `/scope` rule moves into the scope notice SpecPi already adds while scope is active. The wishlist and credential rules already live in the improvement skill, and the web and browser rule now lives in `request_capability`'s own description.
+- Offer `report_capability_gap` only where a report could land: collection on, or undecided in an interactive session, where its first report asks for consent. With collection off, or undecided in a headless session, it could only ever answer "Not recorded". `/wishlist on` and `/wishlist off` switch it with collection. Its four guidance lines, which repeated its description, are now one.
+- Offer `request_capability` only to an interactive session with a requestable group installed. Headless, it could only refuse. Its description is shorter too.
+- Keep the improvement skill out of the model's skill list. It only ever runs from a `/harness-improvement` selection, so the kickoff now names its file, and Pi still lists it as a command.
+- Repair `scripts/measure-context.mjs`, which failed on 0.31.0: it expected two first-party extensions and authoring tools that no longer ship by default. It now records where each Pi row's instruction characters go, section by section. The published record and charts are re-measured; Oh My Pi runs again (18.2.5), so its row is no longer carried forward.
+- Give tier 6's Pi-family harnesses compaction settings that fit the declared window. Pi's defaults compact at 7,616 tokens of a 24,000 window and try to keep 20,000, so earlier runs compacted almost every turn; plain SpecPi compacted 17-19 times on the marathon task against Pi's 5-7, because its fixed prompt took most of what was left. Runs from before this setting are not comparable.
+- Note on the evaluations page that `configure-git-webserver` measures a cleanup habit. Its checker's push never succeeded for any harness, so every pass came from a test file left in the web root. That also qualifies a claim in 0.31.0: SpecPi + Jev's self-stopped failures outnumber Pi's only because of this task. Without it they are level, 31 against 32.
+- Consider a background-task system and do not build one. In the Terminal-Bench transcripts agents already start servers with `nohup` or `&`, tool timeouts are about one in eighteen attempts, and the one task that spends minutes blocked in commands (`tune-mjcf`) times out equally in both arms. Both earlier background-task integrations were removed, and a new one would add tool schema to every request.
+- SpecPi Chat 0.15.0 needs no change: it runs Pi interactively, so both tools stay available to it, and its command menu still lists the improvement skill.
+
 ## 0.31.0 - 2026-09-22
 
 - Report Terminal-Bench 2.0 per sitting rather than per run. Bare Pi -- unchanged software, the same thirteen tasks, the same machine -- solved 21, 22, 30, 30 and 32 of 39 across five launches, so a figure from one run is not evidence about a harness. The page pools every sitting, publishes each harness's per-sitting range beside its rate, and charts the spread directly.

package/NPM_RELEASE.md

@@ -6,7 +6,7 @@ Publishing, tags, deprecation, ownership changes and GitHub Releases require exp
 
 ## Prepare
 
-1. This candidate is SpecPi **0.31.0**, paired with the Chat **0.15.0** VSIX. Browser QA **0.3.0** is already independently published; do not republish or edit its source as part of this release. Choose an unused version; update `package.json`, the dated `CHANGELOG.md` entry, README, and the website. Check Chat's version and VSIX download links. Preserve historical changelog entries.
+1. This candidate is SpecPi **0.32.0**, paired with the Chat **0.15.0** VSIX. Browser QA **0.3.0** is already independently published; do not republish or edit its source as part of this release. Choose an unused version; update `package.json`, the dated `CHANGELOG.md` entry, README, and the website. Check Chat's version and VSIX download links. Preserve historical changelog entries.
 2. Validate:
 
     ```sh

package/README.md

@@ -28,7 +28,7 @@
 
 ---
 
-SpecPi 0.31.0 is a small starting point for the [Pi coding agent](https://pi.dev/). It is one opinionated setup for how the agent should work, not a marketplace of plugins.
+SpecPi 0.32.0 is a small starting point for the [Pi coding agent](https://pi.dev/). It is one opinionated setup for how the agent should work, not a marketplace of plugins.
 
 At the center are two built-in extensions. **Scope control** keeps each task to the files it said it would touch. The **improvement loop** turns repeated friction into small, tested changes to the setup, instead of letting prompts and workarounds pile up. Around those are eight hand-picked packages, each locked to an exact version and checked before anything installs, plus **SpecPi Chat**, a VS Code panel for working alongside the agent.
 
@@ -44,7 +44,7 @@ Everything it touches is written down, versioned, and easy to undo.
 
 ## Measured context
 
-This chart shows first-call context from a clean install: all eight pinned packages, the working agreement, and the skills Pi finds. It has not been re-measured since the command guard returned to a pinned package rather than a native system. "Enabled" means browser QA, delegation, and web access are switched on, with no goal, scope, or improvement selection active.
+This chart shows first-call context from a clean install: all eight pinned packages, the working agreement, and the skills Pi finds, in an interactive session with wishlist collection undecided. A headless session, or one with collection off, also leaves out the gap report and capability request tools. "Enabled" means browser QA, delegation, and web access are switched on, with no goal, scope, or improvement selection active.
 
 The solid rows are measured by us, from the request each setup actually sends through one local test provider. That includes OpenCode, the DeepSeek Harness, and Oh My Pi, all measured as installed. The faded Codex CLI and Claude Code rows come from HarnessTax's published numbers, measured under their own setup. Treat those as a rough reference, not a head-to-head test. These are character counts. They say nothing about tokens, cost, or how well each tool does the job. The research page [breaks down the enabled setup by feature](https://tannermidd.github.io/SpecPi/research/#specpi), so you can see what each switch costs on its own.
 
@@ -52,7 +52,7 @@ The solid rows are measured by us, from the request each setup actually sends th
   <a href="https://tannermidd.github.io/SpecPi/research/#specpi">
     <picture>
       <source media="(prefers-color-scheme: dark)" srcset="https://tannermidd.github.io/SpecPi/media/context-chart-dark.svg">
-      <img src="https://tannermidd.github.io/SpecPi/media/context-chart-light.svg" width="880" alt="Bar chart of characters sent on the first model call: Pi stock 5,521, SpecPi default 15,069, OpenCode 31,043, DeepSeek Harness 31,743, SpecPi enabled 40,203, Codex CLI 41,616, Oh My Pi 65,816, Claude Code 90,460.">
+      <img src="https://tannermidd.github.io/SpecPi/media/context-chart-light.svg" width="880" alt="Bar chart of characters sent on the first model call: Pi stock 5,521, SpecPi default 11,119, OpenCode 31,043, DeepSeek Harness 31,743, SpecPi enabled 35,767, Codex CLI 41,616, Oh My Pi 66,708, Claude Code 90,460.">
     </picture>
   </a>
 </p>
@@ -64,7 +64,7 @@ The gap between the two SpecPi bars comes from a few separate switches, so the e
   <a href="https://tannermidd.github.io/SpecPi/research/#specpi">
     <picture>
       <source media="(prefers-color-scheme: dark)" srcset="https://tannermidd.github.io/SpecPi/media/capability-chart-dark.svg">
-      <img src="https://tannermidd.github.io/SpecPi/media/capability-chart-light.svg" width="880" alt="Bar chart of tool-schema characters each capability adds: Pi built-ins 2,896, Improvement loop 4,214, Goals 1,315, Browser QA 8,046, Delegation 4,453, Web access 11,298. Browser QA, Delegation, Web access are hidden until switched on.">
+      <img src="https://tannermidd.github.io/SpecPi/media/capability-chart-light.svg" width="880" alt="Bar chart of tool-schema characters each capability adds: Pi built-ins 2,896, Improvement loop 1,601, Capability request 995, Goals 1,315, Browser QA 8,234, Delegation 4,453, Web access 11,298. Browser QA, Delegation, Web access are hidden until switched on.">
     </picture>
   </a>
 </p>

package/SECURITY_MODEL.md

@@ -10,7 +10,7 @@ Scope records use Pi's current session branch. Restoring a branch does not creat
 
 ## Capability requests
 
-Optional tool groups ship withdrawn. The `request_capability` tool lets the model name a withdrawn group instead of silently working around it; it never grants one. Activation requires a human decision, either accepted in the moment or recorded earlier as a standing grant, so the tool refuses in headless sessions and a declined prompt leaves the session unchanged. Activation is additive, offers only the named group's tools, and lasts for the session: it writes no startup preference, and the next session starts from the saved preference as before. Delegation is not requestable, because its own package requires a human command to bind a model. Acceptance offers the tools; it is not a per-call permission, and the Permission System continues to govern what those tools may do.
+Optional tool groups ship withdrawn. The `request_capability` tool lets the model name a withdrawn group instead of silently working around it; it never grants one. Activation requires a human decision, either accepted in the moment or recorded earlier as a standing grant, so the tool is not offered in headless sessions or when no requestable group is installed, refuses if called without an interactive user, and a declined prompt leaves the session unchanged. Activation is additive, offers only the named group's tools, and lasts for the session: it writes no startup preference, and the next session starts from the saved preference as before. Delegation is not requestable, because its own package requires a human command to bind a model. Acceptance offers the tools; it is not a per-call permission, and the Permission System continues to govern what those tools may do.
 
 `/capability allow <name>` records a standing grant so that group is offered without a prompt, and `/capability ask <name>` returns it to prompting. Recording either requires an interactive human command, and a grant that fires still announces itself in the session. Grants live in `<agent-dir>/specpi/capabilities/settings.json`, written atomically with owner-only permissions; links and irregular files are refused, and an unreadable file, a foreign schema or an unknown capability name reads as no grant. A standing grant removes the prompt, not the requirement for a human: headless sessions are still refused, so a granted capability cannot be activated by an unattended run. It also does not offer the group at startup — the model must still ask, and the group stays withdrawn until it does.
 
@@ -62,7 +62,7 @@ As of 0.3.0 the guard resolves its key the way the advisor does and the way Pi r
 
 ## Improvement authority and evidence
 
-Collection is off by default. Enabling it permits sanitized gap observations, not implementation. Only an exact human `/harness-improvement` selection authorizes a wishlist-sourced change. The selected contract is bound to the gap, source checkout, session, and selection generation. Web access tools (`web_search`, `source_check`, `fetch_content`, `get_search_content`) are hidden until a human offers them, through `/webaccess on` or by accepting a `request_capability` prompt.
+Collection is off by default. Enabling it permits sanitized gap observations, not implementation. The observation tool is offered only where a report could land: collection on, or undecided in an interactive session, where its first report asks for consent. The improvement skill is kept out of the model's skill list and is named by path only in the `/harness-improvement` kickoff. Only an exact human `/harness-improvement` selection authorizes a wishlist-sourced change. The selected contract is bound to the gap, source checkout, session, and selection generation. Web access tools (`web_search`, `source_check`, `fetch_content`, `get_search_content`) are hidden until a human offers them, through `/webaccess on` or by accepting a `request_capability` prompt.
 
 Retirement requires source registry integration, unchanged verification policy, a matching contract, bounded source snapshots, `npm run check`, and closed registered validators. Receipts distinguish machine-observed gates from model-reported acceptance evidence. Stale selections, changed source, missing evidence, and failed checks reject retirement. A validator proves only the behavior it exercises; the human remains responsible for accepting the result. The loop never commits, publishes, or installs a resulting change automatically.
 

package/extensions/tool-wishlist/authoring-tools.mjs

@@ -7,36 +7,66 @@
 // the answer is a boolean — no latency, no cost, no false positives, and nothing for a classifier
 // to route.
 //
-// `report_capability_gap` is deliberately not in this list. It is the *observation* tool and the
-// reason the improvement loop exists; withdrawing it would silently lose the friction reports the
-// loop is built to capture. It stays offered at all times.
+// `report_capability_gap` is the *observation* tool and the reason the improvement loop exists, so
+// it stays offered whenever a report could land: collection on, or undecided with a human present to
+// answer the consent prompt its first call raises. Only when nothing can be recorded is it withdrawn
+// -- collection switched off, or undecided in a headless session that can never ask. Its schema and
+// guidance were about 2.5 KB of every request, paid in exactly the sessions where it always answered
+// "Not recorded".
+
+import { fileURLToPath } from "node:url";
 
 /** Only usable while an improvement is selected. */
 export const AUTHORING_TOOL_NAMES = Object.freeze(["record_harness_contract", "finish_harness_improvement"]);
 
+/** The observation tool. */
+export const OBSERVATION_TOOL_NAME = "report_capability_gap";
+
+/**
+ * The improvement skill is hidden from the model's skill list (`disable-model-invocation`), because it
+ * only ever runs from a /harness-improvement selection. Installed resources and the npm package share
+ * the same layout, so the path is resolved from this file rather than from the agent directory.
+ */
+export function improvementSkillPath() {
+    return fileURLToPath(new URL("../../skills/specpi-improve/SKILL.md", import.meta.url));
+}
+
+/** Whether a report could be recorded in this session, which is the only reason to offer the tool. */
+export function observationToolWanted(mode, interactive) {
+    return mode === "on" || (mode === "undecided" && interactive === true);
+}
+
 /**
- * Add or remove the authoring tools without disturbing any other extension's tools. Mirrors the
+ * Add or remove named tools without disturbing any other extension's tools. Mirrors the
  * web-access gate: it only ever touches the names it owns, and it does nothing when the active set
  * already matches, so a no-op never costs the cached prompt prefix.
  */
-export function syncAuthoringTools(pi, selected) {
+function syncOwnedTools(pi, names, wanted) {
     if (typeof pi?.getActiveTools !== "function" || typeof pi?.setActiveTools !== "function") {
         return false;
     }
 
-    const owned = new Set(AUTHORING_TOOL_NAMES);
+    const owned = new Set(names);
     const active = pi.getActiveTools();
     const present = active.filter((name) => owned.has(name));
-    if (selected && present.length === owned.size) {
+    if (wanted && present.length === owned.size) {
         return false;
     }
 
-    if (!selected && present.length === 0) {
+    if (!wanted && present.length === 0) {
         return false;
     }
 
     const others = active.filter((name) => !owned.has(name));
-    pi.setActiveTools(selected ? [...others, ...AUTHORING_TOOL_NAMES] : others);
+    pi.setActiveTools(wanted ? [...others, ...names] : others);
 
     return true;
 }
+
+export function syncAuthoringTools(pi, selected) {
+    return syncOwnedTools(pi, AUTHORING_TOOL_NAMES, selected);
+}
+
+export function syncObservationTool(pi, wanted) {
+    return syncOwnedTools(pi, [OBSERVATION_TOOL_NAME], wanted);
+}

package/extensions/tool-wishlist/index.ts

@@ -13,7 +13,12 @@ import { getMarkdownTheme, type ExtensionAPI } from "@earendil-works/pi-coding-a
 import { StringEnum } from "@earendil-works/pi-ai";
 import { Box, Markdown, Text } from "@earendil-works/pi-tui";
 import { Type } from "typebox";
-import { syncAuthoringTools } from "./authoring-tools.mjs";
+import {
+    improvementSkillPath,
+    observationToolWanted,
+    syncAuthoringTools,
+    syncObservationTool,
+} from "./authoring-tools.mjs";
 import {
     appendWishlistDecision,
     archiveWishlist,
@@ -468,7 +473,7 @@ function improvementPrompt(group: any, context: ImprovementContext = {}) {
 
     lines.push(
         "",
-        "This exact menu selection authorizes implementation of the smallest sufficient intervention in the current SpecPi source checkout. Load and follow the specpi-improve skill. Treat the wishlist evidence as a lead, inspect current behavior, keep scope minimal, and do not ask for another approval unless scope expands or external/remote state would change.",
+        `This exact menu selection authorizes implementation of the smallest sufficient intervention in the current SpecPi source checkout. Read and follow the specpi-improve skill at ${improvementSkillPath()}. Treat the wishlist evidence as a lead, inspect current behavior, keep scope minimal, and do not ask for another approval unless scope expands or external/remote state would change.`,
         "First call record_harness_contract with the exact gap, selection ID, source root, proposed requirements, acceptance checks, paths, rollback, and non-goals. Run direct acceptance checks and focused tests. At the end, call finish_harness_improvement with the gap ID, concise acceptance evidence, and a validation note. That tool independently runs the repository gate, verifies registry integration and frozen policy inputs, runs supported capability validators, records a bounded local receipt, and retires the item. If any check fails, do not retire it; leave it selected and report the blocker.",
     );
 
@@ -586,9 +591,23 @@ export default function toolWishlist(pi: ExtensionAPI) {
         }
     };
 
+    // Offer the observation tool only where a report could land. Decided at session start and on an
+    // explicit /wishlist on|off, never in between, so the cached prompt prefix is not disturbed.
+    const syncObservation = (interactive: boolean) => {
+        let mode = "off";
+        try {
+            mode = readCollectionMode(stateDir);
+        } catch {
+            // An unreadable collection file cannot record anything either.
+        }
+
+        syncObservationTool(pi, observationToolWanted(mode, interactive));
+    };
+
     pi.on("session_start", (_event, ctx) => {
         restoreActiveImprovement(ctx);
         syncAuthoring();
+        syncObservation(ctx.hasUI === true);
     });
 
     pi.on("session_tree", (_event, ctx) => {
@@ -653,13 +672,10 @@ export default function toolWishlist(pi: ExtensionAPI) {
         name: "report_capability_gap",
         label: "Report Capability Gap",
         description:
-            "Privately record a material, reusable capability gap in SpecPi's local wishlist. Report only after reasonable existing tools or workarounds proved insufficient. Do not use for transient failures, command mistakes, credentials or permissions the user must supply, ordinary project-specific work, or speculative nice-to-haves. Never include secrets, source code, full commands, file paths, URLs with private data, or user prompt text. Report a gap at most once per user task. Collection requires an explicit local on/off decision. Only a separately enabled and consented Jev advisor may transmit redacted report samples.",
+            "Privately record, in SpecPi's local wishlist, a material and reusable capability gap that reasonable existing tools or workarounds could not cover. Not for transient failures, command mistakes, credentials or permissions the user must supply, ordinary project work, or speculative nice-to-haves. At most once per gap per task. Never include secrets, source code, full commands, file paths, private URLs, or user prompt text.",
         promptSnippet: "Record recurring, generalizable capability friction without interrupting the user task",
         promptGuidelines: [
-            "Use report_capability_gap only for a material and generalizable missing capability after reasonable existing tools or workarounds have proved insufficient.",
-            "Do not use report_capability_gap for transient errors, model mistakes, missing credentials or permissions, ordinary project-specific work, or speculative nice-to-haves.",
-            "Call report_capability_gap at most once per distinct gap per user task; use a short durable capability phrase without project names, and never include secrets, source code, full commands, private paths, or user prompt text.",
-            "After report_capability_gap, continue the requested task; never treat a report as permission to modify SpecPi or external state.",
+            "After report_capability_gap, continue the requested task; a report never authorizes changing SpecPi or external state.",
         ],
         parameters: Type.Object(
             {
@@ -1450,6 +1466,8 @@ export default function toolWishlist(pi: ExtensionAPI) {
 
             if (action === "on" || action === "off") {
                 await setCollectionMode({ stateDir, mode: action });
+                // A human command, so offering or withdrawing the tool now is the expected cost.
+                syncObservation(ctx.hasUI === true);
                 ctx.ui.notify(
                     `Local wishlist collection is ${action}. Jev transmission requires its own switch and consent.`,
                     "info",

package/extensions/workflow-controls/capabilities.mjs

@@ -124,6 +124,23 @@ export function capabilityInstalled(allToolNames, capability) {
     return capability.tools.some((name) => known.has(name));
 }
 
+/** The tool the model uses to ask for a withdrawn group. */
+export const CAPABILITY_REQUEST_TOOL = "request_capability";
+
+/** Whether any requestable group is installed, i.e. whether asking for one could ever succeed. */
+export function anyCapabilityInstalled(allToolNames) {
+    return CAPABILITY_NAMES.some((id) => capabilityInstalled(allToolNames, CAPABILITIES[id]));
+}
+
+/**
+ * Whether to offer the request tool at all. It can only ever ask a human, so a session without one
+ * would carry its schema for a tool that always refuses, and a session with no requestable group
+ * installed has nothing to ask for.
+ */
+export function capabilityRequestOffered({ interactive, allToolNames }) {
+    return interactive === true && anyCapabilityInstalled(allToolNames);
+}
+
 /** One catalogue line per capability, for the tool description and its error results. */
 export function describeCapabilities() {
     return CAPABILITY_NAMES.map((id) => `${id}: ${CAPABILITIES[id].summary}`).join("; ");

package/extensions/workflow-controls/index.ts

@@ -5,8 +5,10 @@ import { truncateToWidth } from "@earendil-works/pi-tui";
 import { Type } from "typebox";
 import {
     CAPABILITY_NAMES,
+    CAPABILITY_REQUEST_TOOL,
     capabilityActive,
     capabilityInstalled,
+    capabilityRequestOffered,
     describeCapabilities,
     findCapability,
     missingTools,
@@ -389,6 +391,17 @@ export default function workflowControls(pi: ExtensionAPI) {
         );
     });
 
+    // Decided once per session, before the first request, so the cached prompt prefix is never
+    // disturbed. See capabilityRequestOffered for why a session may not need the tool at all.
+    const applyCapabilityRequest = (ctx: ExtensionContext) => {
+        const allToolNames = typeof pi.getAllTools === "function" ? pi.getAllTools().map((tool) => tool.name) : [];
+        syncToolGroup(
+            pi,
+            [CAPABILITY_REQUEST_TOOL],
+            capabilityRequestOffered({ interactive: ctx.hasUI, allToolNames }),
+        );
+    };
+
     // Web access ships hidden. A missing or unreadable preference means off, and the
     // gate only ever touches its own four tool names.
     let webAccessEnabled = loadStartupActivation();
@@ -397,6 +410,7 @@ export default function workflowControls(pi: ExtensionAPI) {
     pi.on("session_start", (_event, ctx) => {
         webAccessEnabled = loadStartupActivation();
         applyWebAccess();
+        applyCapabilityRequest(ctx);
         beginRestore(ctx);
     });
 
@@ -561,7 +575,7 @@ export default function workflowControls(pi: ExtensionAPI) {
         if (scope.active) {
             const taskStale = scope.taskDigest !== undefined && currentTask?.digest !== scope.taskDigest;
             guidance.push(
-                `[SPECPI SCOPE]\nDeclared paths: ${scope.entries.map((item) => `${sanitizePathLabel(item.path)}${item.directory ? "/" : ""}`).join(", ")}\nPending outside-scope paths: ${scope.pending.map(sanitizePathLabel).join(", ") || "none"}. Do not describe pending paths as accepted scope.${taskStale ? "\nTask-bound scope is stale; do not widen it automatically." : ""}`,
+                `[SPECPI SCOPE]\nDeclared paths: ${scope.entries.map((item) => `${sanitizePathLabel(item.path)}${item.directory ? "/" : ""}`).join(", ")}\nPending outside-scope paths: ${scope.pending.map(sanitizePathLabel).join(", ") || "none"}. Keep outside-scope findings pending until the human allows once, acknowledges them with /scope accept, expands scope with /scope add, or clears it. Acknowledgement does not widen scope, and pending paths are not accepted scope.${taskStale ? "\nTask-bound scope is stale; do not widen it automatically." : ""}`,
             );
         }
 
@@ -905,9 +919,9 @@ export default function workflowControls(pi: ExtensionAPI) {
     };
 
     pi.registerTool({
-        name: "request_capability",
+        name: CAPABILITY_REQUEST_TOOL,
         label: "Request Capability",
-        description: `Ask the user to restore a withdrawn SpecPi tool group for this session. Available groups — ${describeCapabilities()}. Their tools are hidden to keep each request small, and restoring one mid-session also discards the provider's cached prompt prefix, which measured about 20% of a mid-length attempt's cost in this project's own testing — so request a group only when the current task actually needs it, and continue without it if the user declines. The restored tools are usable from your next message and stay available until the session ends. Delegation is not requestable here; ask the user to run /delegate on.`,
+        description: `Ask the user to restore a withdrawn tool group for this session — ${describeCapabilities()}. Hidden tools cannot be called until restored. Ask only when the task needs one: restoring mid-session discards the cached prompt prefix, about 20% of a mid-length task's cost. Restored tools work from your next message; if the user declines, continue without them. Delegation is not requestable; ask the user to run /delegate on.`,
         parameters: Type.Object(
             {
                 capability: StringEnum(CAPABILITY_NAMES, {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "specpi",
-  "version": "0.31.0",
+  "version": "0.32.0",
   "description": "Scope control and a human-selected harness improvement loop for Pi",
   "author": "Tanner Middleton",
   "repository": {

package/skills/specpi-improve/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: specpi-improve
 description: Turns a selected SpecPi capability-gap wishlist item into a minimal, evidence-backed, reversible improvement. Use when the user asks to improve SpecPi from its wishlist, act on a selected gap, or complete the notice-to-retire loop.
+disable-model-invocation: true
 ---
 
 # SpecPi Improve

package/templates/AGENTS.md

@@ -2,11 +2,7 @@
 
 - Keep changes small, testable, reversible, and tied to the human's request. Inspect existing code and guidance before editing; avoid adjacent feature accumulation.
 - Prefer direct work and existing project tools. Ask concise questions only when material requirements are unclear.
-- Keep replies brief and human-readable. Lead with the answer, use plain language, and avoid jargon, technical babble, and repetitive progress updates. Include technical detail only when it helps the human decide or act.
-- Write commits and pull requests the same way: a short, clear title and a brief explanation of what changed, why, and what was tested. Avoid boilerplate, inflated claims, and unnecessary implementation detail.
-- When `/scope` is active, keep outside-scope findings pending until the human allows once, acknowledges them with `/scope accept`, expands scope with `/scope add`, or clears it. Acknowledgement does not widen scope.
-- Treat wishlist observations as leads, not authorization. Start a wishlist-sourced change only from an exact `/harness-improvement` selection and follow `specpi-improve`. Record its contract before editing and retire only after its verification gate passes.
-- Web access and Browser QA tools ship hidden to keep each request small. When the task genuinely needs one, call `request_capability`; it asks the human, who may decline. Continue without the capability if they do, and do not attempt a hidden tool. The human can also run `/webaccess on` or `/browser on` directly. Delegation is not requestable this way; ask the human to run `/delegate on`.
-- Never inspect Pi authentication, provider credentials, trust decisions, sessions, missions, or history to improve the harness. Use only the active extension context and intended local improvement records.
+- Keep replies brief and human-readable: lead with the answer, use plain language, avoid jargon and repetitive progress updates, and include technical detail only when it helps the human decide or act.
+- Write commits and pull requests the same way: a short, clear title and a brief note on what changed, why, and what was tested.
 - Use observed files, diffs, tests, and runtime behavior as evidence. Run relevant checks, inspect the final diff, and obtain fresh read-only review when risk warrants it. Report results and residual risks without claiming more than the checks prove.
 - Do not commit, push, publish, deploy, or alter remote state unless explicitly requested.