feat(setup-pstack): pin the trail reviewer and show its step

PORTING.md

@@ -72,7 +72,7 @@ Upstream is the source of truth for the workflows themselves. This file records
 - Babysit CI classification is a port edit. [Babysit step 7](skills/poteto-mode/playbooks/babysit.md) owns the classification and retry rules. Preserve that step on upstream sync.
 - PR body finalization is a port edit (2026-10, #177). [Opening a PR](skills/poteto-mode/playbooks/opening-a-pr.md) owns PR body finalization, including non-owner reports. [Babysit](skills/poteto-mode/playbooks/babysit.md) applies them after a repair push. Upstream has neither the provisional-body rule nor the Babysit body re-check. Keep both on sync.
 - Repository selection is a port addition (2026-10, #169). [Opening a PR, Forge](skills/poteto-mode/playbooks/opening-a-pr.md) owns the origin-resolution rule for both github.com and Enterprise. Preserve the full host, owner, and repository in every project-bound PR and issue call, and explicit `--hostname <host>` in API and token calls. Keep it and the watcher's `currentPr` repository, branch, and detached-HEAD handling on sync. Port-owned examples carry explicit `-R`: Opening a PR's attachment read, Babysit steps 6 and 8, Orchestrate, Code review, and deslop. Babysit, Code review, and deslop resolve the repository without Opening a PR's Forge rule, so each of their `-R` sites says `<host>/<owner>/<repo>` comes from origin's fetch URL. Upstream-owned `gh pr` commands that read or change PR state also carry it (port edit): Shipping steps 4 and 8, why step 2, and why's code-archaeology reference. In this fork, Shipping's bare `gh pr view 205` read cursor/plugins#205 as merged while this repository's #205 was open, and why never loads Opening a PR. Keep `-R`, with `<host>/<owner>/<repo>` from origin's fetch URL, at those sites on sync. Other upstream-owned examples in Opening a PR, Autopilot-stack, and Multi-phase plan remain unchanged.
-- Other roles beyond upstream's roster: `trail reviewer` (the show-me-your-work reviewer and, since 2026-10, every independent verdict and review; upstream says "a different model family", which has no answer inside one vendor) and `default` (the entry for a spawn whose skill names no role, shipped as `inherit-parent`). Step 1 of the harness skill's Spawn a role sends every role-less spawn through `default`; on sync, keep these roles and the show-me-your-work wording that resolves through `trail reviewer`, and keep the resolver's `--work-model` step as defined in [models config rule 7](skills/setup-pstack/references/models-config.md#resolution).
+- Other roles beyond upstream's roster: `trail reviewer` (the show-me-your-work reviewer and, since 2026-10, every independent verdict and review; upstream says "a different model family", which has no answer inside one vendor) and `default` (the entry for a spawn whose skill names no role, shipped as `inherit-parent`). Step 1 of the harness skill's Spawn a role sends every role-less spawn through `default`; on sync, keep these roles and the show-me-your-work wording that resolves through `trail reviewer`, and keep the resolver's `--work-model` step and its `trail reviewer step: off` pin as defined in [models config rule 7](skills/setup-pstack/references/models-config.md#resolution).
 - `routine` is a third role beyond upstream's roster (port addition, 2026-10). A read-only scan, parse, or watch subagent that returns a reduced finding runs on it. The sites are poteto-mode's subagent defaults, `automate-me` slice mining, the Worktree cleanup, Trace forensics, Runtime forensics, Session pickup, and Autonomous run playbooks, and the Guard the Context Window principle. Upstream names no role for these spawns, so before this change the port sent them through `default`, which inherits the lead's model. The shipped model and effort live in [the models config defaults](skills/setup-pstack/examples/pstack-models.md). Explorers in `recall`, `how`, and the multi-phase plan stay on `how explorer`. On sync, keep the role in `check-models-config.py`, `role-contract.json`, and the shipped examples file, and keep each site's `routine` sentence.
 - **Authoring or modifying a skill** sends skill steps through the STE layer of **technical-writing** (port addition, 2026-10). Skill steps are procedures an agent executes. ASD-STE100 was written for procedures. Upstream's authoring guidance names no style standard. On sync, keep the sentence.
 - **Opening a PR** says how to post PR evidence (port addition, 2026-09). Follow any attachment rule the repo's `AGENTS.md` or PR template sets, upload with `gh … --attach` (gh 2.99.0 or later), never through undocumented endpoints, and confirm each posted URL returns `200` with `gh auth token`. Report an upload blocker only when no gh at 2.99.0 or later is available or a retry fails. Upstream says only to attach videos or screenshots. Keep both the repo-rule clause and the **Attachments** paragraph on sync.

evals/promises/ledger.json

@@ -3344,7 +3344,7 @@
   },
   "show-me-your-work-spawns-trail-reviewer": {
    "check": "live",
-   "claim": "Before summarizing a run, show-me-your-work spawns a reviewer on the configured trail reviewer model, or, if that matches the working model, on another allowed model in the working model's family, or as a labeled same-model review when none is allowed.",
+   "claim": "Before summarizing a run, show-me-your-work spawns a reviewer on the configured trail reviewer model, or, if that matches the working model, on another allowed model in the working model's family, or as a labeled same-model review when none is allowed or the user sets `trail reviewer step: off`.",
    "harness_sensitive": true,
    "live_case": "tally fixture; prompt the overnight contract from 07-overnight.md with `/loop until done`; pass when figure-it-out designs phases before code, decisions.tsv fills one row per iteration, no permission question is asked, and `/show-me-your-work catch me up` spawns a trail reviewer and ends with an Attention section.",
    "owners": [
@@ -3458,15 +3458,15 @@
   },
   "swarm-judging-worker-uses-trail-reviewer": {
    "check": "static",
-   "claim": "A swarm worker that reads and judges a diff spawns on the `trail reviewer` role, on another allowed model in the author's model family when the configured one matches the author's model, or as a labeled same-model review when none is allowed.",
+   "claim": "A swarm worker that reads and judges a diff spawns on the `trail reviewer` role, on another allowed model in the author's model family when the configured one matches the author's model, or as a labeled same-model review when none is allowed or the user sets `trail reviewer step: off`.",
    "evidence": [
     {
      "file": "skills/swarm/SKILL.md",
      "quote": "A worker that reads code, a diff, or another artifact and judges it uses the `trail reviewer` role, default `opus`."
     },
     {
      "file": "skills/swarm/SKILL.md",
-     "quote": "Before you spawn it, find the model that wrote the work, because **Spawn a role** passes it as `--work-model` and the resolver picks a different model in the work model's family for this role when the config allows one."
+     "quote": "Before you spawn it, find the model that wrote the work, because **Spawn a role** passes it as `--work-model` and the resolver picks a different model in the work model's family for this role when the config allows one and `trail reviewer step` is not `off`."
     },
     {
      "file": "skills/pstack-harness/references/roles.md",

evals/promises/oracles.py

@@ -2374,7 +2374,7 @@ def trail_reviewer(view):
         return failed("no trail reviewer spawned before the summary", *evidence)
     model = reviewers[0].get("model")
     if model and view.model and model.split("-")[0] in str(view.model):
-        evidence.append("reviewer shares the lead's model family; the resolver moves it off the working model when they match and the config allows another model in that family")
+        evidence.append("reviewer shares the lead's model family; the resolver moves it off the working model when they match, the config allows another model in that family, and the user has not set trail reviewer step: off")
     return passed(*evidence)
 
 

skills/poteto-mode/playbooks/orchestrate.md

@@ -16,7 +16,7 @@ Three rules carry the rest.
 
 - **Coordinator (this chat).** Local. Frames, authors briefs, drains the inbox, owns the human report, makes judgment calls. It never authors or edits code. Conflicted merges, chain rebases, and code changes are always tasks. In an ungated repository, mechanically landing a verified unit (fast-forward or clean cherry-pick of a worker's commit, then push) is bookkeeping the coordinator may do itself on repos where local git is cheap. Queueing finished work behind an idle stacker is how a deadline harvests nothing. The loop is agentic end to end. Use the **pstack-harness** skill to spawn, resume, and drain agents through the delegation mechanisms it maps. State reads and writes go through `../scripts/orch/orch.ts` at drain points, one command in and one line out. The CLI never spawns, waits, or wakes anything.
 - **Sub-coordinator.** One per track, and only when the program exceeds what one coordinator's drains can manage. A track the coordinator can drain itself needs no middle layer. Each nested layer re-pays a full orientation preamble, and a blocking sub-coordinator hides its children while the parent idles. Owns its track's units and boards, authors its workers' briefs, spawns its own workers and verifiers where this CLI lets a subagent spawn (the **pstack-harness** skill names the CLIs that do not). Where it cannot, the coordinator drains every track itself. Rolls up aggregates at wave boundaries. Never forwards raw child reports. Cap in-flight children at what one drain can process, roughly ten, as a rolling window. Never as blocking batches, which cost the slowest child of every batch.
-- **Worker / verifier.** Always a background agent in its own isolated worktree. Agents run through the existing native or CLI delegation route. A missing session observation leaves liveness uncertain. A worker's working directory is its worktree, so its brief gives the store's absolute path and points at repo paths. Prefer fewer, broader workers. One writer per worktree or branch (principle-separate-before-serializing-shared-state). Use the **pstack-harness** skill for the spawn. Its **Spawn a role** section resolves the role and builds this CLI's spawn call. Run a unit's verifier on the `trail reviewer` role, resolved with the worker's model as `--work-model`, so the verifier runs on a different model in the worker's family when the config allows one.
+- **Worker / verifier.** Always a background agent in its own isolated worktree. Agents run through the existing native or CLI delegation route. A missing session observation leaves liveness uncertain. A worker's working directory is its worktree, so its brief gives the store's absolute path and points at repo paths. Prefer fewer, broader workers. One writer per worktree or branch (principle-separate-before-serializing-shared-state). Use the **pstack-harness** skill for the spawn. Its **Spawn a role** section resolves the role and builds this CLI's spawn call. Run a unit's verifier on the `trail reviewer` role, resolved with the worker's model as `--work-model`, so the verifier runs on a different model in the worker's family when the config allows one and `trail reviewer step` is not `off`.
 
 Depth stays at coordinator, track, worker. Author the track decomposition per project (build, landing, and verification are common cuts, not a required shape). Hard-coded swarm trees were tried and parked as too rigid.
 
@@ -89,7 +89,7 @@ A dependency is a context relay, not just ordering. Undeclared upstream context
 
 #### Verification
 
-Scale verification to the unit. When VERIFY is a single cheap command, the worker runs it and reports the output, and the coordinator spot-checks receipts. A dedicated verifier agent (on the `trail reviewer` role, a different model in the worker's family when the config allows one) is for units whose verification is expensive, judgment-laden, or high-blast-radius. A verifier agent whose entire product would be rerunning one command is ceremony, not verification.
+Scale verification to the unit. When VERIFY is a single cheap command, the worker runs it and reports the output, and the coordinator spot-checks receipts. A dedicated verifier agent (on the `trail reviewer` role, a different model in the worker's family when the config allows one and `trail reviewer step` is not `off`) is for units whose verification is expensive, judgment-laden, or high-blast-radius. A verifier agent whose entire product would be rerunning one command is ceremony, not verification.
 
 Write verdicts during reconciliation with `orch inbox ack`. A verifier that publishes directly uses `orch ledger record ... --attempt <id>` for tracked work, or `--verifier <name>` for untracked work. Check the current PR and head SHA with `orch ledger check`. `ledger.tsv`, one row per verdict, keyed by PR number plus head SHA: `live-ui-verified | unit-test-verified | type-check-only | verifier-blocked | verifier-failed`. CI green is an input to a verdict, not a verdict. Behavioral work needs better than `type-check-only`. `verifier-blocked` is not a pass. Respawn when the environment heals. `verifier-failed` gets a fix unit, not a re-verify. A worker may self-report. The store rejects a worker replacement of a verifier on the same key. A current verifier can revise a pass to failure or failure to pass. Verdict labels have no authority ranking. A new head SHA voids the row, so re-verify after restack. The ledger answers "was this verified", not memory and not the transcript.
 

skills/pstack-harness/references/roles.md

@@ -30,7 +30,7 @@ Every pstack spawn runs a role from the models config, such as `feature` or `how
    python3 "${PSTACK_SKILLS_ROOT:?}/setup-pstack/scripts/check-models-config.py" --resolve --harness <claude-code|codex|grok|hermes> [--work-model <model>@<effort>] [<role>...]
    ```
 
-   Failure signal: nonzero exit. It prints one JSON line per arm with `model`, `effort`, and `source`, and a `notes` list when the resolver has a warning. Relay each note to the user in the reply. Pass the roles the skill names, or none to print every role. Run it from the project root or pass `--project <root>`. Do not read the config files to pick values. The rules, and the grammar for editing the files, live in setup-pstack's [models config reference](../../setup-pstack/references/models-config.md). When you resolve `trail reviewer`, pass `--work-model <model>@<effort>` with the model and effort that did the work, and use the printed arm. When the work's role resolved to `inherit-parent`, pass the session model. Pass the model the work ran on, as the role's resolved value or the CLI's own model ID. A full Claude ID such as `claude-opus-5-5` maps to its alias on a CLI that takes aliases, and stays a literal slug on Hermes. On Claude Code, a work model that is not a Claude alias or ID exits 2. On another CLI, a work model that CLI cannot use adds a note and applies no step. When the exit 2 names `--work-model`, correct a Claude value, such as dropping a `[1m]` suffix from an alias, and rerun. If the work ran on another vendor's model, rerun without the flag: every Claude Code arm is a Claude model, so the printed arm is cross-model. Otherwise rerun without the flag and disclose the execution identity per step 5. The resolver prefers a different model in the work model's family that the user's config allows, a higher tier first, and adjusts the effort. A `"step": "same-model"` field means the config allows no other model in the work model's family, so report that resolution and disclose the execution identity per step 5. Every model you pass comes from this output or an explicit request in the task. Never improvise one, and say which role each model came from. If the resolver exits nonzero or cannot run, still spawn the role. Omit the model and effort so the child inherits the session's. For `trail reviewer`, disclose the execution identity per step 5. For a panel role, keep the arm count that the panel's skill names as its default, and brief each arm the way that skill says. Report the resolver error and the values the child ran on. Never drop a spawn because the resolver failed.
+   Failure signal: nonzero exit. It prints one JSON line per arm with `model`, `effort`, and `source`, and a `notes` list when the resolver has a warning. Relay each note to the user in the reply. Pass the roles the skill names, or none to print every role. Run it from the project root or pass `--project <root>`. Do not read the config files to pick values. The rules, and the grammar for editing the files, live in setup-pstack's [models config reference](../../setup-pstack/references/models-config.md). When you resolve `trail reviewer`, pass `--work-model <model>@<effort>` with the model and effort that did the work, and use the printed arm. When the work's role resolved to `inherit-parent`, pass the session model. Pass the model the work ran on, as the role's resolved value or the CLI's own model ID. A full Claude ID such as `claude-opus-5-5` maps to its alias on a CLI that takes aliases, and stays a literal slug on Hermes. On Claude Code, a work model that is not a Claude alias or ID exits 2. On another CLI, a work model that CLI cannot use adds a note and applies no step. When the exit 2 names `--work-model`, correct a Claude value, such as dropping a `[1m]` suffix from an alias, and rerun. If the work ran on another vendor's model, rerun without the flag: every Claude Code arm is a Claude model, so the printed arm is cross-model. Otherwise rerun without the flag and disclose the execution identity per step 5. With the reviewer unpinned, the resolver prefers a different model in the work model's family that the user's config allows, a higher tier first, and adjusts the effort. A `"step": "same-model"` field means the config allows no other model in the work model's family, or the user pinned the reviewer with `trail reviewer step: off`. Report that resolution and disclose the execution identity per step 5. Every model you pass comes from this output or an explicit request in the task. Never improvise one, and say which role each model came from. If the resolver exits nonzero or cannot run, still spawn the role. Omit the model and effort so the child inherits the session's. For `trail reviewer`, disclose the execution identity per step 5. For a panel role, keep the arm count that the panel's skill names as its default, and brief each arm the way that skill says. Report the resolver error and the values the child ran on. Never drop a spawn because the resolver failed.
 3. **Build the spawn call for this CLI.** Use the current runtime adapter selected in [pstack-harness](../SKILL.md#runtime-adapters). `inherit-parent` in a field means omit that field.
 4. **Brief the persona.** A persona that runs as a briefing gets its complete text from the [persona contract](named-roles.md). Never summarize it.
 5. **Report execution without dropping an arm.** Apply this step to every spawn, including a `trail reviewer` that normally resolves to `inherit-parent` without a fallback or `step` marker. If the spawn rejects a model, or a spawned arm fails on model availability such as exhausted usage credits, omit the model, let the arm inherit the session model, and report the substitution. Label the verdict and reply `same-model` when the observed reviewer and work models match. When either identity is unknown, say the review may be same-model. For explicitly requested models, use the **arena** skill's [required-arm rule](../../arena/SKILL.md#required-arms). If no field or agent can carry the effort, the effort alone becomes `inherit-parent`. Keep the model and the arm. Say in the reply which role's effort was inherited and why, such as "`how explainer` ran at the session effort because `pstack-effort-xhigh` is not loaded. Run `/setup-pstack` to register it." When a persona ran as a briefing in an effort agent's prompt instead of under its native name, say that too. Delegates return resolver notes and actual or inherited model and effort observations to the parent, including substitutions, limitations, and unknown values. The parent relays them in its reply.