git:20261008.31a131d to git:20261016.1d260bc

+ pstack-t3 runs inside T3 Code. Every provider T3 drives (Claude, Codex, Grok, Cursor, Pi, OpenCode, Muse, ACP agents) gets the same `t3-code` MCP server. This file maps each pstack concept onto those tools, so a skill works the same whatever model runs it.

+ Tool names may carry a harness prefix, such as `mcp__t3-code__delegate_task` or `mcp__t3_code__delegate_task`. The semantics are the same. If a T3 tool this skill names is not in your tool list, find it with the host's tool search when the host has one, and call it by the name the search returns. When the host has no tool search, call the tool directly. Start with `orchestrator_capabilities`, and do not conclude the tools are missing until a search or a direct call has failed. ACP agents that cannot see the tools use the terminal bridge in [ACP fallback](#acp-fallback).

+ | worktree for a worker | A worktree from `delegate_task` with `isolation: "worktree"`, or a `t3_thread_launch` worktree binding for top-level threads. See [Isolation](#isolation). |

+ | status page, dashboard, report table, chart | A page published with `html_preview`, then `html_render`, inside a reply already due. See [Visual reports](#visual-reports). |

+ - After a `t3_thread_launch` or `delegate_task` call whose seat has `options`, read the applied options from the launch result's `modelSelection.options` or from `t3_thread_configuration` on the child's `childThreadId`, and never call again with the options removed. Each applied option is one object `{"id": <key>, "value": <value>}`. A missing option or a different value is a mismatch. On a mismatch, or when the call is refused for its `options`, stop that child. Report the tool's error text. Call `task_cancel` for a child task. Call `t3_thread_interrupt` and then `t3_thread_wait` for a thread. A Cursor harness sent `options` as a string, T3 refused the call, and the child then dropped the options.

+ - OpenCode moves a long command to the background, tells the model to end its turn, and resumes the thread when the command finishes. T3 publishes the task's result when the first turn ends, and the later turn does not reopen the task. Paste this paragraph unchanged into the brief of every child seated on OpenCode.

+

+ > Nobody resumes you after your turn ends, so a command left running in the background is lost. Run every long command in the foreground with a long enough timeout, for example a bash timeout of 600000 ms. If your shell moves a command to the background anyway, keep checking its output, with `sleep 60` between checks, until it finishes. Do not end your turn until your report is written.

+

+ When an OpenCode child's task is terminal and the report file its brief named is missing, the task is not finished. Read its activity with `t3_thread_read`. While a later turn on its thread still runs, wait on it per step 5. Otherwise handle it per [Failure handling](#failure-handling).

+ 4. A child starts with only its brief. It sees none of this conversation. Put the goal, the exact paths or SHAs, how to verify, and the report shape in the brief. Point at files instead of pasting large context. Write tool steps as plain verbs ("read", "search the repo", "run"), because the child may be a different provider with different tool names. When the role entry `roles.py show` printed for the child's seat has `haikuBrief`, paste its paragraphs unchanged, in order, at the end of the brief, per [Claude Haiku 5.5](#claude-haiku-55). A code-writing child inside a poteto-mode playbook opens with the poteto-agent persona body. Below it, paste unchanged the lines `python3 <pstack-runtime>/scripts/roles.py mode --cwd "$PWD" --playbook <name> --attempt <kind> [--brief-mode <value> | --session-mode light]` prints, per [Modes](#modes). They start with the `Playbook: playbooks/<name>.md` line, such as `Playbook: playbooks/feature.md`, and carry the required `Mode:` line. Write no `Playbook:` line of your own, because a second one fails the check. The lines include `Attempt:`. Under `Mode: light` they also include any `Waived by mode:` line. Under `Mode: full` there is no `Waived by mode:` line, and the brief must not add one. Copy the printed `Mode:` value into `--brief-mode` on the `roles.py show` call that seats the delegate, and pass no other mode flag. Write that brief to a file and run `python3 <pstack-runtime>/scripts/roles.py check-brief <file>` before `delegate_task`. Exit 1 names what is missing. Fix the brief, run the check again, and pass the checked text unchanged. A seat that matches this thread's model, or an edit that looks small, is not a `skip:` reason for the code delegate.

+ - A completion arrives only when the child's run ends. A child stalled on an approval request, or a run that stays open after its final message, never ends, so no wake comes. On T3 Code 0.0.46-nightly.20261015.3145 or later, a child's question for the user does wake this thread, per [Pending requests](#pending-requests). That wake queues behind this thread's active turn. Check for the question per [Failure handling](#failure-handling) while this turn stays open. A question that blocks the child also ends a `mode: "wait"` call, per the bullet below. That question sends no wake while the call blocks. An approval request still sends no wake. A thread with no schedule of its own, such as a worker running a brief, does not end its turn while a child is open. This holds even though the `delegate_task` tool text says to end the turn. A coordinator's liveness check is not this thread's schedule. Call `t3_thread_wait` on the child's `childThreadId` with `timeoutMs: 300000`. When it returns a terminal status, call `task_status` to read and acknowledge the result, because `t3_thread_wait` does not acknowledge it. When it returns `timedOut: true`, read the child with `t3_thread_read`, `view: "activity"`, and `afterPosition`. A child with no new item for 10 minutes is stalled. A child with a question that blocks it is not stalled, per [Failure handling](#failure-handling). Handle a stalled child per [Failure handling](#failure-handling), then wait on the next open child.

+ - A child with a final assistant message that holds the result the brief asked for, no pending tool or child run, and no new activity for two minutes is stalled. A message that says more work follows does not hold the result. A last message that says the child waits on a background command does not hold the result either, so this two-minute rule does not apply to it. After you see that message while the child's run is still open, call `t3_thread_wait` on the child's `childThreadId` with `timeoutMs: 120000`. Then read its activity again and call `task_status`. Handle it per [Failure handling](#failure-handling) only when the wait timed out, `workState` is still `working`, that message is still the last item, and no tool or child run is pending. Otherwise the 10-minute rule above decides that child.

+ - A child's run can end while its task stays open. A Claude child that leaves a background shell job running is one case. Then `t3_thread_wait` on its `childThreadId` returns at once, because an idle thread returns immediately, while `task_status` still reports `working` or `waiting_for_children`. Do not repeat that call. Wait with `t3_thread_wait` and `timeoutMs: 120000` on another open child whose run is still going. With none, wait on this thread's own run. Read the `activeRunId` of the `parentThreadId` from `orchestrator_capabilities` with `t3_thread_read`, and pass them as `threadId` and `runId`. Without `runId`, the call picks this thread's latest run, which can be a queued run already cancelled, and returns at once. This thread's run stays open during the call, so it returns `timedOut: true` after 120 seconds. Never wait with a shell `sleep`, which some harnesses refuse. After each wait, read the child with `t3_thread_read`, `view: "activity"`, and `afterPosition`, then call `task_status`. Count 10 minutes from the child's last activity item. A new item restarts the count, and a `task_status` check does not. A child with no new item for 10 minutes is stalled, even when its last message holds the result, because the two-minute rule above needs an open run. Handle it per [Failure handling](#failure-handling). When its run starts again, go back to the waits above.

+ - If you need a result now, call `task_status` with the `taskId`. Reading a terminal result this way acknowledges it, so no completion notification follows. Process that result immediately, as if the notification had arrived. `workState: "result_available"` means done, and `summary` holds the result. `working` and `waiting_for_children` mean not done. `hasPendingChildRuns` does not change that. `hasPendingQuestion` does not change it either. On T3 Code 0.0.46-nightly.20261015.3145 or later it is `true` while a question blocks the child. See [Pending requests](#pending-requests). See [Failure handling](#failure-handling). Do not busy-poll. Do other work between checks.

+ - `mode: "wait"` blocks for at most `timeoutMs`, ten minutes by default. Use it only for short children whose result gates the very next step. `waitTimedOut: true` does not cancel the child. Keep the `taskId`. On T3 Code 0.0.46-nightly.20261015.3145 or later, a question that blocks the child also ends the wait, with `hasPendingQuestion: true` and `waitTimedOut: false`. The task is still open. Answer the question per [Pending requests](#pending-requests). The task's completion still wakes this thread.

+ Children inherit this thread's runtime mode and interaction mode. Omit `runtimeMode` so the child inherits. Never raise it above the parent's, and never lower it. A child in `approval-required` stops at its first command on an approval request that no tool can answer, so it never finishes. A read-only reviewer is a read-only brief: say "do not edit files, commit, or push" in the task. T3 has no read-only flag that keeps MCP access, so the brief carries the constraint. Muse supports only `approval-required` and `full-access`. Under any other parent mode T3 runs a Muse child or launched Muse thread as `approval-required`, so it stalls at its first command. Read `runtimeMode` from `orchestrator_capabilities` before you seat Muse. Under a mode Muse lacks, replace the Muse seat with `"inherit"` per [Fallback](#fallback) and say why.

+ - A child fails or returns nothing usable: proceed with N-1 and record the dropout. Respawn once with a fresh child for a required slice. Never resume a failed child to fix its own work. When the failure carries a provider error, follow the next bullet before that respawn. A failure that reads `Killed: out of memory.` is an out-of-memory kill that T3 reports. Lower the load before you respawn that child. Run fewer children at once, or run builds through the slot in [Local command capacity](#local-command-capacity). Report a second kill as a blocker.

+ - Check a usage limit only for a failed child that did not return the brief's result. Read the error text from `task_status` `summary`, or from the last activity item of `t3_thread_read`. Run this command with that text on stdin. Pass `--cwd`, `--parent`, the catalog file, and the mode flag the same way as `show`. Pass `--role`, `--provider`, `--model`, and `--options` from the failed seat. For a reviewer role, repeat `--author` for every model that wrote the diff, per [Gate review](#gate-review): each code delegate's model, and the worker's model when the worker wrote code. A `review backups` member needs the same `--author` flags when it runs with `--resume`. Repeat `--out` for each provider already tried. The command prints `relaunch`, `panel`, `park`, or `not-usage-limit`.

+ ```bash

+ python3 <pstack-runtime>/scripts/roles.py backup --cwd "$PWD" --catalog <file> --parent "<inheritedProviderInstanceId>/<inheritedModel>" --role "<name>" --provider "<providerInstanceId>" --model "<model>" [--options '<json>'] [--author "<providerInstanceId>/<model>" ...] [--out "<provider>" ...] [--resume] [--brief-mode <value> | --session-mode light] <<'TEXT'

+ <the error text>

+ TEXT

+ ```

+

+ On `relaunch`, start a fresh child on the printed seat. Give that child a new stable `clientRequestId` ending in `-backup`. Confirm the applied options per [Delegation](#delegation) step 3. On `not-usage-limit`, respawn per the bullet above. On `park`, launch nothing. A worker moves to `claude-opus-5-5` on `claudeAgent`. `how explorer`, `why investigators`, and `skill tests` move to `claude-sonnet-5-5` on `claudeAgent`. `verifiers`, `interrogate reviewers`, and `arena cross-judge pool` move to `grok-4.7` on `grok`, then `claude-opus-5-5` on `claudeAgent`, skipping every author's family. When every backup family is an author family, the command parks. Every family comparison in `roles.py` uses normalized model ids, per [Built-in defaults](#built-in-defaults). A panel seats each family once. For a `verifiers` seat with `review backups` set, the command prints `panel` instead. On `panel`, spawn one fresh read-only child per printed seat with the same gate brief and a stable `clientRequestId` ending in `-panel-<n>`. Confirm each seat's options per [Delegation](#delegation) step 3. Wait until every member is terminal, even after two pass. A member that hits its usage limit runs this command with `--role "review backups"`, which parks it, and it counts as no pass. A member resumed after a reset runs `--resume --role "review backups"` with every `--author`. Without `--author` the command exits 2. It parks a member whose family is an author's, and that member counts as no pass. A member that fails otherwise respawns once. Land only if no reviewer reproduces a blocker and at least two of the panel pass. With `review backups` unset, or fewer than two usable seats, the command prints `park`. Backup never selects Codex or Cursor. Codex stays the default reviewer. A limit on `claudeAgent` parks a worker. A Claude model on another provider, such as `cursor/claude-opus-5-5`, moves to `claudeAgent`. A panel relaunches the failed seat and says when a family repeats. `park` on a panel proceeds with N-1. The backup is one hop. A second limit passes both providers as `--out` and parks a worker. After the reset time the error named, run the command with `--resume`, the parked item's original seat, the same `--author` flags, and `--out` for each provider whose reset has not passed. `--resume` reads no error text. It prints the original seat when its provider is back, and otherwise the backup above, so a worker gets the `claudeAgent` backup. A reviewer seat still skips every author's family. Start a fresh child on that seat. A parked worker keeps its lease and its branch's work. Say the printed `report` line in your report.

+ - `hasPendingChildRuns` on `task_status` does not mean the child is still running. It reports later turns on the child's thread, even after the task ended, and it does not reopen the task, including a turn you start with `t3_thread_send`. Decide completion by `workState` alone. On T3 Code 0.0.46-nightly.20261008.2813 or later, a turn held in a stopped queue does not count, and startup recovery on that host repairs a task an older build left `working` behind a held queue.

+ - A stalled child (see [Delegation](#delegation) step 5): first call `t3_pending_request_list` with the child's `childThreadId` as `threadId`. On T3 Code 0.0.46-nightly.20261015.3145 or later, `task_status` also shows `hasPendingQuestion: true` while a question blocks the child. A child with a question that blocks it waits on an answer and is not stalled. Answer it per [Pending requests](#pending-requests), and count its 10 minutes again from the answer. Otherwise read its last items. When its last assistant message holds the result the brief asked for, use that message as the result and call `task_cancel` on the task. When its last item is an approval request that is still waiting, call `task_cancel` and respawn once with no `runtimeMode`. Otherwise call `task_cancel` and respawn once for a required slice.

+

+ A `t3_thread_send` to a child whose task has already published its result can start a separate task for that message. Read the send result for a `taskId`. When it carries one, retain it and collect that task per [Delegation](#delegation) step 5. Its `summary` holds the answer, and the original task's `summary` does not change. When the result carries no `taskId`, wait with `t3_thread_wait` on the `childThreadId` and read the answer with `t3_thread_read`.

+

+ Always pass `--parent` with the values from `orchestrator_capabilities`. The saved catalog records whichever thread ran setup, so it never names this thread. Without `--parent`, the verifier panel treats no seat as this thread's own, and `show` cannot settle an `inherit` seat on a thread that runs an excluded model. `show`, `validate`, and `write` reject a malformed `--parent`. See [Excluded seats](#excluded-seats).

+ | `review backups` | N | `roles.py backup`, when every paid reviewer backup is out |

+ Code roles (`feature, refactoring`, `bug-fix`, `perf-issue`, `hillclimb`, `swarm workers`, `reflect tooling`) use `grok-4.7` at xhigh. Judgment roles (`judgment and prose`, `hardest tasks`, `how explainer`, `why synthesizer`, `reflect judgment, divergent, synthesizer`) use `claude-opus-5-5` at xhigh. `arena runners`, `arena cross-judge pool`, `architect runners`, and `interrogate reviewers` use those two seats in that order. Every seat follows [Excluded seats](#excluded-seats), so a `grok-4.7` seat on a provider whose model declares `fastMode` comes back with `"fastMode": false`.

+ `skill tests` uses `claude-haiku-5-5` at high. `how explorer` and `why investigators` use `claude-haiku-5-5` at medium, per [Claude Haiku 5.5](#claude-haiku-55).

+ `verifiers` starts with `"inherit"` when this thread's provider can run children, then adds one seat per other runnable provider (`canRunChildTask: true`), using that provider's first pickable model and skipping a family already seated. A thread on an excluded model gets no `"inherit"` seat, and its own provider joins with its first pickable model instead. With only one runnable provider, `verifiers` is three `"inherit"` seats, or three copies of the one runnable provider's first pickable model when this thread cannot be inherited, and the report must say the models did not differ. The other panel roles do not use that three-seat rule.

+ A model family is the leading word of the model ID. `claude-opus-5-5` is `claude`, `gpt-6.1-sol` is `gpt`, and `grok-4.7` is `grok`. The normalizer in [Excluded seats](#excluded-seats) runs first, so `us.anthropic.claude-sonnet-5-5-v1:0` is `claude`. Diversity rules compare families, never providers, because one provider can serve another's models.

+ When the preferred model is missing, the seat stays and a numbered note names the role, the seat number, the wanted model, and the replacement. The replacement is the first pickable runnable model of that family, then this thread's model when its provider can run children and the model is pickable, then the first pickable runnable model in the catalog. No runnable provider is an error. The panel keeps every seat. When two seats land on the same model, the note says the panel lost a distinct model.

+ Without a catalog, a preferred role reports `"seats": "catalog-required"`. `skill tests` reports `"seats": "catalog-required"` like the other preferred roles. `verifiers` reports `"seats": "default-panel"`.

+ `review backups` has no built-in seats, so `show` reports `"seats": "unset"` until the user sets it. Once it is set, `show` needs a catalog and reports `"seats": "catalog-required"` without one. With a catalog it prints the seats `backup` keeps when no provider is out and no author is named, and a `dropped <provider>/<model>: <reason>` note for each other seat that [Excluded seats](#excluded-seats) does not skip first. When a seat is dropped, `validate` lists it and exits 1, and `write` refuses the config unless `--force` is passed. When the role keeps fewer than two seats, `validate` prints `review backups: has <n> usable seats and needs 2`, with `seat` in place of `seats` when `<n>` is 1, and exits 1. `write` refuses that config unless `--force` is passed. With a catalog, `show` adds the same clause, without the role name, as the role's last note.

+

+ ### Excluded seats

+

+ pstack never runs a fast Grok model or Claude Haiku 4.5 as a seat or a worker. A fast Grok seat is a grok-family model whose id carries a `fast` token, such as `grok-4.7-build-fast`, or a Grok seat with `fastMode` set to `true`. `grok-build` has no `fast` token. A Claude Haiku 4.5 seat has a model id such as `claude-haiku-4-5`, `claude-haiku-4-5-20251001`, `claude-haiku-4-5@20251001`, or `anthropic/claude-haiku-4.5`. One normalizer maps that id to its canonical form before the Haiku 4.5 exclusion and before the Haiku 5.5 identity check. It removes a provider path prefix such as `amazon-bedrock/` and folds case. It strips one leading Bedrock prefix, `anthropic.`, `us.anthropic.`, `eu.anthropic.`, `apac.anthropic.`, or `global.anthropic.`. It treats dots and underscores as hyphens. It strips a Vertex `@YYYYMMDD` suffix and a trailing `-YYYYMMDD` suffix. Haiku 4.5 then matches `claude-haiku-4-5` at a hyphen boundary. Haiku 5.5 matches the canonical id `claude-haiku-5-5`. A pickable model is one that is not excluded. Every automatic pick in this file takes a pickable model.

+

+ - No picker chooses an excluded id.

+ - Every seat on a Grok model that declares a boolean `fastMode` option comes back with `"fastMode": false`. No mode and no budget sets it to `true`. pstack never adds `fastMode` to a model of another family.

+ - An `inherit` seat on an excluded id becomes that provider's first pickable model, with the note `inherit replaced by <provider>/<model>`. When that provider cannot run children or has no pickable model, `show` refuses the role.

+ - An `inherit` seat on a Grok model that declares `fastMode` becomes an explicit seat on that model with `"fastMode": false`, and the info `inherit made explicit as <provider>/<model> so fastMode stays false`. When that provider cannot run children, `fastMode` cannot be pinned, so `show` refuses the role.

+ - `show` skips a configured excluded seat with the note `skipped configured seat <provider>/<model>`. When no configured seat is left, the role uses its built-in default. `validate` lists each one and exits 1. `write` refuses it with `refusing to write, even with --force`. With a catalog, a `review backups` role with no configured seat left reports `"seats": []`.

+ - `verifiers` gets no `inherit` seat for an excluded parent, with the note `skipped inherit of <provider>/<model>`, per [Built-in defaults](#built-in-defaults).

+ - Without a catalog, a role whose seats include `inherit`, and the `verifiers` default panel, report `"seats": "catalog-required"` when `--parent` names an excluded id. Call `orchestrator_capabilities` and rerun `show` with `--catalog`.

+

+ The config may carry `"budget"`: `default`, `small`, `medium`, `large`, or `unlimited`. It caps the reasoning option of every seat that has one (`effort`, `reasoningEffort`, `reasoning_effort`, or `reasoning`) at `medium`, `high`, `xhigh`, or the highest level at or below `max`, or the closest lower value the model offers. A seat that names its own reasoning level keeps it when it is at or below the budget level, and is lowered to the budget level otherwise. `default` leaves options alone. The built-in Opus and Grok seats name xhigh, so `default` leaves that level in place. The ladder stops at max. `unlimited` raises those two seats to the model's highest level at or below max. The default Opus seat moves from xhigh to max. Grok stays at xhigh, the top of its ladder. `unlimited` does not raise the Claude Haiku 5.5 seats, per [Claude Haiku 5.5](#claude-haiku-55). `unlimited` lowers a configured `ultra` seat to max when the model offers a level at or below max. `default` keeps a configured `ultra` seat. When every offered level is above the cap, the seat gets the lowest level. Verifiers use those same levels. `ultracode` and `ultrathink` are never chosen by a budget. Under any budget other than `default`, an `inherit` seat becomes an explicit target on this thread's provider and model with the budgeted option, because an omitted `target` would pass the parent's reasoning level through. `roles.py show` reports the budgeted seats.

+ A configured seat whose provider is not runnable, or whose model is not in the catalog, falls back on its own. This path is separate from the built-in order above. A configured excluded seat never takes this path. A `review backups` seat never takes it either. `show` drops that seat with a note. [Excluded seats](#excluded-seats) says how each command handles it.

+ 1. Use the same provider's first pickable model. When it has none, `show` refuses the seat.

+ 2. If the provider is not runnable, use `"inherit"`, settled per [Excluded seats](#excluded-seats).

+ ### Claude Haiku 5.5

+ `skill tests`, `how explorer`, and `why investigators` use Claude Haiku 5.5 by default. `skill tests` runs at high effort. `how explorer` and `why investigators` run at medium. Anthropic positions Haiku 5.5 for high-volume, latency-sensitive work such as classification, routing, extraction, and sub-agent tasks, and for reading-heavy workers that search, read, and extract with little hard reasoning. A worker that needs more judgment takes Sonnet, and hard work takes Opus. Effort defaults to medium, and high fits work where instruction following matters. `unlimited` does not raise these seats.

+ Anthropic documents two weak spots that these paragraphs answer. At low effort, Haiku 5.5 stops early in long agent prompts. At low or medium effort, it skips verification on coding work. `roles.py show` adds both paragraphs as `haikuBrief` to every role entry with a seat that runs Haiku 5.5, including `inherit` on a Haiku 5.5 thread. Paste them unchanged, in order, at the end of the child's brief, per [Delegation](#delegation) step 4.

+ Keep working until everything the user asked for is done, and only stop to ask when you can't go on without the user or before a risky step. When the work the user asked for is done and checked, stop and report. Don't add new features, docs, or refactors that weren't asked for. If you think one would help, mention it at the end instead of doing it.

+ When you change code that can be run, built, or type-checked, run a real check that exercises the change before reporting it done: the project's tests, type-checker, or build, or the changed command itself. A syntax-only check, or a check command that failed to start, does not count; if all that is missing is the project's declared dependencies, install them with its own package manager and lockfile (e.g. npm install, pip install -r requirements.txt), never via sudo or the system package manager, unless told not to. Only if no real check can run here, say which one you did not run and why instead of reporting the change as done.

+ A child launches seats when it passes a `target` to `delegate_task` or a `modelSelection` to `t3_thread_launch`. A skill-test child that launches seats resolves with `roles.py show --role "skill tests" --launches-seats`. Pass exactly one `--role "skill tests"`, a catalog, and `--parent`.

+ The pool first uses the providers named by explicit configured seats in single-seat roles, never cursor. If no such provider remains, it uses every runnable provider that serves a pickable model of a built-in default family, `claude` or `grok`, plus this thread's provider. It removes cursor from that pool too. Cursor's harness sends `target.options` as a JSON string, which T3 refuses. An empty pool refuses with `cannot launch seats`.

+

+ A configured `skill tests` seat on another provider uses the configured-seat resolution rules in [Fallback](#fallback). The pool does not limit that seat. A configured `skill tests` seat on cursor is ignored in favor of the built-in default. Ignoring cursor adds no note. A seat that resolves to cursor is refused with `cannot launch seats`, including `inherit` on a cursor thread.

+

+ Under light with budget `default`, `roles.py show` resolves every role except `verifiers` and `review backups` as budget `small`, which caps reasoning at `medium`. Those two resolve on the configured budget, as in full mode, so a gate review seated from `verifiers` keeps its full-mode level. `roles.py` takes a role and no purpose, so every other child seated from `verifiers` keeps its level too. `roles.py backup` follows the same rule for the seat it relaunches or resumes and for the `review backups` panel it prints. An explicit budget wins. No mode sets `fastMode` to `true`. A Grok seat that declares it gets `false`, per [Excluded seats](#excluded-seats). Pass the live catalog and `--parent` on every light `show` call, per [Roles](#roles), so an `inherit` seat of a capped role gets the cap.

+ Two sources can show both today.

+ 1. A coordinator's pass record, when this work is a brigade item and you know its restaurant directory and item id. Run `python3 <skills>/brigade/scripts/brigade.py --at <restaurant dir> pass check <item> --sha <head> --json`, where `<skills>` is the directory that holds `<pstack-runtime>`. Reuse the pass only when the command exits 0 and prints `"crossFamily": true`. Never read `pass.tsv` yourself. Never take the output of `pass check` without `--json` as proof, because it names the verifier and not the author.

+ 2. A verdict this run launched at that exact SHA. A Shipping or Autopilot root's own verdict at that SHA counts.

+ - A Shipping or Autopilot verdict from another run does not qualify. A coordinator's pass qualifies only through source 1.

+ Read [host.md](host.md) when a thread settles, snoozes, or runs on a host older than the versions this file names, or before you install or locate skills.

+

+ Before you end a worktree turn that can settle, read [Settle on turn end](host.md#settle-on-turn-end).

+

+ Before you delegate a child that needs a chosen branch or a different base, read [Older hosts](host.md#older-hosts).

+

+ - On T3 Code 0.0.46-nightly.20261014.3093 or later, a writing child that may overlap with another writer uses `delegate_task` with `isolation: "worktree"`. T3 branches from the parent's current local commit and runs project setup. Blocking setup finishes before the child starts. An async setup action can keep running. Uncommitted edits are not copied. The brief tells the child to report its branch and head SHA. Read the child's binding with `t3_thread_read` and check its diff before integrating.

+ - T3 storage cleanup can remove that worktree after the thread ends. See [Local state](#local-state).

+ ## Local command capacity

+

+ Children, launched threads, and this thread run on this machine, so their builds and tests share its cores. Run each local build, test suite, and verifier rerun through `python3 <skills>/landing/scripts/land.py slot -- <command>`, where `<skills>` is the directory that holds `<pstack-runtime>`. Run each benchmark or timing measurement through `python3 <skills>/landing/scripts/land.py slot --exclusive -- <command>`. It must be the outermost slot. The slot count, its config file, and the landing queue's reserved slot are in the landing skill's [Capacity](../landing/SKILL.md#capacity) section. A brief links that section and does not copy them.

+

+ - A slot wraps one command and ends when that command exits. Never hold a slot across a model turn, a `t3_thread_wait`, a `task_status` check, a `watch_pull_request` wait, or any other wait on children. Start dev servers with the preview tools, not in a slot.

+ - Slots limit heavy commands, not agents. Do not cap owners, children, or launched threads at the slot count.

+

+ Before you call `t3_thread_configure`, `t3_queue_promote_to_steer`, `t3_thread_fork`, `t3_thread_merge_back`, or `run_scheduled_task_now`, or pause a finite program's schedule, read its section in [threads.md](threads.md).

+

+ "modelSelection": {"instanceId": "claudeAgent", "model": "claude-opus-5-5", "options": {"effort": "xhigh"}}

+ - `modelSelection` is the seat with `providerInstanceId` renamed to `instanceId`, `model` copied, and `options` copied unchanged as the same object, including a boolean such as `{"fastMode": false}`. Omit `modelSelection` for an `inherit` seat.

+ - Confirm a launched thread per [Delegation](#delegation) step 3.

+ - `t3_thread_launch` has no retry key. Retain the `threadId`. After an error or lost response, check `t3_thread_list` before retrying. Report it to the user as a thread link per [History](#history).

+ - Autopilot-full, Autopilot-stack, and Orchestrate owners send their report lines to the root or coordinator with `t3_thread_send` and `mode: "auto"`. `auto` starts an idle recipient, steers a fully active turn, and queues behind a turn that cannot accept steering yet. It does not merge reports into one turn. The recipient handles every report, steered or queued, and runs the playbook's head-specific checks on the head each report names. Arrival order never makes a head current. Brigade's event lines to an executive admin stay on `mode: "queue"`, as [Reporting to an executive admin](../brigade/SKILL.md#reporting-to-an-executive-admin) states.

+ - A correction you queued earlier to an active owner or coordinator can sit behind a long turn. Read [Promote a queued correction](threads.md#promote-a-queued-correction) before you deliver it. Never promote brigade's event lines to an executive admin, a digest message, or a message that needs a turn of its own.

+ - Change an existing launched thread's model with `t3_thread_configure` only when a playbook step already calls for that owner to run on another model, such as Orchestrate's tool-error retry. Never call it because an owner keeps failing a gate. Read [Configure an owner](threads.md#configure-an-owner) before the call.

+ ### Forks

+

+ Before you call `t3_thread_configure`, `t3_queue_promote_to_steer`, `t3_thread_fork`, `t3_thread_merge_back`, or `run_scheduled_task_now`, or pause a finite program's schedule, read its section in [threads.md](threads.md).

+

+ `t3_thread_fork` starts a new top-level thread from another thread's context. `t3_thread_merge_back` moves context between related threads in one project. Use them only for the cases [Forks](threads.md#forks) allows. A fork never stands in for a child task, an Orchestrate sub-coordinator, or a fresh review round, and `task_status` does not apply to it. Read the fork with `t3_thread_read` for its `worktreePath`, `branch`, and `activeRunId` before you send anything. Treat a checkout it shares with another thread as read-only. Writers stay isolated per [Isolation](#isolation).

+

+ Before you call `t3_thread_configure`, `t3_queue_promote_to_steer`, `t3_thread_fork`, `t3_thread_merge_back`, or `run_scheduled_task_now`, or pause a finite program's schedule, read its section in [threads.md](threads.md).

+

+ - Never pause a schedule that renews a lease, drains queued work, consumes standing intake, or notices a merge. A required merge heartbeat and a fallback heartbeat beside `watch_pull_request` keep running. This rule never pauses a brigade schedule. Brigade holds an item on a decision and keeps its liveness schedule renewing the lease. Read [Pause a finite program](threads.md#pause-a-finite-program) before you pause a schedule.

+ - To run an enabled `interval` schedule's work now, read [Run a schedule now](threads.md#run-a-schedule-now). Never run a paused schedule before the answer permits work.

+ Resume notes from Pause safely go to `.pstack/resume/<slug>.md` in the repository, untracked (add `.pstack/` to `.git/info/exclude`), and are also posted as the thread's final message. Rely on the final message, because storage cleanup can delete the file with its worktree.

+ A T3 restart ends the old provider processes. On T3 Code 0.0.46-nightly.20261012.3010 or later, Continue threads after restarts defaults to on and can start a new turn for an eligible interrupted thread. Read `task_status` before replacing a child. A task in `working` or `waiting_for_children` can still be recovering or running, so read its child thread's recent runs and activity before launching the same slice again. A task in `result_available` finished, so read its `summary` before you respawn its slice. Durable queued messages keep their order but are held after recovery until resumed. On T3 Code 0.0.46-nightly.20261013.3080 or later, recovery cancels queued provider notifications whose buffered output was lost with the process. Pushed branches, launched threads, thread history, pull request watches, and schedules persist. Automatic restart continuation needs saved provider resume state and stops after three consecutive continuations in one chain. It does not resume an archived thread, a manually settled thread, a still-snoozed thread, a provider disabled for the project, or a turn waiting on a non-message-capable approval, question, or secret. An ended provider turn normally does not resume. On T3 Code 0.0.46-nightly.20261014.3105 or later, a completed turn can also continue when its live provider session lost an awaited monitor, provider-native subagent, or background task. A shell alone does not wake it. App-owned children recover through their own threads. On that build, `t3_thread_wait` follows the restart continuation chain and can return the continuation's run ID. Keep the original task ID and collect its result with `task_status`. A settings opt-out can disable automatic restart continuation. Read `t3_thread_read`, `task_status`, `list_thread_pull_requests`, and `list_scheduled_tasks` before recreating work after a restart. A T3-managed worktree persists unless the project enables storage cleanup. Storage cleanup removes a worktree that its rules select. It acts after the thread completes, is interrupted, is cancelled, or is rolled back. It also acts after the thread's PR merges into the default branch by squash or rebase at the worktree's head SHA. On T3 Code 0.0.46-nightly.20261015.3145 or later, a project can also remove a worktree a set number of days after its thread settles. Zero days allows removal at the first sweep past the grace below. Other cleanup protections still apply. No rule removes the worktree of a settled thread that still exists within a minute of that thread's last update, so the settle action runs first. The rule is off by default. Depending on the user's cleanup settings, removal takes ignored files with the worktree, such as `.env`, build output, and `.pstack/`. It can take untracked files too. Commit and push the work itself, the tracked source changes, so it outlives the worktree. Never commit an ignored or private file to keep it. Keep private files in the state directory above. The branch and thread survive, and a new turn on that thread recreates the checkout. Resume through the thread's binding with `t3_thread_read`, and check that `worktreePath` exists before you use a saved path. Reattach through `t3_thread_list` and `list_scheduled_tasks`.

+ Before you verify a change in a UI, on a device, or in a CLI, read [verification.md](verification.md) and use the surface it names.

+ A project `verify-*` skill beats all of these when one exists.

+

+ ## Visual reports

+

+ A page is for a reply that is already due. When the playbook that runs this thread sends a reply, and a table of units, a timeline, a frontier, or a chart would carry it better than prose, publish that part as a page. A short status with no table stays text.

+

+ 1. Write one self-contained HTML document. Every number and link on it comes from the store or the tables the text report would read.

+ 2. Call `html_preview` with it. Fix every console error and every clipped or overlapping element. When the page holds a wide table, preview it again with `width: 390`.

+ 3. Call `html_render` with the document, a `title`, and the preview's `contentHeight` as `height`, raised to 80 or capped at 2000. A capped frame scrolls the rest.

+ 4. Write the reply after the render. It does not announce the page and adds only what the page does not show. Every decision that waits on the user, every PR link, and the store and report paths stay in the reply text, so a capped frame never hides them.

+

+ Leave `html`, `body`, and the outermost element with no background color, and style the page with the theme variables `html_render` describes. When either tool is missing or `html_render` fails, send the same facts as text.

+

+ A rendered page is a reply the user reads, even with no reply text. Render none on a wake that sends no reply. Brigade at `digest` renders no page except the one [Agent activity](../brigade/SKILL.md#agent-activity) names, so its replies stay in the plain form [Digest messages](../brigade/SKILL.md#digest-messages) sets. At every level, step 9 of brigade's [Run a service](../brigade/SKILL.md#run-a-service) decides which wakes reply before any page is drawn.

+

+ Read [host.md](host.md) when a thread settles, snoozes, or runs on a host older than the versions this file names, or before you install or locate skills.

+

+ Before you use a saved transcript file from another environment, read [History notes](host.md#history-notes).

+

+ Before you read Claude conversation history, read [History notes](host.md#history-notes).

+

+ - Read it: `t3_thread_read` with `view: "messages"` for the conversation, `view: "activity"` for tool activity. Page with `afterPosition`. Read the worker's explicit report and the result its brief required before treating narration as a decision or completion. Use the activity view to check the turn's order, and collect a child task with `task_status` per Delegation step 5.

+ - Page long stored items with `itemId` and `textOffset`. On T3 Code 0.0.46-nightly.20261014.3105 or later, new file-change items keep only a bounded prefix of their edit text. Paging cannot recover the discarded suffix. Read `git diff <base>...<head>` in the worker's checkout for the whole change.

+ - Link a thread in a user-facing report as a Markdown link whose text is the thread's title and whose target is `t3-thread://v1/<threadId>`. Copy the `threadId` exactly as a tool returned it. Do not URL-encode it, decode its `%` escapes, or add an environment ID. T3 Code shows the thread's current title. List, read, and launch results carry no `link` field, so build the link from `threadId` or `childThreadId`.

+ An owner that may already be settled reads [Settle on turn end](host.md#settle-on-turn-end) before calling `watch_pull_request`.

+

+ Read [host.md](host.md) when a thread settles, snoozes, or runs on a host older than the versions this file names, or before you install or locate skills. Never settle an owner whose PR watch or `schedule_task` loop is still needed, because settling ends the watch.

+ A child or launched thread can stall on a question for the user. `t3_pending_request_list` shows those and `t3_pending_request_read` shows one. Pass the child's `childThreadId`, or the launched thread's `threadId`, as `threadId` on `t3_pending_request_list`, `t3_pending_request_read`, and `t3_pending_request_respond`. Without `threadId` each tool acts on this thread. Answer with `t3_pending_request_respond` only from the brief and the facts and decisions the user already gave. Otherwise ask the user with the host's question tool, then answer. A playbook that parks decisions parks the question instead.

+ On T3 Code 0.0.46-nightly.20261015.3145 or later, a delegated child's question wakes this thread. The wake is a message that names the child's thread and the request ID. A question that blocks the child also ends a `mode: "wait"` call, per [Delegation](#delegation) step 5. A Codex child can ask without stopping, and its wake says it is still working. When the question no longer shows in `t3_pending_request_list`, someone answered or dismissed it, so send nothing. A task in `result_available` that completed or failed keeps its child's open questions. Do not answer one. Answering such a question sends a message to the child's thread and does not reopen the task. Give the answer to a fresh child per [Fresh children by default](#fresh-children-by-default).

+

+ Read [host.md](host.md) when a thread settles, snoozes, or runs on a host older than the versions this file names, or before you install or locate skills.

+ Before you write a child brief that needs a specific MCP server, read [Skill locations](host.md#skill-locations).