pi-pstack-adapter 0.9.0 → 0.11.0

package/docs/compatibility.md

@@ -4,7 +4,7 @@ The compatibility registry in `src/registry.ts` assigns one support tier to ever
 certified pstack revision. Generation reads it, the wrapper frontmatter publishes it, and
 `/pistack-status` reports it.
 
-Certified revision: pstack `0.15.36` at `c742dd61706fbacc1b95f1a20b7b988cf096ce6c` in
+Certified revision: pstack `0.15.42` at `bf0c7cd80abdbf7fe47b634978a7d1b4071f71a7` in
 `https://github.com/cursor/plugins`.
 
 ## Platforms
@@ -21,6 +21,22 @@ executables in the shell the skills run in, with Pi's `shellCommandPrefix` appli
 that matters most, because Git Bash adds `/usr/bin` and `/mingw64/bin` to the `PATH` Pi
 started with. A shell that is missing, inactive, or cannot run a command blocks every workflow.
 
+pstack `0.15.42` was certified on Linux by the unattended release check. No skill or agent was
+added or removed. Upstream changed its default models to Claude Opus 5.5, Claude Fable 5.2, and
+Gemini 4 Carbon, made Fable its own family, and has arena pick its judge from another vendor,
+where Fable and the other Claude models are one vendor. `how` now spawns one read-only subagent,
+and `why` spawns none: it answers inline from commits and PR discussions, so it loses its
+`delegation` gate and keeps `git` and `gh`. The `how explorer`, `how explainer`,
+`why investigators`, and `why synthesizer` role lines are gone, and the host mapping no longer
+names them. The host mapping gained the new default slugs, Fable and Gemini in the family note,
+and a row saying that poteto-mode's `# defaults: 2` check does not apply to the adapter
+configuration. The statechart scripts changed how they draw edges into nested states and how
+they report a SANY parse failure; they need no new executable, and the `/bin/sh` launcher that
+crashes on native Windows did not change. No tier changed. The release check runs no skill end
+to end, because that would execute new upstream content unattended, so no `0.15.42` skill has
+run in Pi, and `0.15.42` has not been checked on native Windows. The evidence below is from
+`0.15.36` and earlier.
+
 pstack `0.15.36` was certified on Linux. No skill or agent was added or removed. The skills
 changed only in text, and the Orchestrate playbook's `orch` scripts were deleted; no adapter
 gate named them. `0.15.36` has not been checked on native Windows. The statechart scripts did
@@ -47,8 +63,8 @@ small Git repository holding a token-bucket rate limiter with two marked bugs.
   `recall` rises to `dependency-gated`, because the transcript was its only Cursor-specific
   step. In a fresh session it read the two earlier chats itself, so its fan-out did not run. An
   earlier fresh run looked in the default session folder, which the sandbox had moved, so the
-  host mapping now says to find the folder from `$PI_SESSION_FILE` first. `reflect` copied the upstream skill
-  to a Pi skill location before editing it, but its create-skill route did not run, and
+  host mapping now says to find the folder from `$PI_SESSION_FILE` first. `reflect` copied the
+  upstream skill to a Pi skill location before editing it, but its create-skill route did not run, and
   `automate-me` found nothing to draft, so both stay `experimental`.
 - `poteto-mode`'s Orchestrate playbook ran a two-unit program in a linked worktree. Each unit had
   an owner on its own branch and worktree, and a verifier from another model family checked the
@@ -223,10 +239,10 @@ Earlier Windows evidence, gathered at pstack `0.15.26` with the same toolchain:
 - `create-formal-verification-skill` completed in the isolated install without `subagent` or
   `ask_user`. It generated `.pi/skills/verify-inventory-reservations/SKILL.md` and a dependency-free
   Node 22 explicit-state verifier that imports the fixture's actual reserve/release functions.
-  It checked 49 reachable states and 490 transitions for stock 0–3 and five request IDs, caught
+  It checked 49 reachable states and 490 transitions for stock from 0 to 3 and five request IDs, caught
   six mutant copies, then caught a removed retry guard in the actual product file. Restoring
-  that file restored the passing result and its original hash. This supports `adapted`: the
-  generated skill path is mapped to Pi. It does not certify TLA+, proof assistants, installation
+  that file restored the passing result and its original hash. This supports `adapted`, because
+  the host mapping maps the generated skill path to Pi. It does not certify TLA+, proof assistants, installation
   of other verifiers, unbounded inputs, or real database/async concurrency.
 - The revised `ketchup` ran read-only in a separate fixture. It listed both supplied product
   choices (CSV versus JSON and seven versus thirty days of history), drew a Mermaid sequence
@@ -237,8 +253,9 @@ Earlier Windows evidence, gathered at pstack `0.15.26` with the same toolchain:
   `ketchup`, but still names `uptime` as missing for `benchmark-checklist`. Delegation and
   structured questions remain unavailable in the isolated install; no delegating tier changed.
 - A cache inside a Git worktree must own its worktree, Git directory, and common directory before
-  bootstrap or reuse can change Git state. The Windows run exposed ancestor discovery from an
-  empty nested cache; this is fixed. Regressions also cover incomplete metadata, a foreign Git
+  bootstrap or reuse can change Git state. The Windows run found that Git, started in an
+  empty nested cache, discovered the enclosing repository. That is fixed. Regression tests also
+  cover incomplete metadata, a foreign Git
   file, foreign worktree/common directory settings, and short paths, while checking that the
   enclosing repository's HEAD, config, index, and tracked bytes stay unchanged.
 
@@ -287,13 +304,13 @@ A session that replaces the `bash` tool with `powershell` cannot run the skills.
 
 ## Changing a tier
 
-A tier is a claim about what was verified, so raising one needs evidence, not optimism.
+A tier is a claim about what a run verified, so raising one needs evidence from a run.
 
 1. Run the workflow end to end in Pi against the certified revision.
 2. Record what the workflow produced, not that it started. A `dependency-gated` skill rises to
    `adapted` only when its delegation or question steps completed against a real provider.
 3. An `experimental` skill rises only when every Cursor-specific step has a Pi equivalent that
-   was exercised, not merely described in the host mapping.
+   a run exercised, not one the host mapping only describes.
 4. An `unsupported` skill rises only when the missing host feature exists in Pi.
 5. Add or update a test that fails if the claim regresses.
 
@@ -332,7 +349,7 @@ Lowering a tier needs one reproduction of the failure and a note saying what bro
 | `principle-test-behavior-not-implementation` | `/skill:pistack-principle-test-behavior-not-implementation` | - | - | - |
 | `principle-type-system-discipline` | `/skill:pistack-principle-type-system-discipline` | - | - | - |
 | `setup-pstack` | `/skill:pistack-setup` | - | - | The upstream body only writes a Cursor .mdc rule, so the adapter replaces it with a Pi setup workflow. |
-| `sharpen` | `/skill:pistack-sharpen` | - | - | Verified end to end in Pi on Linux at pstack 0.15.36: it handed back four short sections and a rewritten prompt for a vague gateway task, left the decisions that were the user's open, and did not start the task. Since pstack 0.15.29 it hands back a rewritten prompt and does not do the task. Its body is prompt-only, with no tool, delegation, or executable, and it runs only when you type it. |
+| `sharpen` | `/skill:pistack-sharpen` | - | - | Verified end to end in Pi on Linux at pstack 0.15.36: it handed back four short sections and a rewritten prompt for a vague gateway task, left the decisions that were the user's open, and did not start the task. Since pstack 0.15.29 it hands back a rewritten prompt and does not do the task. Its body is prompt-only, with no tool, delegation, or executable, and it runs only when you type it. Since pstack 0.15.42 the rewritten prompt asks the agent to prototype any choice an experiment can settle and leaves only product or preference choices to the user. That wording has not been rerun in Pi. |
 | `tdd` | `/skill:pistack-tdd` | - | - | - |
 | `technical-writing` | `/skill:pistack-technical-writing` | - | - | - |
 | `typescript-best-practices` | `/skill:pistack-typescript-best-practices` | - | - | - |
