pi-pstack-adapter 0.9.0 → 0.11.0

package/CHANGELOG.md

@@ -2,6 +2,25 @@
 
 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)
+
+
+### Features
+
+* **pools:** pick a pool's model in code from pstack:<role> delegations ([#33](https://github.com/elderfo/pi-pstack-adapter/issues/33)) ([ac270ae](https://github.com/elderfo/pi-pstack-adapter/commit/ac270ae946ec57378427e300cd2a8c9f67c100f6))
+
+
+### Bug Fixes
+
+* **host-mapping:** distinguish host PR event subscriptions from standalone Pi ([#29](https://github.com/elderfo/pi-pstack-adapter/issues/29)) ([8dacfa3](https://github.com/elderfo/pi-pstack-adapter/commit/8dacfa3ad578134b65eb848b5221cf70064fa18a))
+
 ## [0.9.0](https://github.com/elderfo/pi-pstack-adapter/compare/v0.8.0...v0.9.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,146 +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. Each delegation for that role picks one
-model from the list. 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 each pick one model from the
-`judgment` and `general` pools.
-
-### 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
 
@@ -268,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.9.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,14 +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 list of models, of which each delegation picks one.
+   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
@@ -89,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
@@ -101,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
@@ -114,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
 
@@ -127,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
@@ -138,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 |
 | --- | --- |