fix(bstack): isolate untrusted PR review workers

.github/workflows/ci.yml

@@ -0,0 +1,25 @@
+name: BStack checks
+
+on:
+  pull_request:
+  push:
+    branches: [main]
+
+permissions:
+  contents: read
+
+jobs:
+  verify:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          persist-credentials: false
+      - uses: actions/setup-python@v5
+        with:
+          python-version: '3.11'
+      - run: python3 -B bstack/scripts/package.py check
+      - run: python3 -B bstack/scripts/layers.py check
+      - run: python3 -B bstack/scripts/test_package.py
+      - run: python3 -B -m unittest discover -s bstack/shared/tests
+      - run: python3 -B -m unittest discover -s bstack/github/tests

bstack/CHANGELOG.md

@@ -4,6 +4,7 @@ User-visible changes collect under **Unreleased** until a version is published.
 
 ## Unreleased
 
+- Require an isolated worker for untrusted PR reviews, validate targets before contacting GitHub, limit repeated model calls, reject unsafe model-written publication text, and stop reusing public receipts as proof of another checkout's review. Trusted PRs can explicitly use host access. Run package and reviewer checks on every PR.
 - Keep PR briefings short and place useful visuals beside the explanation they support.
 - Use the shared configured CLI launcher for PR reviews and Codex PR visuals, including wrapper commands.
 - Make automatic engineering routing the new-install default. Existing projects keep their saved setting; `bstack-auto off` restores manual routing.

bstack/INSTALL.md

@@ -146,6 +146,8 @@ python3 .bstack/package/scripts/bstack.py doctor --project "$PWD" --live --workf
 
 The live check sends a short prompt to the configured model for each role. A failed role stops that workflow and tells you whether to fix login, choose another model, or correct the launcher. The PR review runner also checks its roles before a new full review. Autonomous grilling's normal preflight checks its CLI roles before planning writes. The `to-pr` check proves Codex can answer a text prompt; its image tool and the final picture still need a real visual attempt.
 
+For an untrusted PR, `review-pr` also needs an isolated model worker. The general model doctor checks model access; the review runner's own `doctor --live` checks its worker canary. See [review setup](engineering/review-pr/references/running.md) before automating reviews. A trusted PR can be reviewed with the explicit `--trusted-pr` flag, which gives the models ordinary host access.
+
 If a tool is launched through a local wrapper, tell your agent the working terminal command. For example, a wrapper that runs `launch claude -- <arguments>` can be saved once:
 
 ```sh

bstack/README.md

@@ -82,7 +82,7 @@ You can enter at any point. A bug fix does not need a Wayfinder map, and a plann
 
 Invoke a skill with your tool's native prefix, such as `$how` in Codex or `/how` in Claude Code and Cursor. [SDLC entries](sdlc/README.md) and [engineering entries](engineering/README.md) describe the individual workflows. The local [workspace app](workspace/README.md) and agent CLI share planning and ticket records.
 
-Some workflows need more than the host running your chat. For example, [review-pr](engineering/review-pr/SKILL.md) calls authenticated GitHub, Codex, and Claude Code CLIs. Installing bstack does not sign in to those services. The [model doctor](INSTALL.md#check-optional-model-workflows) tests the selected models when you need them and supports local wrapper commands.
+Some workflows need more than the host running your chat. For example, [review-pr](engineering/review-pr/SKILL.md) calls authenticated GitHub, Codex, and Claude Code CLIs. Installing bstack does not sign in to those services. The [model doctor](INSTALL.md#check-optional-model-workflows) tests the selected models and supports local wrapper commands. Reviewing untrusted PRs also requires an isolated worker; the review runner checks its boundary before starting models.
 
 ### What loads into context
 

bstack/engineering/review-pr/SKILL.md

@@ -23,11 +23,13 @@ python3 /absolute/skill-directory/scripts/review.py doctor --project /path/to/pr
 python3 /absolute/skill-directory/scripts/review.py run --project /path/to/project --pr https://github.com/owner/repo/pull/123
 ```
 
+For untrusted PRs, configure the isolated worker described in [reviewer-job security](references/security.md) and [run details](references/running.md) before `run`. If you trust the current PR code and discussion and accept ordinary host access, add `--trusted-pr` to `run`. That grant covers only those inputs; a later push or new PR discussion needs a new explicit `run --trusted-pr` or an isolated worker. Never use that flag in an unattended callback.
+
 Confirm the target PR and local project. The first draft uses authenticated GitHub CLI for the forge and Claude Code/Codex CLIs for model execution. The calling agent can run in any host with those dependencies. The runner probes the chosen roles before starting a new paid review. If a CLI requires a wrapper, configure it through the shared [model launcher](../../shared/model_cli.py) and retry doctor; do not assemble a one-off shell workaround. Missing clients, unsupported flags, unavailable models, and failed responses are incomplete reviews, never permission to substitute a model or approve.
 
-The runner checks whether review work is needed before starting models. Closed PRs are skipped; confirmed merge conflicts defer review. Unchanged compatible assessments can be reused locally or from this GitHub account's own published review. Another developer's review remains feedback to evaluate, not proof that this developer's models ran. Different models or `run --fresh` start an independent pass, with earlier public feedback available as evidence.
+The runner checks whether review work is needed before starting models. Closed PRs are skipped; confirmed merge conflicts defer review. Unchanged compatible local assessments can be reused. A published review from another checkout is discussion evidence, not proof that this checkout's models ran. Different models or `run --fresh` start an independent pass, with earlier public feedback available as evidence.
 
-A follow-up uses the last complete assessment, new changes and affected context. Each reviewer receives its own earlier report when available, not the other current reviewer's report. If the PR changes during review or before publication, the runner repeats both reviewers and the adjudicator on the delta, up to three passes total. Human rebuttals can also trigger reassessment without a code change. Evaluate them honestly: accept supported corrections or justified noncritical trade-offs, and defend findings that still hold. Follow the rubric for critical failures and decision authority.
+A follow-up uses the last complete assessment, new changes and affected context. Each reviewer receives its own earlier report when available, not the other current reviewer's report. With an isolated worker, a PR change during review or before publication repeats both reviewers and the adjudicator on the delta, up to three passes total. A trusted host-access run stops if the code or discussion changes and needs a fresh grant. Human rebuttals can also trigger reassessment without a code change. Evaluate them honestly: accept supported corrections or justified noncritical trade-offs, and defend findings that still hold. Follow the rubric for critical failures and decision authority.
 
 ## Read the result
 

bstack/engineering/review-pr/references/rubric.md

@@ -21,4 +21,4 @@ A finding names a reachable trigger or material structural cost, the consequence
 
 An unresolved material coverage gap makes the review incomplete. It is not evidence of a bug, and does not erase valid findings elsewhere. Explain why uninspected content matters; a changed binary file alone does not establish a material gap. A failed mapped archive verification remains an unresolved integrity gap. Read-only review does not require rerunning tests. A missing live check makes coverage incomplete only when you can name the consequential behavior you cannot assess from the available code and evidence. No findings is valid; do not fill empty categories.
 
-Write for a busy developer. Usually two short sentences per finding: what can happen and why it matters, then the useful next step. Link evidence instead of narrating the runner or repeating the same point in the title, explanation and action. Use plain language without softening real blockers to meet a length target.
+Write for a busy developer. Usually two short sentences per finding: what can happen and why it matters, then the useful next step. Give precise evidence paths and lines; the runner makes the published links. Keep model prose plain text, without Markdown links or images. Do not narrate the runner or repeat the same point in the title, explanation and action. Use plain language without softening real blockers to meet a length target.