@@ -342,7 +359,7 @@ Lowering a tier needs one reproduction of the failure and a note saying what bro
 
 | upstream skill | Pi skill | capabilities | executables | why |
 | --- | --- | --- | --- | --- |
-| `arena` | `/skill:pistack-arena` | `delegation` | `git` | The whole skill is spawning N candidate subagents plus a judge. Since pstack 0.15.36 the judge must come from a model family other than the parent's. The adapter maps the cross-judge pool to the `arena-cross-judge-pool` panel role, which uses `judgment`, then `general` while unset, so when the parent knows its model, the judge runs only when one of its entries is on another family. The status report and `check` warn when that pool is on one model. Otherwise arena skips the judge, picks the base alone, and says so. When the parent does not know its model, arena tries the pool in order anyway and says the family check did not run. Verified end to end in Pi on Linux at pstack 0.15.36 with pi-subagents: two candidates on the `judgment` and `general` roles, then a judge from the family other than the parent's, which scored them. The parent picked a base, took the fixes for two bugs from the other candidate, fixed a third that both shared, and finished with passing tests. It left the candidate worktrees for comparison. |
+| `arena` | `/skill:pistack-arena` | `delegation` | `git` | The whole skill is spawning N candidate subagents plus a judge. Since pstack 0.15.36 the judge must come from a model family other than the parent's, and since pstack 0.15.42 from another vendor, where Fable and the other Claude models are one vendor. Its default runners and pool are now one Fable, one Opus, and one Gemini model. The adapter maps the cross-judge pool to the `arena-cross-judge-pool` panel role, which uses `judgment`, then `general` while unset, so when the parent knows its model, the judge comes from the first pool entry from another vendor. When no entry qualifies, arena tries `judgment`, then `general`, and only when neither is from another vendor does it skip the judge, pick the base alone, and say so. The status report and `check` warn when that pool is on one model. When the parent does not know its model, arena tries the pool in order anyway and says the vendor check did not run. Verified end to end in Pi on Linux at pstack 0.15.36 with pi-subagents: two candidates on the `judgment` and `general` roles, then a judge from the family other than the parent's, which scored them. The parent picked a base, took the fixes for two bugs from the other candidate, fixed a third that both shared, and finished with passing tests. It left the candidate worktrees for comparison. The pstack 0.15.42 vendor rule has not run in Pi. |
 | `create-formal-verification-skill` | `/skill:pistack-create-formal-verification-skill` | - | - | Manual invocation only; no delegation. It installs or runs the verification tool it chooses and temporarily breaks product code to prove the check. Generated skills belong under `.pi/skills/` in Pi. Verified on a Windows Node finite-state fixture; other toolchains need their own prerequisites. Since pstack 0.15.32, a generated TLA+ check tells the next agent to read its results with statechart, which has its own prerequisites. |
 | `create-verification-skill` | `/skill:pistack-create-verification-skill` | - | - | Only the generated skill's output path needs remapping to Pi's skill directory. |
 | `interrogate` | `/skill:pistack-interrogate` | `delegation` | `git` | Multi-model adversarial review is entirely one subagent per configured model. Since pstack 0.15.36 it picks adversaries the way arena picks runners, from the `interrogate reviewers` line, and gives each one its own worktree with the scope's uncommitted changes. Each adversary must prove a finding with a run, and the skill keeps only findings whose command it reruns and sees fail. It reports findings and applies no fixes, but adversaries write and run repro commands, and the skill reruns them, all with your permissions. A worktree is not a sandbox, so read each repro before it reruns, especially on code you do not trust. The rubric, the lead's judgment, and the code-quality lens are gone. Verified end to end in Pi on Linux at pstack 0.15.36 with pi-subagents: two adversaries on the `judgment` and `general` roles, from two model families, each in its own worktree, proved the same two real bugs, and the skill reran both repros before it reported them. It left the adversary worktrees in the temporary folder and named the commands that remove them. |
@@ -358,13 +375,13 @@ Lowering a tier needs one reproduction of the failure and a note saying what bro
 | `blast-radius` | `/skill:pistack-blast-radius` | - | `git`, `gh` | Needs git and gh to read the diff, commits, and PR before any analysis. |
 | `correct` | `/skill:pistack-correct` | - | `git` | Mines commit history, then commits fixes and edits lint, CI, and agent instruction files. Run it on a branch you will review. |
 | `figure-it-out` | `/skill:pistack-figure-it-out` | `delegation` | - | Phase B fan-out and the architect/arena routing require parallel subagents. |
-| `how` | `/skill:pistack-how` | `delegation` | - | Every path spawns explorer or explainer subagents; nothing runs inline. |
+| `how` | `/skill:pistack-how` | `delegation` | - | Since pstack 0.15.42 it spawns one read-only subagent that explores and explains in one pass, and nothing runs inline. That path has not run in Pi. |
 | `maintain-formal-verification-skill` | `/skill:pistack-maintain-formal-verification-skill` | - | `git` | Verified end to end on a Windows Node finite-state fixture at pstack 0.15.28. Manual invocation only; no delegation. It diffs the covered code with git from the verify skill's sync commit, edits only the verification and the verify skill, and temporarily breaks product code to prove an updated check can still fail. In Pi, look for the verify skill under `.pi/skills/`; the verification tool needs its own prerequisites. |
 | `maintain-verification-skill` | `/skill:pistack-maintain-verification-skill` | `delegation` | - | Source wave launches one read-only subagent per feature file. |
 | `no-comments` | `/skill:pistack-no-comments` | `delegation` | `git` | Step 1 must spawn the comment-sicko agent; the skill only triages its report. |
-| `recall` | `/skill:pistack-recall` | `delegation` | `git`, `gh` | Its core corpus is Cursor's on-disk transcript JSONL. The host mapping points it at this workspace's Pi session files instead. Verified end to end in Pi on Linux at pstack 0.15.36: in a fresh session it found the two earlier chats in the folder that holds `$PI_SESSION_FILE`, read their user messages, checked their claims against git and the code, and rebuilt the threads, problems, and next move. With two chats to read, it read them itself, so it did not fan out to subagents, and that step has not run in Pi. A run before the host mapping said to start from `$PI_SESSION_FILE` looked in the default folder instead, which a custom `PI_CODING_AGENT_DIR` had moved, and found nothing. |
-| `teach` | `/skill:pistack-teach` | `delegation` | - | It runs the how and why skills, both of which need subagents. |
-| `why` | `/skill:pistack-why` | `delegation` | `git`, `gh` | Default posture spawns one investigator subagent per evidence category plus a synthesizer. |
+| `recall` | `/skill:pistack-recall` | `delegation` | `git`, `gh` | Its core corpus is Cursor's on-disk transcript JSONL. The host mapping points it at this workspace's Pi session files instead. Verified end to end in Pi on Linux at pstack 0.15.36: in a fresh session it found the two earlier chats in the folder that holds `$PI_SESSION_FILE`, read their user messages, checked their claims against git and the code, and rebuilt the threads, problems, and next move. With two chats to read, it read them itself, so it did not fan out to subagents, and that step has not run in Pi. A run before the host mapping said to start from `$PI_SESSION_FILE` looked in the default folder instead, which a custom `PI_CODING_AGENT_DIR` had moved, and found nothing. Since pstack 0.15.42 its shared-record sweep spawns one investigator per source itself instead of reusing why's investigators, and that step has not run in Pi. |
+| `teach` | `/skill:pistack-teach` | `delegation` | - | It runs the how skill, which needs a subagent, and the why skill, which since pstack 0.15.42 runs inline and needs git and gh. Check why's prerequisites too. |
+| `why` | `/skill:pistack-why` | - | `git`, `gh` | Since pstack 0.15.42 it spawns no subagents. It answers inline from the commits and PR discussions behind the target, and from other sources when that trail is thin, so it needs git, and gh for the PR discussions. The inline path has not run in Pi. |
 
 ### experimental (7)
 
