pi-pstack-adapter 0.10.0 → 0.11.0

package/CHANGELOG.md

@@ -2,6 +2,13 @@
 
 All notable changes to this project are documented here. release-please writes new entries from Conventional Commit PR titles.
 
+## [0.11.0](https://github.com/elderfo/pi-pstack-adapter/compare/v0.10.0...v0.11.0) (2026-11-15)
+
+
+### Features
+
+* **pstack:** certify pstack 0.15.42 ([#35](https://github.com/elderfo/pi-pstack-adapter/issues/35)) ([10fd682](https://github.com/elderfo/pi-pstack-adapter/commit/10fd6827a09376d499cbc82ee3e720871ef7c74e))
+
 ## [0.10.0](https://github.com/elderfo/pi-pstack-adapter/compare/v0.9.0...v0.10.0) (2026-11-05)
 
 

package/README.md

@@ -9,9 +9,9 @@ Use Cursor's [pstack](https://github.com/cursor/plugins/tree/main/pstack) skills
 
 pstack is Cursor's collection of engineering workflows: design reviews (`how`), prose cleanup
 (`unslop`), test-driven development (`tdd`), parallel fan-out (`swarm`), and the full Poteto Mode
-working style. This package downloads a tested pstack release and exposes every workflow as a
-Pi skill named `pistack-*`. The upstream files stay unmodified, so you can audit exactly what
-the agent reads.
+working style. This package downloads a tested pstack release and gives you every workflow as a
+Pi skill named `pistack-*`. The upstream files stay unmodified, so you can audit what the agent
+reads.
 
 ## Quick start
 
@@ -44,42 +44,7 @@ commands, so keep the `bash` tool active rather than switching to Pi's `powershe
 `/pistack-status` warns when Bash is missing or the `bash` tool is inactive. Pi inside WSL
 counts as Linux.
 
-### Add optional providers for delegating workflows
-
-Some workflows hand work to subagents or ask you multiple-choice questions. Two providers can run
-the subagents:
-
-- **T3 Code.** When Pi runs inside [T3 Code](https://github.com/pingdotgg/t3code), workflows
-  delegate through T3's `delegate_task` tool. Each child appears in T3, can run on any provider
-  and model T3 offers, and can work in its own worktree. You install nothing extra.
-- **pi-subagents.** Outside T3 Code, install `pi-subagents`. The upstream agents register as
-  `pistack-comment-sicko` and `pistack-poteto-agent`.
-
-For multiple-choice questions, install `pi-ask-user`:
-
-```bash
-pi install npm:pi-subagents
-pi install npm:pi-ask-user
-```
-
-The adapter uses T3 Code first and falls back to `pi-subagents`. To reverse that order, set
-`"delegation": "pi-subagents"` in the adapter config, or set `PISTACK_DELEGATION=pi-subagents`.
-Restart Pi or run `/reload` after changing it. `/pistack-status` shows the order and the
-provider the session resolved.
-
-The adapter counts T3's tools, including `task_status` and `orchestrator_capabilities`, only
-when T3 Code's own bridge registered them. A tool that another extension or MCP server registers
-under the same name is ignored, and `/pistack-check <skill>` names the one tool to delegate with.
-
-When a delegating workflow starts, the adapter turns on that provider's tool, even if you turned
-it off in the tool selector. This happens
-whether you run the workflow's `/skill:` command or the agent opens the skill itself. While Poteto
-Mode is on, the adapter turns it on for every prompt.
-
-To find missing providers or executables before you start a workflow, run
-`/pistack-check <skill>`.
-
-## Install from Git instead of npm
+### Install from Git instead of npm
 
 To track the repository directly, install from GitHub:
 
@@ -87,8 +52,10 @@ To track the repository directly, install from GitHub:
 pi install git:github.com/elderfo/pi-pstack-adapter
 ```
 
-To pin a release, add its tag, for example `git:github.com/elderfo/pi-pstack-adapter@v0.3.0`.
-For a pinned npm release, use `npm:pi-pstack-adapter@0.3.0`.
+To pin a release, add a tag from the
+[releases page](https://github.com/elderfo/pi-pstack-adapter/releases), as in
+`git:github.com/elderfo/pi-pstack-adapter@v<version>`. For a pinned npm release, use
+`npm:pi-pstack-adapter@<version>`.
 
 ## Run pstack workflows
 
@@ -106,153 +73,199 @@ Before you run a workflow, check what it needs:
 /pistack-check how
 ```
 
-The check reports the workflow's support tier and any missing capabilities or executables.
+The check reports the workflow's support tier and any providers or executables you still need
+to install.
 
 The adapter also adds these commands:
 
 | Command | What it does |
 | --- | --- |
-| `/pistack-status` | Shows versions, the resolved commit, trust, capabilities, support tiers, and diagnostics. |
+| `/pistack-status` | Shows versions, the pstack commit in use, trust, capabilities, support tiers, and diagnostics. |
 | `/pistack-check <skill>` | Checks one workflow's requirements. |
-| `/pistack-mode on\|off\|status` | Turns Poteto Mode on or off for the current session. |
-| `/skill:pistack-setup` | Assigns Pi models to pstack roles or changes the upstream source. |
-| `/skill:pistack-status` | Asks the agent to produce the status report. |
+| `/pistack-mode on\|off\|status` | Turns Poteto Mode on or off for every prompt in the current session. |
+| `/skill:pistack-setup` | Assigns Pi models to pstack roles, sets a model filter, or changes the pstack source. |
+| `/skill:pistack-status` | Asks the agent to produce the status report and explain it. |
 
-## Check how well a workflow is supported
+### Check how well a workflow is supported
 
 `/pistack-status` lists a support tier for each skill:
 
 | Tier | Meaning |
 | --- | --- |
 | `native` | The skill needs no Pi-specific changes, or the adapter supplies a Pi version. |
-| `adapted` | The upstream body works with the host mappings in its wrapper. |
-| `dependency-gated` | The workflow needs a capability or executable that may be missing. |
+| `adapted` | The skill works in Pi with the instructions the adapter adds to it. |
+| `dependency-gated` | The workflow needs a provider or executable that may be missing. |
 | `experimental` | Part of the workflow has no direct Pi equivalent. |
-| `unsupported` | Pi cannot provide a required host feature. |
+| `unsupported` | Pi cannot provide a feature the workflow requires. |
 
 The [compatibility registry](docs/compatibility.md) lists the tier and requirements of every
 skill.
 
+## Set up workflows that delegate or ask questions
+
+Some workflows hand work to subagents or ask you multiple-choice questions. Two providers can run
+the subagents:
+
+- **T3 Code.** When Pi runs inside [T3 Code](https://github.com/pingdotgg/t3code), workflows
+  delegate through T3's `delegate_task` tool. Each child appears in T3, can run on any provider
+  and model T3 offers, and can work in its own worktree. You install nothing extra.
+- **pi-subagents.** Outside T3 Code, install `pi-subagents`. The pstack agents appear as
+  `pistack-comment-sicko` and `pistack-poteto-agent`.
+
+For multiple-choice questions, install `pi-ask-user`:
+
+```bash
+pi install npm:pi-subagents
+pi install npm:pi-ask-user
+```
+
+When both providers are available, the adapter uses T3 Code. To prefer `pi-subagents`, set
+`"delegation": "pi-subagents"` in the adapter config, or set `PISTACK_DELEGATION=pi-subagents`.
+Restart Pi or run `/reload` after changing it. `/pistack-status` shows the order and the
+provider the session uses.
+
+When a delegating workflow starts, the adapter turns on that provider's tool, even if you turned
+it off in the tool selector. While Poteto Mode is on, it turns the tool on for every prompt.
+
+The adapter uses T3's tools only when T3 Code itself provides them. It ignores a tool with the
+same name from another extension or MCP server.
+
 ## Choose models for pstack roles
 
 pstack assigns work to named model roles such as `feature`, `bug-fix`, and `judgment`. The
 `general` role covers every other delegate, such as explorers, swarm workers, and ad-hoc helpers.
-A role you leave unset uses `general`, and uses the model of the agent that starts it only when
-`general` is unset too.
+A role you leave unset uses `general`. When `general` is unset too, the role uses the model of the
+agent that starts it.
 
-To list the models in your Pi installation and assign them to roles, run the setup skill:
+To see the models in your Pi installation and assign them to roles, run the setup skill:
 
 ```text
 /skill:pistack-setup
 ```
 
-In a noninteractive session, set roles with `PISTACK_MODELS`:
+The setup skill saves your choices in a config file. To set roles in a file or an environment
+variable yourself, see [Set roles without the setup skill](#set-roles-without-the-setup-skill).
 
-```bash
-PISTACK_MODELS='feature=provider/model,bug-fix=provider/other-model' pi
-```
+### Thinking levels
 
-Add a thinking level to a role with a `:level` suffix. The levels are `off`, `minimal`, `low`,
-`medium`, `high`, `xhigh`, and `max`:
+Each role can also have a thinking level: `off`, `minimal`, `low`, `medium`, `high`, `xhigh`, or
+`max`. The level is a ceiling. A delegate may lower it for routine work but never raises it. A
+role without a level passes none, so the provider uses its own default. If the model does not
+offer the level, Pi limits it to what the model supports. Under T3 Code, T3 may reject the level
+instead. The agent then lowers the level to one the model offers and tells you.
 
-```bash
-PISTACK_MODELS='feature=provider/model:medium,judgment=provider/other-model:high' pi
-```
+A role you leave unset, with `general` unset too, inherits the model and thinking level of the
+agent that starts it. A `strongest-judgment` delegate at `xhigh` would then start every helper at
+`xhigh`. Set `general` to keep helpers at a cheaper level.
 
-Panels such as `arena`'s runners and judge, `architect`'s runners, and `interrogate`'s adversaries
-use the panel roles `arena-runners`, `arena-cross-judge-pool`, `architect-runners`, and
-`interrogate-reviewers`. A panel holds a list of models, one seat each, separated by spaces.
-An `inherit` entry uses the model and thinking of the agent that starts the panel, which is
-your session unless a delegate runs the workflow:
+### Panels
 
-```bash
-PISTACK_MODELS='arena-runners=provider/model:high other-provider/other-model:high' pi
-```
+Some workflows run several models side by side: `arena`'s runners, `architect`'s runners, and
+`interrogate`'s adversaries. Their panel roles are `arena-runners`, `architect-runners`, and
+`interrogate-reviewers`. A panel lists up to eight models, and each one gets a seat. An `inherit`
+seat uses the model and thinking level of the agent that starts the panel, which is your session
+unless a delegate runs the workflow.
+
+The `arena-cross-judge-pool` role works differently. `arena`, and `architect` through it, pick
+one judge from this list, the first model from a vendor other than your session's. pstack counts
+Claude Fable and the other Claude models as one vendor. When no entry
+qualifies, `arena` tries `judgment`, then `general`. If neither qualifies, it skips the judge and
+says so. An `inherit` entry never judges.
+
+Upstream pstack gives each panel models from several model families. A panel you
+leave unset uses `judgment`, then `general`, so it covers two families only when those roles do.
+The status report warns when a panel's seats all run on one model.
+
+### Pools
 
-Upstream pstack defaults each panel to two model families. A panel you leave unset uses
-`judgment`, then `general`, so it covers two families only when those roles do. The status
-report warns when a panel's seats all run on one model.
+A role can list up to eight models in order of preference. Each delegation for that role runs on
+the first model that the [model filter](#restrict-which-models-delegation-uses) allows. When a
+task clearly suits another model in the pool, the agent may pick that one instead, and it tells
+you which model it picked and why. It cannot pick a model outside the pool.
 
-### Give a role a pool of models
+A pool runs one model per task, and a runner panel runs every seat. A pool is also not a retry list.
+When a delegation fails, the agent reports the failure and does not move on to the next model.
 
-An ordinary role can list several models instead of one. The list is a ranking. The agent
-delegates by role, passing `pstack:<role>` as the model, and the adapter rewrites the call to the
-first model in the ranking that the filter allows, at that entry's thinking level. The agent that
-delegates may override the ranking with `pstack:<role>@<provider/model>` when the task clearly
-fits another model from the pool better, and it says which model it picked and why. The adapter
-blocks an override that is not an allowed entry of the pool. A `:<level>` suffix, as in
-`pstack:feature:low`, lowers the thinking level and never raises it above the configured one.
-A pool is not a panel: a panel runs one seat per entry, but a pool starts one
-child per task. A pool is not a retry list either: when a delegation fails, the agent reports the
-failure and does not try the next model. In a config file a pool is a JSON list:
+### Set roles without the setup skill
+
+In a config file, a role takes one model, a pool takes a list, and a panel takes a string of
+seats separated by spaces. Add a thinking level to any model with a `:level` suffix:
 
 ```json
-{ "models": { "feature": ["provider/model-a:high", "provider/model-b:high", "provider/model-c"] } }
+{
+  "models": {
+    "general": "provider/cheap-model:low",
+    "judgment": "provider/strong-model:high",
+    "feature": ["provider/model-a:high", "provider/model-b:high", "provider/model-c"],
+    "arena-runners": "provider/model-a:high other-provider/model-d:high"
+  }
+}
 ```
 
-The `set_model` action takes the same list in `model`, and its `thinking` applies to each entry
-without its own `:level`. Every entry must be a model in your Pi installation, or nothing is
-written. In `PISTACK_MODELS`, separate a pool's entries with `|`:
+For a noninteractive session, set the same values in `PISTACK_MODELS`. Separate roles with
+commas and a pool's entries with `|`:
 
 ```bash
-PISTACK_MODELS='feature=provider/model-a:high|provider/model-b' pi
+PISTACK_MODELS='general=provider/cheap-model:low,feature=provider/model-a:high|provider/model-b' pi
+PISTACK_MODELS='arena-runners=provider/model-a:high other-provider/model-d:high' pi
 ```
 
-A panel keeps its string of seats. An unset panel's two default seats are delegated as
-`pstack:judgment` and `pstack:general`, so each runs once on the first allowed model of its pool,
-unless the delegating agent overrides the ranking.
-
-### Restrict which models delegation uses
-
-A model filter limits delegation to some models without changing the role assignments, for
-example to run an experiment on one model family only. Ask the agent, or call the
-`pstack_adapter` tool's `set_filter` action:
-
-- `include: ["gpt-*"]` allows only models whose id starts with `gpt-`.
-- `exclude: ["*claude*"]` excludes model ids containing `claude`, including Bedrock-style ids.
-- `clear: true` removes the filter at that scope.
-
-A pattern with a `/` matches `provider/model`, and one without matches the model id after the
-provider. `*` is the only wildcard, and matching ignores case. A model must match an `include`
-pattern when there are any, and must match no `exclude` pattern.
-
-A filter applies to the current session by default and is not saved. Pass `scope: "user"` or
-`scope: "project"` to save it as `modelFilter` in that config file. A saved filter takes effect
-at once, and a filter set for the session wins over a saved one until you clear it. The
-`model filter` row of `/pistack-status` shows the filter in force and where it came from.
-A trusted project's filter replaces the user filter as a whole, including an empty filter.
-Empty lists set an unrestricted override; clearing the session filter restores the saved filter.
-Wait for `set_filter` to finish before starting delegations, rather than issuing them together.
-
-Under a filter, the status report and `/pistack-check` mark each pool entry as allowed or
-excluded. A role with no allowed entry is blocked: its work is not moved to `general` or to the
-session's model. A role that inherits is blocked when the filter excludes the session's model.
-A panel seat on an excluded model is blocked, and the other seats still run.
-
-The adapter also checks every `delegate_task` and `subagent` call in the session, including
-calls that no pstack workflow made, and blocks one whose model the filter excludes or that it
-cannot check. That includes a call with no model while the session's model is excluded, a model
-Pi does not know, a T3 provider other than Pi, a `subagent` child without a model, a `subagent`
-workflow script, and a `subagent` action that restarts, refines, steers, or schedules a child,
-opens a project session, or configures a watchdog. A T3 target with a named environment is also
-blocked because its registry may differ. A blocked call is not retried. These limits apply:
-
-- A child does not inherit a session filter, so the agent puts it into each brief as an
-  instruction. A saved filter applies in a child where the adapter loads the same config files.
-- Other tools that start agents or processes, such as T3 Code's thread tools or a shell command,
-  are not checked. The filter does not block a provider or a model inside Pi.
-- Changing models with `/model` is not affected.
-- The filter is a model-selection guard, not an access-control boundary. The agent can change it
-  through `set_filter`, but is instructed to keep it unchanged unless the user requests a change.
-
-Role names are lowercase letters, digits, and hyphens. A model value is printable ASCII with no spaces or markup characters, at most 128 characters. A config entry that breaks these rules stops the adapter at startup with an error that names the file, so fix the key there and restart Pi.
-
-A role without a level passes none, so the delegation backend applies its own default. A role's
-level is a ceiling: a delegate may lower it for routine work but never raises it. A role you leave
-unset, with `general` unset too, inherits the model and thinking level of the agent that starts
-it. A `strongest-judgment` delegate at `xhigh` would then start every helper at `xhigh`, so set
-`general` to keep helpers at a cheaper level. The `pstack_adapter` tool's `set_model` action takes the same
-level in its `thinking` parameter. A level the model does not offer is clamped by Pi at run time.
+Role names use lowercase letters, digits, and hyphens. A model value is printable ASCII with no
+spaces or markup characters, at most 128 characters. If an entry breaks these rules, the adapter
+stops at startup with an error that names the file. Fix the entry and restart Pi.
+
+## Restrict which models delegation uses
+
+A model filter limits delegation to some models without changing your role assignments, for
+example to run an experiment on one model family. Ask the agent, for example "only delegate to
+GPT models", or run `/skill:pistack-setup`. A filter has two lists of patterns:
+
+- `include` lists the models delegation may use. `["gpt-*"]` allows only model ids that start
+  with `gpt-`.
+- `exclude` lists the models delegation may not use. `["*claude*"]` blocks every model id that
+  contains `claude`, including Bedrock-style ids.
+
+A pattern with a `/` matches `provider/model`, and one without matches the part of the id after
+the last `/`. `*` is the only wildcard, and matching ignores case. A model must match an `include`
+pattern when the list has any, and must match no `exclude` pattern.
+
+A filter lasts for the current session unless you ask the agent to save it. A saved filter goes
+in your user or project config file as `modelFilter`, for example
+`{ "modelFilter": { "include": ["gpt-*"] } }`, and takes effect at once. A session filter
+overrides a saved one until you clear it. A project's saved filter replaces your user filter
+entirely. The `model filter` row of `/pistack-status` shows the filter in force and where it came
+from.
+
+### What the filter blocks
+
+The status report and `/pistack-check` mark each pool entry as allowed or excluded. The adapter
+blocks a role with no allowed entry, and does not move its work to `general` or to your session's
+model. It blocks a role that inherits when the filter excludes your session's model. It blocks a
+panel seat on an excluded model, and the other seats still run.
+
+The adapter checks every `delegate_task` and `subagent` call in the session, not only the calls
+pstack workflows make. It blocks a call that would run on an excluded model, and a call it
+cannot check, such as:
+
+- a call with no model while the filter excludes your session's model
+- a model Pi does not know
+- a T3 provider other than Pi, or a T3 target that names an environment
+- a `subagent` child without a model, or a `subagent` workflow script
+- a `subagent` action that restarts, refines, steers, or schedules a child, opens a project
+  session, or configures a watchdog
+
+The agent does not retry a blocked call.
+
+### What the filter does not cover
+
+- A child agent does not inherit a session filter. The agent includes the filter in each child's
+  instructions instead. A saved filter applies in a child that loads the same config files.
+- The adapter does not check other tools that start agents or processes, such as T3 Code's
+  thread tools or a shell command.
+- The filter does not block a provider or a model inside Pi, and it does not affect switching
+  models with `/model`.
+- The filter guards model choice. It is not a security boundary. The agent can change it, but its
+  instructions say to keep it unless you ask for a change.
 
 ## Run Pi noninteractively
 
@@ -275,13 +288,28 @@ To select a branch, tag, commit, repository, or local checkout, run `/skill:pist
 adapter asks you to confirm before it changes the source. Restart Pi or run `/reload` afterward.
 
 A branch or tag resolves to one commit when you select it. The adapter records that commit and
-does not move it on later starts. `/pistack-status` warns when you use a custom repository or a
-revision the adapter has not certified.
+does not move it on later starts. The `trust` row of `/pistack-status` tells you how far to trust
+the source:
+
+| Trust | Meaning |
+| --- | --- |
+| `tested` | The certified commit from the official repository. |
+| `untested-ref` | A source from the official repository without this release's certified pin. This release has not verified it. |
+| `untested-repo` | A custom repository. Its code runs with your permissions, so review it first. |
+| `local` | A local checkout. Its contents are unverified and can differ between machines. |
 
 ## Configuration reference
 
-The setup skill writes user settings to `~/.pi/agent/pi-pstack-adapter.json` and project
-settings to `.pi/pi-pstack-adapter.json`. Environment variables override both files:
+The adapter reads settings from these places. A later one overrides an earlier one:
+
+1. Your user config, `~/.pi/agent/pi-pstack-adapter.json`.
+2. The project config, `.pi/pi-pstack-adapter.json` in the working directory. Pi reads it only
+   after you trust the project, and a project cannot change `namespace`.
+3. Environment variables.
+
+The setup skill writes both files. The keys you are most likely to edit are `models`,
+`modelFilter`, and `delegation`. The setup skill also records the pstack source there, so change
+the source through it.
 
 | Variable | Effect |
 | --- | --- |

package/VERSION

@@ -1 +1 @@
-0.10.0
+0.11.0

package/adapter-skills/setup.md

@@ -4,17 +4,17 @@ Upstream pstack ships a `setup-pstack` skill that writes `~/.cursor/rules/pstack
 a Cursor-only always-applied rule full of Cursor model slugs. Pi has neither that file nor
 those models, so this adapter replaces the body with the Pi equivalent.
 
-Four things are configurable. Model roles, the model filter, the upstream source, and the
+You can configure four things: model roles, the model filter, the upstream source, and the
 delegation order.
 
 ## Model roles
 
-pstack skills name a model per role. In Pi those names mean nothing, so each role maps to a
-model in your own catalogue. A role you never configure uses the `general` role. When `general` is
+pstack skills name a model per role. Pi has no such models, so each role maps to a
+model in your Pi installation. A role you never configure uses the `general` role. When `general` is
 unconfigured too, the role inherits the model of whichever agent starts it, which is a working
 default, not a failure.
 
-Roles used by pstack workflows.
+pstack workflows use these roles.
 
 | role | used by |
 | --- | --- |
@@ -37,11 +37,13 @@ keeps them as panel roles.
 | `architect-runners` | `architect`'s design candidates |
 | `interrogate-reviewers` | `interrogate`'s adversaries |
 
-Upstream defaults each panel to two model families, one Claude model and one Grok model. A panel
+Upstream defaults each panel to one Claude Fable, one Claude Opus, and one Gemini model. A panel
 left unset uses `judgment`, then `general`, so it spans two families only when those roles do.
-`arena` takes its judge from the pool only when the model is from a family other than the
-session's model, so a pool on the session's family skips the judge. The status report warns when
-a panel's seats all land on one model.
+`arena` takes its judge from the pool only when the model is from a vendor other than the
+session model's, and it counts Fable and the other Claude models as one vendor. When no pool entry
+qualifies, it tries `judgment`, then `general`, and skips the judge only when neither does. The
+status report warns when
+a panel's seats all use one model.
 
 A panel value lists entries in order. An entry is a model id, optionally with a thinking level,
 or `inherit` for the model and thinking of the agent that starts the panel, which is the
@@ -59,16 +61,16 @@ configure `general` to stop that. A role's level is a ceiling: delegates may low
 work, but never raise it. Model choice often affects cost more than thinking level does, so
 consider a cheaper model for the bulk roles as well.
 
-Steps.
+Follow these steps.
 
 1. Call the adapter tool with `action: "models"` to list the provider and model ids this Pi
-   installation can actually reach. Do not invent ids.
+   installation can reach. Do not invent ids.
 2. Ask the user which model each role should use. Offer the listed ids, and offer
    `inherit` for any role they do not care about. Use the structured question tool when it is
-   available; otherwise ask in plain text. Only ids from step 1 are accepted. A user who wants
-   alternatives for a role gets a pool: a ranked list of models. The adapter runs each delegation
-   on the first one the model filter allows, unless the delegating agent overrides the ranking
-   for that task, so ask for the order.
+   available; otherwise ask in plain text. The tool accepts only ids from step 1. For a user who
+   wants alternatives for a role, offer a pool, which is a ranked list of models. Ask for the
+   ranking. The adapter normally picks the first model the filter allows. The delegating agent
+   may pick another allowed entry for a particular task.
    A pool is a set of choices, not a retry list and not a panel, so say that when you offer it.
 3. Ask for a thinking level. Do not assume the user wants none. Skip this step only when every
    role is on `inherit`. It applies to every role that got a model in step 2. A role on
@@ -91,8 +93,9 @@ Steps.
    only when the user says it should differ from its group. Backend default passes no level and
    leaves the choice to the delegation backend. A Custom user who wants thinking disabled picks
    `off`.
-   A model may not offer every level. A level it lacks is clamped when it runs, so say that
-   instead of asking again. The tool rejects any level other than `off` on a model that has no reasoning support.
+   A model may not offer every level. Pi clamps a level it lacks when the role runs. Under T3 Code,
+   T3 may reject the level instead, and the delegating agent then lowers it and tells the user.
+   Say that instead of asking again. The tool rejects any level other than `off` on a model that has no reasoning support.
    When it does, set that role with no level and tell the user which role has none.
 4. For each role, call the adapter tool with `action: "set_model"`, the role, the chosen
    `provider/model` id, and `thinking` when step 3 picked a level. For a pool, pass `model` as a
@@ -103,7 +106,9 @@ Steps.
    pass it again.
 5. Set the panels. Read the `panel roles` table of `action: "status"` and show the user each
    panel's seats. When a panel's seats share one model, or one family, say so and suggest two
-   families from step 1, as upstream's defaults do. Never say a family is missing unless the
+   families from step 1, as upstream's defaults do. For `arena-cross-judge-pool`, suggest models
+   from two vendors, because a Fable and an Opus model are one vendor, so that pool has no eligible
+   judge for a Claude session, and arena falls back to `judgment`, then `general`. Never say a family is missing unless the
    step 1 list shows it. Ask whether to keep each panel or set it. For each panel the user sets,
    call `set_model` with the panel role and its entries in `model`, separated by commas, for
    example `model: "provider/model-a, provider/model-b"`. Pass `thinking` for the level of the
@@ -116,8 +121,8 @@ For a scripted environment, set `PISTACK_MODELS` instead, for example
 `PISTACK_MODELS=feature=anthropic/claude-sonnet-4-5:medium,bug-fix=openai/gpt-5:high`. The
 optional `:level` suffix sets the thinking level. A pool's entries are separated by `|`, as in
 `feature=anthropic/claude-sonnet-4-5:high|openai/gpt-5:high`. A panel's entries are separated by spaces, as
-in `PISTACK_MODELS='arena-runners=anthropic/claude-sonnet-4-5:high openai/gpt-5:high'`. The environment wins
-over both config files, so CI never needs this dialog.
+in `PISTACK_MODELS='arena-runners=anthropic/claude-sonnet-4-5:high openai/gpt-5:high'`. `PISTACK_MODELS` overrides
+both config files, so CI does not need this dialog.
 
 ## Model filter
 
@@ -129,10 +134,11 @@ without rewriting the roles. Call the adapter tool with `action: "set_filter"` a
 - `clear: true` to remove the filter at that scope.
 
 A pattern with `/` matches `provider/model`; one without matches the model id. `*` is the only
-wildcard. The filter applies to this session only, unless the user asks to save it: then pass
-`scope: "user"` or `scope: "project"`. A session filter wins over a saved one until it is cleared.
-A trusted project's filter replaces the user filter as a whole. Empty lists set an unrestricted
-override; clearing the session filter restores the saved filter. Wait for `set_filter` to finish
+wildcard. The filter applies to this session only. When the user asks to save it, pass
+`scope: "user"` or `scope: "project"`. A session filter wins over a saved one until you clear it.
+A trusted project's filter replaces the user filter as a whole. Empty `include` and `exclude`
+lists set an override that allows every model. Clearing the session filter restores the saved
+filter. Wait for `set_filter` to finish
 before issuing delegation calls. Keep the active filter unchanged unless the user requests a change.
 
 Read back `action: "status"`. Report the `model filter` row, and any role or panel seat the
@@ -140,34 +146,35 @@ Read back `action: "status"`. Report the `model filter` row, and any role or pan
 Tell the user the limits: the adapter blocks `delegate_task` and `subagent` calls in this session
 that the filter does not allow. A child does not inherit a session filter and follows it only as
 an instruction in its brief. A saved filter applies in a child where the adapter loads the same
-config files. Other tools that start agents are not checked. This is a model-selection guard,
+config files. The adapter does not check other tools that start agents. This is a model-selection guard,
 not an access-control boundary.
 
 ## Upstream source
 
 By default the adapter uses the pstack revision this release was tested against. Change it only
-when you are deliberately testing another revision.
+to test another revision.
 
 Call the adapter tool with `action: "set_source"` and one of these.
 
-- `ref` with a branch, tag, or commit. A branch or tag is resolved to a commit once, here, and
-  recorded. Later sessions keep that commit. The adapter never advances it on its own.
+- `ref` with a branch, tag, or commit. The adapter resolves a branch or tag to a commit once, during
+  this call, and records it. Later sessions keep that commit. The adapter never advances it on its own.
 - `repo` with another repository. This is outside the tested trust boundary.
 - `localPath` with a directory holding a pstack checkout. Use this when developing pstack itself.
 
 The adapter asks the user to confirm every source change itself and refuses without an
-interactive session, so a change cannot happen on your say-so alone. Explain the consequence in
+interactive session, so you cannot change the source without the user's confirmation. Explain the consequence in
 plain words before you call it, and report a refusal as a refusal.
 
-Regeneration happens on the next Pi start. Tell the user to restart Pi, or run `/reload`.
+The adapter regenerates its wrappers on the next Pi start. Tell the user to restart Pi, or run
+`/reload`.
 
 ## Delegation order
 
 Delegating workflows try T3 Code's `delegate_task` first, then pi-subagents' `subagent`. A user
 who wants `subagent` first sets `"delegation": "pi-subagents"` in the adapter config file, or
 `PISTACK_DELEGATION=pi-subagents`. The adapter tool has no action for this. Tell the user which
-file to edit: the `config layers` row of the status report lists them. Regeneration happens on
-the next Pi start.
+file to edit: the `config layers` row of the status report lists them. The change takes effect
+on the next Pi start.
 
 ## Finish
 

package/adapter-skills/status.md

@@ -1,7 +1,7 @@
 # pstack adapter status
 
-Report what the adapter is actually running, so nobody has to guess whether a pstack workflow
-is verified here.
+Report what the adapter is running, so the user can see whether a pstack workflow is verified
+here.
 
 1. Call the adapter tool with `action: "status"`.
 2. Show the user the full report. Do not summarize away the trust line, the resolved commit, or
@@ -15,7 +15,7 @@ To check one workflow before starting it, call the tool with `action: "check"` a
 name. That reports the capabilities and executables that workflow needs and whether this
 environment has them, before the workflow does any work.
 
-Support tiers mean this.
+The support tiers mean the following.
 
 | tier | meaning |
 | --- | --- |

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 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. |
+| `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
 
@@ -434,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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-pstack-adapter",
-  "version": "0.10.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/generate.ts

@@ -622,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\`. 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. |
+| \`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\`. |

package/src/registry.ts

@@ -7,7 +7,7 @@ import type { CapabilityId, RegistryEntry, SupportTier } from "./types.ts";
  */
 export const SKILL_REGISTRY: Readonly<Record<string, RegistryEntry>> = {
   "architect": { tier: "dependency-gated", capabilities: ["delegation"], executables: [], note: "Phase B delegates to arena runners, so it cannot run without parallel subagents." },
-  "arena": { tier: "adapted", capabilities: ["delegation"], executables: ["git"], note: "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": { tier: "adapted", capabilities: ["delegation"], executables: ["git"], note: "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." },
   "automate-me": { tier: "experimental", capabilities: ["delegation", "structured-question"], executables: ["git", "gh"], note: "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." },
   "benchmark-checklist": { tier: "dependency-gated", capabilities: [], executables: ["uptime", "nproc"], note: "Its setup step checks load with `uptime` and cores with `nproc`. macOS has no `nproc` without GNU coreutils, and Git Bash on Windows has no `uptime`." },
   "blast-radius": { tier: "dependency-gated", capabilities: [], executables: ["git", "gh"], note: "Needs git and gh to read the diff, commits, and PR before any analysis." },
@@ -16,7 +16,7 @@ export const SKILL_REGISTRY: Readonly<Record<string, RegistryEntry>> = {
   "create-formal-verification-skill": { tier: "adapted", capabilities: [], executables: [], note: "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": { tier: "adapted", capabilities: [], executables: [], note: "Only the generated skill's output path needs remapping to Pi's skill directory." },
   "figure-it-out": { tier: "dependency-gated", capabilities: ["delegation"], executables: [], note: "Phase B fan-out and the architect/arena routing require parallel subagents." },
-  "how": { tier: "dependency-gated", capabilities: ["delegation"], executables: [], note: "Every path spawns explorer or explainer subagents; nothing runs inline." },
+  "how": { tier: "dependency-gated", capabilities: ["delegation"], executables: [], note: "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." },
   "in-your-own-words": { tier: "native", capabilities: [], executables: [] },
   "interrogate": { tier: "adapted", capabilities: ["delegation"], executables: ["git"], note: "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." },
   "ketchup": { tier: "adapted", capabilities: [], executables: [], note: "Read-only. Pi has no `/visualize` skill or image generation, so its visuals are Mermaid diagrams and screenshots that already exist. It checks PR and CI state only for work the chat touched." },
@@ -26,7 +26,7 @@ export const SKILL_REGISTRY: Readonly<Record<string, RegistryEntry>> = {
   "make-bot-ui": { tier: "unsupported", capabilities: [], executables: ["curl", "tailscale", "sudo"], note: "Built entirely on Cursor Automations webhook routines and the secret-request card." },
   "no-comments": { tier: "dependency-gated", capabilities: ["delegation"], executables: ["git"], note: "Step 1 must spawn the comment-sicko agent; the skill only triages its report." },
   "poteto-help": { tier: "experimental", capabilities: [], executables: [], note: "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": { tier: "experimental", capabilities: ["delegation", "structured-question"], executables: ["git", "gh"], note: "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." },
+  "poteto-mode": { tier: "experimental", capabilities: ["delegation", "structured-question"], executables: ["git", "gh"], note: "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." },
   "principle-attack-the-premise": { tier: "native", capabilities: [], executables: [] },
   "principle-boundary-discipline": { tier: "native", capabilities: [], executables: [] },
   "principle-build-the-lever": { tier: "native", capabilities: [], executables: [] },
@@ -51,19 +51,19 @@ export const SKILL_REGISTRY: Readonly<Record<string, RegistryEntry>> = {
   "principle-subtract-before-you-add": { tier: "native", capabilities: [], executables: [] },
   "principle-test-behavior-not-implementation": { tier: "native", capabilities: [], executables: [] },
   "principle-type-system-discipline": { tier: "native", capabilities: [], executables: [] },
-  "recall": { tier: "dependency-gated", capabilities: ["delegation"], executables: ["git", "gh"], note: "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." },
+  "recall": { tier: "dependency-gated", capabilities: ["delegation"], executables: ["git", "gh"], note: "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." },
   "reflect": { tier: "experimental", capabilities: ["delegation"], executables: [], note: "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." },
   "setup-pstack": { tier: "native", capabilities: [], executables: [], rename: "setup", replacement: "setup.md", note: "The upstream body only writes a Cursor .mdc rule, so the adapter replaces it with a Pi setup workflow." },
-  "sharpen": { tier: "native", capabilities: [], executables: [], note: "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": { tier: "native", capabilities: [], executables: [], note: "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." },
   "show-me-your-work": { tier: "adapted", capabilities: ["delegation"], executables: [], note: "The mandatory cross-model review of the trail requires spawning a different-family subagent. Verified end to end in Pi on Linux at pstack 0.15.36 with pi-subagents: it kept a decision log the repository ignores, and its reviewer on another model family read the parent's Pi session file and checked each row against it. Its own scripts ran unchanged." },
-  "statechart": { tier: "experimental", capabilities: [], executables: ["node", "sh", "dirname", "sed"], note: "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": { tier: "experimental", capabilities: [], executables: ["node", "sh", "dirname", "sed"], note: "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": { tier: "experimental", capabilities: ["delegation"], executables: [], note: "Cloud background workers and cloud_base_branch have no Pi mapping; only local fan-out approximates it." },
   "tdd": { tier: "native", capabilities: [], executables: [] },
-  "teach": { tier: "dependency-gated", capabilities: ["delegation"], executables: [], note: "It runs the how and why skills, both of which need subagents." },
+  "teach": { tier: "dependency-gated", capabilities: ["delegation"], executables: [], note: "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." },
   "technical-writing": { tier: "native", capabilities: [], executables: [] },
   "typescript-best-practices": { tier: "native", capabilities: [], executables: [] },
   "unslop": { tier: "native", capabilities: [], executables: [] },
-  "why": { tier: "dependency-gated", capabilities: ["delegation"], executables: ["git", "gh"], note: "Default posture spawns one investigator subagent per evidence category plus a synthesizer." },
+  "why": { tier: "dependency-gated", capabilities: [], executables: ["git", "gh"], note: "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." },
 };
 
 /** Adapter-owned skills with no upstream counterpart. Keyed by unprefixed generated name. */
@@ -113,7 +113,7 @@ export const MODEL_ROLES: readonly string[] = [
 
 /**
  * Upstream's panel lines, such as `arena runners`, hold a list of models with one seat per entry.
- * Upstream defaults each to two model families. A panel left unset here uses the roles in
+ * Upstream defaults each to several model families from two vendors. A panel left unset here uses the roles in
  * `PANEL_DEFAULT_ROLES`, so it spans two families only when those roles do.
  */
 export const PANEL_ROLES: readonly string[] = [

package/src/status.ts

@@ -216,7 +216,7 @@ function seatModels(seats: readonly PanelSeat[], ranked: boolean): Set<string> |
 }
 
 /**
- * Upstream's default panels span two model families. A panel whose seats all land on one model
+ * Upstream's default panels span several model families and two vendors. A panel whose seats all land on one model
  * lost that because of configuration, not because no other model exists, so say so where the
  * agent reads it. Families are left to the agent, which knows them better than a prefix list.
  */
@@ -232,11 +232,12 @@ export function panelWarning(panel: ResolvedPanel, config: AdapterConfig, contex
     ? `its configured entries all name ${named}`
     : `it is unset, and ${PANEL_DEFAULT_ROLES.map((role) => `\`${role}\``).join(" and ")} both resolve to ${named}`;
   const ranked = usable.some((seat) => seat.kind === "choice") ? " with the ranked picks, unless the delegating agent overrides the ranking," : ",";
-  return `Every seat of \`${panel.role}\` runs on ${named}${ranked} because ${cause}, ${pool ? poolEffect(panel, config, model, context) : "so the panel has one model and no second family"}. This comes from the adapter configuration, not from which models are available. Run \`/skill:${config.namespace}-setup\` to put this panel on two model families, as upstream's defaults do.`;
+  return `Every seat of \`${panel.role}\` runs on ${named}${ranked} because ${cause}, ${pool ? poolEffect(panel, config, model, context) : "so the panel has one model and no second family"}. This comes from the adapter configuration, not from which models are available. Run \`/skill:${config.namespace}-setup\` to put this panel on models from two vendors, as upstream's defaults do.`;
 }
 
 /**
- * Arena's judge is never from the session's family. When no pool entry qualifies, upstream tries
+ * Arena's judge is never from the session's vendor, which since pstack 0.15.42 counts Fable and the
+ * other Claude models as one. When no pool entry qualifies, upstream tries
  * its default pool, which here is `judgment`, then `general`, before it skips the judge.
  */
 function poolEffect(panel: ResolvedPanel, config: AdapterConfig, model: string | undefined, context: ResolutionContext): string {
@@ -245,7 +246,7 @@ function poolEffect(panel: ResolvedPanel, config: AdapterConfig, model: string |
   const lead =
     model === PARENT_MODEL
       ? "and an `inherit` entry never judges, so arena"
-      : `so a session on the family of \`${model}\` gets no judge from the pool, and arena`;
+      : `so a session on the vendor of \`${model}\` gets no judge from the pool, and arena`;
   const sameFallback = fallbackModels?.size === 1 && fallbackModels.has(model ?? PARENT_MODEL);
   return sameFallback
     ? `${lead} skips the judge`

package/src/vocabulary.ts

@@ -33,8 +33,9 @@ export const CURSOR_TERMS: readonly CursorTerm[] = [
   { key: "`resume`", pattern: /`resume`/ },
   { key: "`file_attachments`", pattern: /file_attachments/ },
   { key: "`claude-opus-5-5-xhigh`", pattern: /\bclaude-[a-z]+-\d/ },
-  { key: "`grok-4.7-xhigh-fast`", pattern: /\bgrok-\d/ },
+  { key: "`grok-*`", pattern: /\bgrok-\d/ },
   { key: "`gpt-*`", pattern: /\bgpt-\d/ },
+  { key: "`gemini-4-carbon-high`", pattern: /\bgemini-\d/ },
   { key: "`inherit-parent`", pattern: /inherit-parent/ },
   { key: "`~/.cursor/rules/pstack-models.mdc`", pattern: /pstack-models\.mdc/ },
   { key: "`.cursor/skills/`", pattern: /\.cursor\/skills/ },
@@ -53,6 +54,7 @@ export const CURSOR_TERMS: readonly CursorTerm[] = [
   { key: "Cursor `/loop`", pattern: /(^|[\s(`])\/loop\b/ },
   { key: "a skill under `plugins/cache/`", pattern: /plugins\/cache\// },
   { key: "a Custom Mode", pattern: /Custom Mode/ },
+  { key: "`# defaults: 2`", pattern: /# defaults: \d/ },
 ];
 
 /** One upstream Markdown file, named by its skill and its path inside the skill directory. */