pi-t3-bridge 0.4.0 → 0.5.0

package/README.md

@@ -142,7 +142,13 @@ The bridge caps every shell command at 300 seconds, in the main thread and in ch
 
 ### Stop checks
 
-When a run is about to stop, the bridge asks a classifier how the run ended. The classifier is `typesafe/jev-latest` from your Pi model catalog. When the classifier says the agent gave up partway, the bridge adds a note and gives the agent one more turn, at most twice per prompt. Every 3 turns during a run, the bridge also asks the classifier whether the agent shows a known failure, and it adds a note when one is likely. The failures it checks for come from the MAST list of agent failures:
+When a run is about to stop, the bridge asks a classifier how the run ended. It picks the classifier in this order:
+
+1. The chat model named by `classifierModel` in the config, as `"provider/modelId"`.
+2. `typesafe/jev-latest`, when it is in your Pi model catalog and you have access to it.
+3. The model of the current session.
+
+A chat model gets the same questions through one tool call, and the bridge reads its answers from the tool arguments. A chat model's probabilities are its own estimates. They are not calibrated like Jev's, and the stop thresholds were fitted on Jev, so a chat model may nudge more or less often. If Jev is available but its call fails, the bridge does not fall back to a chat model. A `classifierModel` that is not in the catalog or has no auth is an error, and the bridge does not fall back from it either. When the classifier says the agent gave up partway, the bridge adds a note and gives the agent one more turn, at most twice per prompt. Every 3 turns during a run, the bridge also asks the classifier whether the agent shows a known failure, and it adds a note when one is likely. The failures it checks for come from the MAST list of agent failures:
 
 - Stuck in a loop
 - Doesn't know when to stop
@@ -161,6 +167,8 @@ on(run about to stop)
 
 The stop check and the notes come from [pi-mast-steer](https://github.com/dbreunig/pi-mast-steer). Set `steer` to `"shadow"` in the config to log verdicts without changing the session, or to `"off"` to turn the checks off.
 
+A chat-model judge costs tokens on your account, one call per stop check and one every 3 turns.
+
 ## The pstack extension
 
 The pstack extension adds the pstack skills to Pi's skill catalog, and it adds a note to each prompt that tells the agent when to enter `poteto-mode`. `poteto-mode` picks the workflow that fits your goal, for example a bug fix, a feature, a design review, or a PR watch. The skills come from [pstack](https://github.com/cursor/plugins/tree/main/pstack) by way of [t3-pstack](https://github.com/chhoumann/t3-pstack), and they live unchanged under `pstack/`.
@@ -223,6 +231,7 @@ The bridge reads one JSON file per machine, at `~/.config/pi-t3/config.json`. Ev
 {
   "bashTimeoutSeconds": 300,
   "childSandbox": "on",
+  "classifierModel": "anthropic/claude-sonnet-4-5",
   "mcpUrl": "http://127.0.0.1:3773/mcp",
   "steer": "on"
 }
@@ -232,6 +241,7 @@ The bridge reads one JSON file per machine, at `~/.config/pi-t3/config.json`. Ev
 | --- | --- | --- |
 | `bashTimeoutSeconds` | `300` | The longest a shell command can run, in seconds. |
 | `childSandbox` | `"on"` | Whether a delegated child's shell commands need a sandbox. With `"on"`, a child's `bash` is blocked when no sandbox can run. With `"off"`, commands run with no sandbox on every platform, and the child's report says `SANDBOX: off`. |
+| `classifierModel` | unset | A chat model that judges the stop checks, as `"provider/modelId"`. The model id may contain more slashes. When unset, the bridge uses `typesafe/jev-latest` if it is available, and the session model if not. A chat model's probabilities are its own estimates, not Jev-calibrated. |
 | `mcpUrl` | `http://127.0.0.1:3773/mcp` | The T3 MCP endpoint to use outside a T3 thread. |
 | `steer` | `"on"` | The stop checks, as `"on"`, `"shadow"`, or `"off"`. |
 
@@ -251,7 +261,7 @@ Earlier releases kept the state and the model sheet under `t3-pstack`. The first
 
 ## Data handling
 
-The package has no server and sends no telemetry. The stop checks send parts of the session transcript to the classifier provider in your Pi model catalog, and any file a skill asks the agent to read goes to your model provider. Scripts run on your machine, and the PR tools use your GitHub CLI login.
+The package has no server and sends no telemetry. The stop checks send parts of the session transcript to the classifier provider, which is Jev, the model you name in `classifierModel`, or your session model, and any file a skill asks the agent to read goes to your model provider. Scripts run on your machine, and the PR tools use your GitHub CLI login.
 
 ## Development
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-t3-bridge",
-  "version": "0.4.0",
+  "version": "0.5.0",
   "description": "Pi extension adapter for t3-pstack inside T3 Code.",
   "keywords": [
     "pi-extension",
@@ -85,7 +85,7 @@
     ]
   },
   "upstreams": {
-    "t3": "0.1.5-nightly.20261029.3877",
+    "t3": "0.1.7",
     "tstack": "1085050f3baed1ac724caa4a8166145fb2ac88af"
   }
 }

package/pstack/skills/create-verification-skill/SKILL.md

@@ -14,7 +14,7 @@ Answer these from the codebase and only ask the user what you cannot observe:
 
 - **Surface:** what does a user actually touch? A web UI, a CLI/TUI, a desktop app, an API, a mobile app, a library? A repo can have several; pick the primary one and note the rest.
 - **Run:** how does the app start locally? Prefer the repo's own documented dev command (package scripts, Makefile, README quickstart). Note ports, env vars, seed data, auth.
-- **Drive:** how can an agent interact with it programmatically? Existing harnesses first — Playwright/Cypress specs, expect scripts, PTY helpers, curl-able endpoints, a debug port. Only then pick a generic recipe: browser/CDP for web and Electron, a tmux/PTY harness for CLI/TUI, plain HTTP for services.
+- **Drive:** how can an agent interact with it programmatically? Existing harnesses first — browser test specs, expect scripts, PTY helpers, curl-able endpoints, a debug port. Only then pick a generic recipe: browser/CDP for web and Electron, a tmux/PTY harness for CLI/TUI, plain HTTP for services.
 - **Observe:** what evidence can be captured? Screenshots, terminal transcripts, response bodies, logs, exit codes, DB state.
 - **Isolate:** can two instances run side by side (ports, data dirs, profiles)? If not, say so in the generated skill: refusing to double-drive a shared instance beats corrupting the user's session.
 

package/pstack/skills/poteto-mode/scripts/node_modules/commander/LICENSE

@@ -0,0 +1,22 @@
+(The MIT License)
+
+Copyright (c) 2011 TJ Holowaychuk <tj@vision-media.ca>
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+'Software'), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.