@@ -373,9 +390,9 @@ Lowering a tier needs one reproduction of the failure and a note saying what bro
 | `automate-me` | `/skill:pistack-automate-me` | `delegation`, `structured-question` | `git`, `gh` | Its mining step reads this workspace's transcripts. The host mapping points it at this workspace's Pi session files, which use a different format. Verified end to end in Pi on Linux at pstack 0.15.36: it read only this workspace's sessions, told the parent chat from its subagents' files, found no stated preference there, and changed nothing. The built-in create-skill skill it drafts with has no Pi equivalent, and that step has not run in Pi. |
 | `ketchup-video` | `/skill:pistack-ketchup-video` | - | - | New in pstack 0.15.32. One end-to-end Pi run on native Windows drew its slides and rendered an mp4 with `ffmpeg` alone, before pstack 0.15.36 added subtitles. Verified end to end in Pi on Linux at pstack 0.15.36: it drew five slides as SVG, rendered a 35-second 1280x720 mp4 with `ffmpeg`, with each subtitle burned into a strip below its slide, and checked frames from the file. Manual invocation only; no delegation or structured question. It follows ketchup, read-only, but shows what happened as a short slide video with no audio, rendered outside the repository, with the waiting calls as text under it. Since pstack 0.15.36 it burns a one-line subtitle into each slide's frames, in a strip below the slide, and measures each slide's hold by matching the rendered frames to the slide. Its body names no renderer, so it needs whatever video tool the session has, such as `ffmpeg`, and Pi has no image generation. Its reply embedded the video as an HTML `video` tag with the file path, and whether a Pi client plays it inline is unverified. When the render fails, it says so in one line and gives only the calls. |
 | `poteto-help` | `/skill:pistack-poteto-help` | - | - | Its answers describe Cursor setup, the slash menu, and Custom Modes. A request for work runs poteto-mode, which is experimental. It asks a multiple-choice question only when the need is unclear. Its README and guide links resolve under the status report's plugin directory. |
-| `poteto-mode` | `/skill:pistack-poteto-mode` | `delegation`, `structured-question` | `git`, `gh` | Sticky-mode hosting plus references to Cursor built-in and plugin skills only partially map to Pi. Since pstack 0.15.36 the Orchestrate playbook calls no scripts, because the `orch` helpers are gone, and watches PRs through event subscriptions only when the harness has them. Pi has none. Its Project tracker and Project store, and forking a worker with its built state, have no Pi equivalent; the host mapping says what to do instead. Verified end to end in Pi on Linux at pstack 0.15.36 with pi-subagents and a question tool: Orchestrate ran a two-unit program in a linked worktree, with an owner per unit on its own branch and worktree, a verifier from another model family at the owner's head, and local merges. It kept the tracker and store in a folder it added to the exclude file Git resolved for the worktree, and handed state to new agents instead of messaging old ones. Its other playbooks and sticky mode were not rerun. |
+| `poteto-mode` | `/skill:pistack-poteto-mode` | `delegation`, `structured-question` | `git`, `gh` | Sticky-mode hosting plus references to Cursor built-in and plugin skills only partially map to Pi. Since pstack 0.15.36 the Orchestrate playbook calls no scripts, because the `orch` helpers are gone, and watches PRs through event subscriptions only when the harness has them. Pi standalone has none; a T3 Code host can provide them when it exposes `mcp__t3-code__watch_pull_request`. This is a host capability, not a guarantee of either delegation backend. Its Project tracker and Project store, and forking a worker with its built state, have no Pi equivalent; the host mapping says what to do instead. Verified end to end in Pi on Linux at pstack 0.15.36 with pi-subagents and a question tool: Orchestrate ran a two-unit program in a linked worktree, with an owner per unit on its own branch and worktree, a verifier from another model family at the owner's head, and local merges. It kept the tracker and store in a folder it added to the exclude file Git resolved for the worktree, and handed state to new agents instead of messaging old ones. Its other playbooks and sticky mode were not rerun. Since pstack 0.15.42 it tells the user to rerun setup when the model rule has no `# defaults: 2` line. The host mapping says that check does not apply to the adapter configuration. |
 | `reflect` | `/skill:pistack-reflect` | `delegation` | - | Its reviewers read the active transcript, and the host mapping points them at the current Pi session file. Verified end to end in Pi on Linux at pstack 0.15.36 with pi-subagents: three reviewers on two model families and a synthesizer read the session file, and the run found a regression the earlier review missed. When told to apply two edits, it copied the upstream skill from the plugin directory to a Pi skill location under a new name and edited only the copy. Its create-skill routing for a new skill is Cursor-specific and has not run in Pi. It never opens a PR or pushes. |
-| `statechart` | `/skill:pistack-statechart` | - | `node`, `sh`, `dirname`, `sed` | Lowered from dependency-gated at pstack 0.15.34, because its new scripts crash on native Windows, a certified platform. There, the launcher starts `/bin/sh` by that path to stop TLC's process group, Node cannot start it even when `sh` is on PATH, and with no error handler the run exits 1 with `spawn /bin/sh ENOENT`. It writes no output and leaves an empty hidden staging folder beside the output folder and an empty `statechart-` folder in the temporary folder, so delete those by hand. `/pistack-check` still clears it there, because the gates are found. Use it from Linux, macOS, or WSL. Verified end to end on a Linux checkout fixture at pstack 0.15.34, and again at pstack 0.15.36, where it found the uncapped refill in a token bucket as the shortest path to a broken rule. The Windows end-to-end evidence from pstack 0.15.32 and 0.15.30 describes the scripts it replaced. Manual invocation only; no delegation or structured question. `scripts/statechart` is a POSIX `sh` launcher for TypeScript scripts, and it runs `dirname` and `sed` on every start. It runs the scripts under Node 22.18 to 22.x or Node 23.6 or later, then Bun 1.1.5 or later, then Deno 2.0 or later, and exits with code 127 when none is found. The prerequisite check gates on `node` but cannot check its version. The launcher does: with only an older Node on PATH, it names the versions it needs and exits 127. The command checks a TLA+ spec with TLC and writes `report.md` and TLC output to a new or empty `--out` folder, `SPEC-chart` beside the spec by default, and refuses a folder that is not empty. It also writes `chart.mmd`, except when TLC finds more than 500 states and no rule breaks. It stages its work in a hidden folder beside the output folder and in the system temporary folder, and deletes both. TLC runs from `TLA2TOOLS`, the path to a downloaded `tla2tools.jar`, with the binary in `JAVA` or `java` from PATH. Without `TLA2TOOLS`, it uses TLC 1.7.4 and Java temurin-25 from `mise`, and installs whichever is missing with `mise`, which needs the network. `JAVA` then changes only the binary that runs TLC, and does not skip the `mise` lookup or install of Java. Either `mise` or `TLA2TOOLS` with Java works, so neither is gated, and the script names what is missing when neither is set up. It imports the `--view` module as JavaScript with full process permissions, so review an existing view before you run it. Since pstack 0.15.34 the scripts render no images and do not run `npm`. For an image, the body has the agent install `pele@1.9.0` with `npm` once, outside the repository, which needs `npm` and the network, and render SVG with it. The body does not ask for `--ignore-scripts`, so pass it, and rendering still imports Pele with full process permissions. Run it in a scratch folder outside the repository. Git for Windows bundles `sh`, `dirname`, and `sed`, but not `node`, `mise`, or Java. |
+| `statechart` | `/skill:pistack-statechart` | - | `node`, `sh`, `dirname`, `sed` | Lowered from dependency-gated at pstack 0.15.34, because its new scripts crash on native Windows, a certified platform. There, the launcher starts `/bin/sh` by that path to stop TLC's process group, Node cannot start it even when `sh` is on PATH, and with no error handler the run exits 1 with `spawn /bin/sh ENOENT`. It writes no output and leaves an empty hidden staging folder beside the output folder and an empty `statechart-` folder in the temporary folder, so delete those by hand. `/pistack-check` still clears it there, because the gates are found. Use it from Linux, macOS, or WSL. Verified end to end on a Linux checkout fixture at pstack 0.15.34, and again at pstack 0.15.36, where it found the uncapped refill in a token bucket as the shortest path to a broken rule. The Windows end-to-end evidence from pstack 0.15.32 and 0.15.30 describes the scripts it replaced. Manual invocation only; no delegation or structured question. `scripts/statechart` is a POSIX `sh` launcher for TypeScript scripts, and it runs `dirname` and `sed` on every start. It runs the scripts under Node 22.18 to 22.x or Node 23.6 or later, then Bun 1.1.5 or later, then Deno 2.0 or later, and exits with code 127 when none is found. The prerequisite check gates on `node` but cannot check its version. The launcher does: with only an older Node on PATH, it names the versions it needs and exits 127. The command checks a TLA+ spec with TLC and writes `report.md` and TLC output to a new or empty `--out` folder, `SPEC-chart` beside the spec by default, and refuses a folder that is not empty. It also writes `chart.mmd`, except when TLC finds more than 500 states and no rule breaks. It stages its work in a hidden folder beside the output folder and in the system temporary folder, and deletes both. TLC runs from `TLA2TOOLS`, the path to a downloaded `tla2tools.jar`, with the binary in `JAVA` or `java` from PATH. Without `TLA2TOOLS`, it uses TLC 1.7.4 and Java temurin-25 from `mise`, and installs whichever is missing with `mise`, which needs the network. `JAVA` then changes only the binary that runs TLC, and does not skip the `mise` lookup or install of Java. Either `mise` or `TLA2TOOLS` with Java works, so neither is gated, and the script names what is missing when neither is set up. It imports the `--view` module as JavaScript with full process permissions, so review an existing view before you run it. Since pstack 0.15.34 the scripts render no images and do not run `npm`. For an image, the body has the agent install `pele@1.9.0` with `npm` once, outside the repository, which needs `npm` and the network, and render SVG with it. The body does not ask for `--ignore-scripts`, so pass it, and rendering still imports Pele with full process permissions. Run it in a scratch folder outside the repository. Git for Windows bundles `sh`, `dirname`, and `sed`, but not `node`, `mise`, or Java. At pstack 0.15.42 the Mermaid backend can draw the edges into a nested state as one edge into its parent plus start edges inside it, and a SANY parse failure reruns SANY to print its errors. Those script changes add no executable, leave the `/bin/sh` launcher unchanged, and have not run in Pi. |
 | `swarm` | `/skill:pistack-swarm` | `delegation` | - | Cloud background workers and cloud_base_branch have no Pi mapping; only local fan-out approximates it. |
 
 ### unsupported (1)
@@ -395,8 +412,8 @@ T3 Code's `delegate_task` has no named agents. Generation writes each agent's pr
 `adapter/agents/<pi-name>.md`, with skill paths relative to that file. The parent begins the
 child's task by telling it to read that file as its system prompt.
 
-Both agents also register through the `pi-subagents:runtime-agent-register:v1` contract. Without an owner for
-that event, the status report says so rather than dropping them silently.
+Both agents also register through the `pi-subagents:runtime-agent-register:v1` contract. When no
+extension handles that event, the status report says the agents did not register.
 
 ## Delegation providers
 
@@ -418,6 +435,13 @@ marker text is reported as a warning, with its bytes unchanged. An agent whose P
 skill name rules is skipped with an error, before its name reaches a file name or any generated
 text.
 
+The generated instructions tell the model to name a role, not a model, by passing
+`pstack:<role>` as the delegation's model. Before either tool runs, the adapter rewrites that
+reference to the role's model and thinking, taking the first model of a pool that the model
+filter allows, and then applies the filter as for any other call. Unit and integration tests drive
+this through the real `tool_call` handler. No workflow has yet run end to end with role
+references, so no tier claim rests on them.
+
 Unit tests cover detection, activation order, and the generated instructions for both providers.
 No tier changed when T3 support arrived, because no delegating workflow has yet run end to end
 through `delegate_task`. That run is the evidence the tier rules above require.
@@ -427,11 +451,10 @@ through `delegate_task`. That run is the evidence the tier rules above require.
 `setup-pstack` writes a Cursor `.mdc` rule, so the adapter substitutes its own body and
 publishes it as `/skill:pistack-setup`. Upstream's optional closing offers to run
 `create-verification-skill` and `create-formal-verification-skill` are left out of the Pi body;
-both skills stay available by name. The upstream skill stays represented, and the
+both skills stay available by name. The registry still lists the upstream skill, and the
 wrapper frontmatter records `pistack-upstream-skill: setup-pstack`.
 
 ## Unknown skills
 
 A skill present upstream but absent from the registry is generated as `experimental` and reported
-in diagnostics. A skill in the registry but absent upstream is reported as removed. Neither case
-is silent.
+in diagnostics. A skill in the registry but absent upstream is reported as removed.

package/index.ts

@@ -18,6 +18,7 @@ import {
   sessionFilterFromEntries,
 } from "./src/filter.ts";
 import { gateDelegation } from "./src/gate.ts";
+import { applyRewrite, routeDelegation } from "./src/route.ts";
 import { checkPrerequisites, detectCapabilities, type ToolDescriptor } from "./src/capabilities.ts";
 import {
   type AdapterConfig,
@@ -149,24 +150,37 @@ export default function (pi: ExtensionAPI) {
     sessionFilter = sessionFilterFromEntries(ctx.sessionManager.getBranch() as never[]);
   });
 
-  // The model filter applies to every delegation in this session, pstack or not, because a
-  // delegation tool call names no pstack role. A blocked call fails; nothing retries it.
+  // A `pstack:<role>` model is rewritten to the model the adapter picks for that role. The model
+  // filter then applies to every delegation in this session, pstack or not, because a call that
+  // names a concrete model names no role. A blocked call fails; nothing retries it.
   pi.on("tool_call", async (event, ctx) => {
     if (event.toolName !== T3_DELEGATE_TOOL && event.toolName !== SUBAGENT_TOOL) return;
-    if (sessionFilter === undefined && configError !== undefined) {
-      return {
-        block: true,
-        reason: `Blocked by the pstack adapter: its config could not be read, so it cannot tell whether a saved model filter applies. ${configError} Fix the config and reload, or ask the user whether to set an explicit session filter with \`set_filter\`.`,
-      };
-    }
-    const decision = gateDelegation(event.toolName, event.input, {
+    const unreadable = configBlock();
+    if (unreadable) return unreadable;
+    const context = {
       filter: filterOf(activeFilter(sessionFilter, savedFilter)),
       parentModel: parentModelOf(ctx),
-      resolveModel: (model) => resolveRegistryModel(ctx, model),
-    });
+      resolveModel: (model: string) => resolveRegistryModel(ctx, model),
+    };
+    const route = await routeDelegation(event.toolName, event.input, { ...context, config: state?.config, parentThinking: ctx.thinkingLevel });
+    if (route.kind === "block") return { block: true, reason: route.reason };
+    if (route.kind === "rewrite") applyRewrite(event.input as Record<string, unknown>, route.input);
+    // Read the config state, filter, and parent model again: a pick that waits on a service could span
+    // a reload, a `set_filter`, or a model change.
+    const unreadableNow = configBlock();
+    if (unreadableNow) return unreadableNow;
+    const decision = gateDelegation(event.toolName, event.input, { ...context, filter: filterOf(activeFilter(sessionFilter, savedFilter)), parentModel: parentModelOf(ctx) });
     if (decision.kind === "block") return { block: true, reason: decision.reason };
   });
 
+  function configBlock(): { block: true; reason: string } | undefined {
+    if (sessionFilter !== undefined || configError === undefined) return undefined;
+    return {
+      block: true,
+      reason: `Blocked by the pstack adapter: its config could not be read, so it cannot tell whether a saved model filter applies. ${configError} Fix the config and reload, or ask the user whether to set an explicit session filter with \`set_filter\`.`,
+    };
+  }
+
   pi.on("resources_discover", async () => {
     if (!state) return {};
     return { skillPaths: [state.generation.skillsDir] };
@@ -210,7 +224,7 @@ export default function (pi: ExtensionAPI) {
       model: Type.Optional(
         Type.Union([Type.String(), Type.Array(Type.String())], {
           description:
-            "`provider/model` id, or `inherit` to clear the role. A list of ids gives an ordinary role a pool: each delegation picks one. For a panel role such as `arena-runners`, a string of entries separated by commas, one seat each.",
+            "`provider/model` id, or `inherit` to clear the role. A list of ids gives an ordinary role a pool, ranked in list order: a `pstack:<role>` delegation runs on the first one the model filter allows. For a panel role such as `arena-runners`, a string of entries separated by commas, one seat each.",
         }),
       ),
       thinking: Type.Optional(
@@ -467,7 +481,7 @@ export default function (pi: ExtensionAPI) {
     const listed = (typeof plan.value === "string" ? [plan.value] : plan.value).map((entry) => `\`${entry}\``).join(", ");
     return typeof plan.value === "string"
       ? `Role \`${role}\` now uses ${listed}. A pool of one is written as a plain model. Written to ${path}.${note}`
-      : `Role \`${role}\` now has a pool of ${plan.value.length} models: ${listed}. Each delegation picks one model the filter allows. Written to ${path}.${note}`;
+      : `Role \`${role}\` now has a pool of ${plan.value.length} models: ${listed}. A \`pstack:${role}\` delegation runs on the first one the model filter allows. Written to ${path}.${note}`;
   }
 
   function setFilter(

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-pstack-adapter",
-  "version": "0.9.0",
+  "version": "0.11.0",
   "description": "Run Cursor's official pstack plugin inside Pi from an unmodified upstream checkout",
   "type": "module",
   "license": "MIT",

package/src/certified.ts

@@ -5,9 +5,9 @@
 export const CERTIFIED = {
   repo: "https://github.com/cursor/plugins",
   ref: "main",
-  commit: "c742dd61706fbacc1b95f1a20b7b988cf096ce6c",
+  commit: "bf0c7cd80abdbf7fe47b634978a7d1b4071f71a7",
   pluginPath: "pstack",
-  pstackVersion: "0.15.36",
+  pstackVersion: "0.15.42",
   skillCount: 58,
   agentCount: 2,
 } as const;

package/src/config.ts

@@ -10,8 +10,9 @@ import type { DelegationProvider, SourceSelection, Trust } from "./types.ts";
 import { type ModelFilter, parseModelFilter } from "./filter.ts";
 
 /**
- * A role's model. A list is a pool of alternatives for an ordinary role: each delegation picks one
- * eligible entry. A panel role keeps its space-separated string, one seat per entry.
+ * A role's model. A list is a ranked pool of alternatives for an ordinary role: each delegation runs
+ * on the first eligible entry unless it overrides the ranking. A panel role keeps its
+ * space-separated string, one seat per entry.
  */
 export type ModelValue = string | readonly string[];
 

package/src/gate.ts

@@ -1,5 +1,6 @@
 import { splitModelSpec } from "./config.ts";
 import { SUBAGENT_TOOL, T3_DELEGATE_TOOL } from "./delegation.ts";
+import { safeEcho } from "./echo.ts";
 import { type ModelFilter, describeFilter, isRestricting, modelAllowed } from "./filter.ts";
 
 export type GateDecision = { readonly kind: "allow" } | { readonly kind: "block"; readonly reason: string };
@@ -50,7 +51,7 @@ function checkModel(requested: unknown, where: string, context: GateContext & {
   }
   const resolved = context.resolveModel(splitModelSpec(requested.trim()).model);
   if (resolved === undefined) {
-    return block(`${where} asks for \`${requested.trim()}\`, which this Pi installation does not know, so the filter cannot allow it.`, context.filter);
+    return block(`${where} asks for ${safeEcho(requested.trim())}, which this Pi installation does not know, so the filter cannot allow it.`, context.filter);
   }
   if (!modelAllowed(context.filter, resolved)) return block(`${where} asks for \`${resolved}\`, which the filter excludes.`, context.filter);
   return ALLOW;
@@ -83,7 +84,7 @@ function gateT3(args: Record<string, unknown>, context: GateContext): GateDecisi
   }
   const provider = [providerInstanceId, driverKind].find((value) => value !== undefined && value !== "pi");
   if (provider !== undefined) {
-    return block(`\`delegate_task\` targets T3 provider \`${String(provider)}\`, whose models are not Pi registry ids, so the filter cannot check them. Use \`providerInstanceId: "pi"\`.`, filter);
+    return block(`\`delegate_task\` targets T3 provider ${safeEcho(provider)}, whose models are not Pi registry ids, so the filter cannot check them. Use \`providerInstanceId: "pi"\`.`, filter);
   }
   if (model === undefined) return checkParent("`delegate_task`", scoped);
   return checkModel(model, "`delegate_task`", scoped);

package/src/generate.ts

@@ -464,31 +464,52 @@ ${agentSystemPrompt(notes, upstreamPrompt)}
  * strongest-judgment delegate's helpers would all run at its level. The rule travels in every brief.
  */
 const NESTED_DELEGATION_RULE = `Nested delegation: every agent that delegates, a child included, gives each new child an
-  explicit role, using \`general\` when no other role fits, and never lets it inherit the delegating
-  agent's model or thinking. The one exception is a panel seat from an \`inherit\` entry in the
-  \`panel roles\` table, which runs on the delegating agent's model and thinking because the user
-  configured it so. Put this line in each brief, verbatim, just before any read-only or
-  no-commit rule: "If you start agents, give each the model and thinking of its own pstack role from the
-  \`pstack_adapter\` status report, using \`general\` when no role fits. Never let one inherit your
-  model or thinking, except a panel seat from an \`inherit\` entry in that report's \`panel roles\` table, and never raise a role above its configured level."`;
-
-const MODEL_POLICY_SECTION = `Model pools and the model filter work the same on both backends.
-
-- A role whose \`model roles\` row reads "pool, pick one of" lists alternatives. For each
-  delegation, pick ONE model from it by fit, and pass that model and its thinking by the backend
-  rules below. A pool is not a retry list and not a panel: start one child per task, and when a
-  delegation fails, report the failure instead of trying another model from the pool.
+  explicit role as \`pstack:<role>\`, using \`pstack:general\` when no other role fits, and
+  never lets it inherit the delegating agent's model or thinking. The one exception is a panel seat
+  from an \`inherit\` entry in the \`panel roles\` table, which runs on the delegating agent's
+  model and thinking because the user configured it so. Put this line in each brief, verbatim,
+  just before any read-only or no-commit rule: "If you start agents, pass each one's model as \`pstack:<role>\` for its own pstack role, using \`pstack:general\` when no role fits, so the pstack adapter gives it the model and thinking that the \`pstack_adapter\` status report shows for that role. Never let one inherit your model or thinking, except a panel seat from an \`inherit\` entry in that report's \`panel roles\` table, and never raise a role above its configured level."`;
+
+const MODEL_POLICY_SECTION = `Model roles, pools, and the model filter work the same on both backends.
+
+- Name a role, not a model. For every pstack delegation, pass \`pstack:<role>\` as the model, such
+  as \`pstack:feature\`, using \`pstack:general\` when no other role fits. Before the call runs, the
+  adapter replaces it with the role's model and thinking, or, when the role inherits, with no
+  model, so the child inherits the parent model and thinking. The backend sections below say where the
+  reference goes.
+- A role whose \`model roles\` row reads "pool, ranked" lists alternatives in rank order. The
+  adapter picks the first one the model filter allows, with that entry's thinking. To override the
+  ranking for one task, pass \`pstack:<role>@<provider/model>\` with another allowed model from the
+  role's pool, and say in your reply which model you picked and why. The adapter blocks an
+  override that is not an allowed entry of the pool.
+  A pool is not a retry list and not a panel: start one child per task, and when a delegation
+  fails, report the failure instead of trying another model from the pool.
+- To lower a role's thinking, end the reference with \`:<level>\`, as in \`pstack:feature:low\` or
+  \`pstack:feature@<provider/model>:low\`. A level above the role's configured one runs at the
+  configured one, and a role whose thinking reads "backend default" keeps the backend's default.
+- The adapter blocks a reference to an unknown role, to a panel role, or to a blocked role, and
+  the block reason says what to do next. Report a blocked call instead of retrying it.
+- A concrete \`provider/model\` still runs, checked only by the model filter. Use it for a
+  configured panel seat, which names its own model, and not for a pstack role.
 - A role whose row reads "BLOCKED" has no model the model filter allows. Do not delegate its work,
   and do not move the work to \`general\` or to your own model. Tell the user which role is blocked
   and why.
 - A panel seat that reads "BLOCKED" does not run. Run the other seats, and say in your reply which
-  seat did not run and why. A seat that reads "one of" runs once, on one model you pick from it.
+  seat did not run and why. The seats of an unset panel are roles: delegate them as
+  \`pstack:judgment\` and \`pstack:general\`, so a seat that reads "ranked" runs once on the first
+  allowed model unless you override the ranking as for a pool. A configured seat names its model
+  and thinking, and the adapter does not rewrite a concrete model, so pass both yourself: on T3,
+  \`target: { providerInstanceId: "pi", model: "<provider/model>", options: { thinking: "<level>" } }\`;
+  on pi-subagents, \`model: "<provider/model>:<level>"\`. For a seat at "backend default", pass
+  \`options: {}\` on T3, which clears the inherited thinking, or no suffix on pi-subagents. An
+  \`inherit\` seat omits \`target\` on T3 and passes your own model on pi-subagents.
 - When the \`model filter\` row of the status report names a filter, the adapter blocks any
   \`delegate_task\` or \`subagent\` call in this session whose model the filter excludes, or whose
   model it cannot tell. That covers a call with no model while your own model is excluded, a model
   Pi does not know, a T3 provider other than \`pi\`, a \`subagent\` child without \`model\`, a
   \`subagent\` workflow script, and a \`subagent\` action that starts, restarts, steers, or schedules
-  a child or configures a watchdog. A T3 target with a named environment is blocked too.
+  a child or configures a watchdog. A T3 target with a named environment is blocked too. The
+  adapter replaces a \`pstack:<role>\` reference first, and checks the model it picked.
   Report a blocked call instead of retrying it. Keep the active filter unchanged unless the user
   requests a change. Wait for \`set_filter\` to finish before issuing delegation calls.
 - Children do not inherit a session filter. Put the brief line that the \`check\` report gives into
@@ -520,20 +541,19 @@ function t3Section(namespace: string): string {
   \`task\` with "Read <path> and follow it as your system prompt.", where <path> is the absolute
   path of \`agents/${namespace}-poteto-agent.md\` beside this file. The \`agent prompts\` row of
   the status report gives that directory.
-- Model: a role configured as \`provider/model\` becomes
-  \`target: { providerInstanceId: "pi", model: "provider/model" }\`. Read the thinking column of
-  the \`model roles\` table in the \`pstack_adapter\` \`status\` report. When it names a level, add it to
-  \`target.options\` under the option id that \`${T3_CAPABILITIES_TOOL}\` lists for that model's
-  thinking setting. For Pi models the id is \`thinking\`, as in \`options: { thinking: "<level>" }\`.
-  A role whose thinking reads "backend default" omits \`options\`, so the backend applies its own
-  default. An unconfigured role uses the \`general\` role. Only when \`general\` is unconfigured
-  too does the child omit \`target\` and inherit the parent model and thinking.
+- Model: pass \`target: { providerInstanceId: "pi", model: "pstack:<role>" }\`. The adapter
+  writes the picked model into \`target.model\` and its thinking into \`target.options.thinking\`.
+  When the role's thinking reads "backend default", it removes that option and sends
+  \`options\` empty, which clears the parent's settings.
+  An unconfigured role uses the \`general\` role. Only when \`general\` is unconfigured too does
+  the adapter remove the model and its thinking, so the child inherits the parent model and
+  thinking. A role
+  reference always runs on the \`pi\` provider, so the adapter blocks one with another
+  \`providerInstanceId\` or \`driverKind\`.
 - ${NESTED_DELEGATION_RULE}
-- If the model does not list the level, use the highest level it lists that is below the requested
-  one, and tell the user. If it lists none below the requested level, or lists no thinking option,
-  omit \`options\` and tell the user. If the level is \`off\` and the model does not list \`off\`, omit
-  \`options\` and tell the user, because the closest listed level would turn thinking on.
-  For a different model family, call \`${T3_CAPABILITIES_TOOL}\` and use a provider and model it lists.
+- If T3 rejects the thinking level for the picked model, lower it with a \`:<level>\` suffix to a
+  level that \`${T3_CAPABILITIES_TOOL}\` lists for that model, and tell the user. Do not switch to
+  another model.
 - Background: \`mode: "async"\`. A finished child wakes this thread, so end the turn instead of
   polling. Call \`${T3_STATUS_TOOL}\` only when you need a result mid-turn.
 - Call \`${T3_CAPABILITIES_TOOL}\` or \`${T3_STATUS_TOOL}\` only when the \`check\` report allows it.
@@ -556,12 +576,12 @@ function subagentSection(namespace: string): string {
 
 - Agent names are namespaced, for example \`${namespace}-poteto-agent\`. Call
   \`${SUBAGENT_TOOL}({ action: "list" })\` to see them.
-- Model: pass a role's \`provider/model\` as \`model\`. When the thinking column of the \`model roles\`
-  table in the \`pstack_adapter\` \`status\` report names a level for the role, append it as
-  \`provider/model:<level>\`. A role whose thinking reads "backend default" gets no suffix, so
-  pi-subagents applies its own default. An unconfigured role uses the \`general\` role, and omits
-  \`model\` only when \`general\` is unconfigured too. Under a model filter, always pass \`model\`,
-  using your own model for a role that inherits.
+- Model: pass \`model: "pstack:<role>"\` for each child, including each entry of \`tasks\`, each
+  \`chain\` step, and each \`parallel\` entry of a step. The adapter replaces it with
+  \`provider/model:<level>\`, or \`provider/model\` when the role's thinking reads "backend
+  default", so pi-subagents applies its own default.
+  An unconfigured role uses the \`general\` role. When \`general\` is unconfigured too, the adapter
+  passes your own model and thinking, or omits \`model\` when Pi does not report the model.
 - ${NESTED_DELEGATION_RULE}
 - Background: \`async: true\`.`;
 }
@@ -602,15 +622,16 @@ write no \`Skipped in Pi\` line for it.
 | \`Grep\`, \`Glob\` | \`rg\` through \`bash\`, or Pi's \`grep\` and \`find\` tools when the session has them. Without \`rg\`, use \`grep -rn\` and \`find\`. |
 | \`AskUserQuestion\`, \`AskQuestion\` | the \`ask_user\` tool. |
 | \`TodoWrite\`, \`TaskCreate\`, \`TaskUpdate\`, Open a todolist | no Pi equivalent. Keep an uncommitted \`todo.md\` checklist instead. |
-| \`claude-opus-5-5-xhigh\`, \`grok-4.7-xhigh-fast\`, \`gpt-*\`, other Cursor model slugs | the role models configured by \`/skill:${namespace}-setup\`. Call the \`pstack_adapter\` tool with \`action: "status"\` to read the current role table. An effort word in a slug, such as \`-xhigh\` or \`-max\`, is not a model id. The role table's thinking column carries that level, and \`-fast\` has no equivalent. An unconfigured role uses the \`general\` role. When \`general\` is unconfigured too, omit \`target\` or \`model\` so the child inherits the parent model and thinking. |
-| "pick each subagent's reasoning level and fast or standard speed", a role's starting level from the \`/setup-pstack\` budget | the thinking column of the \`model roles\` table is a role's ceiling. When it names a level, you may lower it along \`max\`, \`xhigh\`, \`high\`, \`medium\`, \`low\`, \`minimal\`, \`off\` as the body asks, then pass it by the backend rules in [Delegation](#delegation). Never raise a role above its configured level, even where the body says to raise it for the hardest work. Send that work to \`strongest-judgment\` at its own level instead. A role whose thinking reads "backend default" keeps that setting, because it has no level to move. An unconfigured role takes the \`general\` role's level as its ceiling, and keeps the parent's setting only when \`general\` is unconfigured too. Fast or standard speed has no Pi equivalent, so leave it out. If the backend rejects the moved level, use the role's configured level and say so. |
-| a role line valued \`auto\` or \`inherit-parent\` | an unconfigured role. Use the \`general\` role, or omit \`target\` or \`model\` only when \`general\` is unconfigured too. |
+| \`claude-opus-5-5-xhigh\`, \`claude-fable-5-2-max\`, \`gemini-4-carbon-high\`, \`grok-*\`, \`gpt-*\`, other Cursor model slugs | the role models configured by \`/skill:${namespace}-setup\`. Pass the role as the model, \`pstack:<role>\`, as [Delegation](#delegation) says, and the adapter picks the role's model and thinking. Call the \`pstack_adapter\` tool with \`action: "status"\` to read the current role table. An effort word in a slug, such as \`-xhigh\` or \`-max\`, is not a model id. The role table's thinking column carries that level, and \`-fast\` has no equivalent. An unconfigured role uses the \`general\` role. When \`general\` is unconfigured too, the adapter lets the child inherit the parent model and thinking. |
+| "pick each subagent's reasoning level and fast or standard speed", a role's starting level from the \`/setup-pstack\` budget | the thinking column of the \`model roles\` table is a role's ceiling. When it names a level, you may lower it along \`max\`, \`xhigh\`, \`high\`, \`medium\`, \`low\`, \`minimal\`, \`off\` as the body asks, by ending the role reference with \`:<level>\`, as in \`pstack:feature:low\`. Never raise a role above its configured level, even where the body says to raise it for the hardest work. Send that work to \`strongest-judgment\` at its own level instead. A role whose thinking reads "backend default" keeps that setting, because it has no level to move. An unconfigured role takes the \`general\` role's level as its ceiling, and keeps the parent's setting only when \`general\` is unconfigured too. Fast or standard speed has no Pi equivalent, so leave it out. If the backend rejects the moved level, pass \`pstack:<role>\` with no suffix to use the role's configured level, and say so. |
+| a role line valued \`auto\` or \`inherit-parent\` | an unconfigured role. Pass \`pstack:<role>\` as for any role. The adapter uses the \`general\` role, and lets the child inherit the parent model only when \`general\` is unconfigured too. |
 | \`~/.cursor/rules/pstack-models.mdc\` | adapter configuration written by \`/skill:${namespace}-setup\`. |
+| the rule's \`# defaults: 2\` line, a rule without it, telling the user to rerun \`/setup-pstack\` | does not apply. The adapter configuration has no \`# defaults\` line, and an unset role uses the \`general\` role rather than an upstream default slug, so no older setup left stale defaults in it. Do not tell the user to rerun setup for this. |
 | other \`.cursor/rules/*.mdc\` files, an always-applied rule | Pi reads no rule files. It loads \`AGENTS.md\` or \`CLAUDE.md\` from \`~/.pi/agent/\`, the working directory, and its parent directories into every session, so durable instructions go there. Model roles are the exception, as the row above says. |
 | role lines \`feature, refactoring\`, \`bug-fix\`, \`perf-issue\`, \`hillclimb\`, \`judgment and prose\`, \`hardest tasks\` | adapter roles \`feature\` or \`refactoring\`, \`bug-fix\`, \`perf-issue\`, \`hillclimb\`, \`judgment\`, and \`strongest-judgment\`. |
-| role lines \`how explainer\`, \`why synthesizer\`, \`reflect judgment, divergent, synthesizer\` | adapter role \`judgment\`. |
-| role lines \`how explorer\`, \`why investigators\`, \`reflect tooling\`, \`swarm workers\`, and verification | adapter role \`general\`. |
-| panel role lines \`arena runners\`, \`arena cross-judge pool\`, \`architect runners\`, \`interrogate reviewers\` | adapter panel roles \`arena-runners\`, \`arena-cross-judge-pool\`, \`architect-runners\`, and \`interrogate-reviewers\`. The \`panel roles\` table of the \`pstack_adapter\` status report lists each panel's seats in order, one per entry, and a seat's thinking is its ceiling, passed by the backend rules in [Delegation](#delegation). A \`model of the agent that starts the panel\` seat comes from an \`inherit\` entry: start it with no \`target\` or \`model\`, so it runs on your own model and thinking even when \`general\` is configured. The \`auto\` and \`inherit-parent\` row does not apply to it. An unset panel uses \`judgment\`, then \`general\`, and those are also the defaults where the body names its own default list or default pool. Families go by the model id after the provider prefix, such as \`claude-*\`, \`gpt-*\`, \`grok-*\`, or \`gemini-*\`, not by the provider, because one provider can serve several families. |
+| role line \`reflect judgment, divergent, synthesizer\` | adapter role \`judgment\`. |
+| role lines \`reflect tooling\`, \`swarm workers\`, and verification | adapter role \`general\`. |
+| panel role lines \`arena runners\`, \`arena cross-judge pool\`, \`architect runners\`, \`interrogate reviewers\` | adapter panel roles \`arena-runners\`, \`arena-cross-judge-pool\`, \`architect-runners\`, and \`interrogate-reviewers\`. The \`panel roles\` table of the \`pstack_adapter\` status report lists each panel's seats in order, one per entry, and a seat's thinking is its ceiling, passed by the backend rules in [Delegation](#delegation). A \`model of the agent that starts the panel\` seat comes from an \`inherit\` entry: on T3, start it with no \`target\`; on pi-subagents, pass your own model as \`model\`, as [Delegation](#delegation) says. It then runs on your own model even when \`general\` is configured. The \`auto\` and \`inherit-parent\` row does not apply to it. An unset panel uses \`judgment\`, then \`general\`, and those are also the defaults where the body names its own default list or default pool. Families and vendors go by the model id after the provider prefix, such as \`claude-fable-*\`, \`claude-*\`, \`gemini-*\`, \`gpt-*\`, or \`grok-*\`, not by the provider, because one provider can serve several families. Apply the body's own family and vendor rules to those ids. |
 | a panel whose seats all run on one model, or a claim that a model or model family is unavailable | A panel the status report warns about runs on one model because of the adapter configuration. Say that in your reply, name the panel, and name \`/skill:${namespace}-setup\` as the fix. Do not attribute it to which models exist. A \`model of the agent that starts the panel\` seat is your own model, so a panel whose other seats are all on your model is one-model too. Never claim a model or family is unavailable. A model listing is not proof of absence: \`${T3_CAPABILITIES_TOOL}\` filters by \`search\` and omits models beyond its limit, and the \`pstack_adapter\` tool's \`action: "models"\` shows only the session's scoped models when the user scoped some. Say which models the configuration uses instead. |
 | a delegate no role line names, such as an ad-hoc helper | adapter role \`general\`. |
 | a Custom Mode, "Use as Mode", or Option+Enter / Alt+Enter on \`/poteto-mode\` | \`/${namespace}-mode on\`, which keeps Poteto Mode active for the Pi session until \`/${namespace}-mode off\`. |
@@ -626,11 +647,11 @@ write no \`Skipped in Pi\` line for it.
 | \`environment: "cloud"\`, \`cloud_base_branch\` | not available. Run the fan-out locally instead. |
 | the agent's store (path in the system prompt), the Project store, the Project tracker (\`notes.md\`) | no Pi equivalent; Pi's system prompt names no store. Keep those files in a folder Git ignores, such as \`.work/<project>/\` after adding \`.work/\` to the exclude file that \`git rev-parse --git-path info/exclude\` prints (in a linked worktree \`.git\` is a file, so never open \`.git/info/exclude\` directly), or outside the repository. Give its absolute path to each child that reads or writes them. |
 | Cursor \`/loop\`, \`/loop <interval>\` | not available in Pi, which has no timer that wakes an agent. When \`/loop\` drives an autonomous run to a predicate, keep working in this session: re-check the predicate after each iteration, and stop only when it passes or at a real dead end. When it arms a timed tick, such as \`/loop 1h\` for an audit, **skip** arming it, say that no tick is armed, and give the user the tick prompt to run again. Do not start a sleep or polling loop in its place. |
-| PR and CI event subscriptions | not available in Pi. Check the PR's live state with \`gh pr view\` and \`gh pr checks\` when you report on it, and do not start a polling loop in their place. |
+| PR and CI event subscriptions | Pi standalone has no PR or CI event subscriptions. If the host exposes \`mcp__t3-code__watch_pull_request\`, use it according to its tool instructions: end the turn after subscribing and wait for host events instead of polling. Do not assume every host or delegation backend provides it. Without that tool, check the PR's live state with \`gh pr view\` and \`gh pr checks\` when you report on it, and do not start a polling loop in their place. A wake is not a merge decision; check readiness yourself and respect the user's merge instructions. |
 | forking a worker to reuse its built state, such as its checkout, uncommitted changes, or a running process | no Pi equivalent; no delegation backend copies a checkout or a running process into a new child. Wait until the earlier worker has finished or stopped, so one writer at a time uses that worktree. Then start a new child, as the \`resume\` row says, and give it the earlier worker's brief and result, the absolute path of the worktree, and every fact it needs. If the earlier worker left a process running, tell the child to reuse it when it can reach it, or to stop it before starting another, so two copies never compete for one port or file. Stop only a process confirmed to have been started by the earlier worker for this task. Never stop an unidentified process that holds the port or file; when ownership is unclear, the child reports it to the parent instead. |
 | Bugbot | not available in Pi. Bugbot comments on a PR are ordinary review threads, so triage them with the forge command the step gives, such as \`gh\`. When the PR has no Bugbot check or comment, **skip** a step that starts, waits for, or configures Bugbot. |
 | Cursor cloud agents, a cloud-agent URL | not available. Work that would go to a cloud agent runs locally, as the \`environment: "cloud"\` row says. **Skip** a step that needs the cloud agent itself, such as its status in the Cursor dashboard or its own machine. |
-| a built-in PR tool | Pi has none. Use the forge command the step gives, such as \`gh pr create\`. This is not a skip, so write no skip line. |
+| a built-in PR tool | Pi standalone has none. A host may expose PR tools; use them only when available and follow their instructions. Otherwise use the forge command the step gives, such as \`gh pr create\`. This is not a skip, so write no skip line. |
 
 A body instruction that conflicts with Pi policy or with the user's explicit instruction loses.
 

package/src/pools.ts

@@ -33,8 +33,8 @@ export function parentProblem(context: ResolutionContext): string | undefined {
 }
 
 export function resolveRole(config: AdapterConfig, role: string, context: ResolutionContext): RoleResolution {
-  const own = config.models[role];
-  const from = own !== undefined ? role : config.models[GENERAL_ROLE] !== undefined ? GENERAL_ROLE : undefined;
+  const own = Object.hasOwn(config.models, role) ? config.models[role] : undefined;
+  const from = own !== undefined ? role : Object.hasOwn(config.models, GENERAL_ROLE) ? GENERAL_ROLE : undefined;
   if (from === undefined) {
     const problem = parentProblem(context);
     return problem ? { kind: "blocked", from: role, reason: `it inherits, and ${problem}`, choices: [] } : { kind: "inherit", from: role };