feat(orchestration): run ticket workers as launched threads and follow T3 nightlies

skills/engineering/implement/SKILL.md

@@ -11,9 +11,9 @@ Implement the work described by the user in the specification or tickets, follow
 
 Resolve referenced skills through the current harness's available-skills catalog and read their `SKILL.md` before following them. In Codex, apply those instructions directly with the available tools. If a referenced skill is unavailable, perform its step directly and report that fallback.
 
-1. Find the issue tracker in `docs/agents/issue-tracker.md`, the file the `## Agent skills` block in `AGENTS.md` or `CLAUDE.md` points to. If it is missing, invoke the `setup-xenrya-stack` skill and continue once it reports. As a subagent, stop and report the missing file instead, since setup needs the user's answers. Done when you have read the tracker file, and you follow it for every step that reads or updates an issue.
+1. Find the issue tracker in `docs/agents/issue-tracker.md`, the file the `## Agent skills` block in `AGENTS.md` or `CLAUDE.md` points to. If it is missing, invoke the `setup-xenrya-stack` skill and continue once it reports. When a parent's brief started you (a delegated task or a launched worker thread), stop and report the missing file instead, since setup needs the user's answers. Done when you have read the tracker file, and you follow it for every step that reads or updates an issue.
 2. Implement the requested behavior. Use the `tdd` skill where possible, at pre-agreed seams.
-3. Run the repository's typecheck and affected test files regularly during implementation. Run the full test suite once implementation is complete. As a subagent, follow the brief's Validation field: when it says the parent runs the full suite, skip it and say so. Report unavailable checks or existing failures accurately, and don't fix failures the brief lists as already on the base branch.
-4. Commit the task's changes and push to the current branch, unless the user's instructions or repository rules specify another delivery path. Use the `pr` skill to prepare and open the pull request. As a subagent, follow the brief's delivery instructions instead: when the parent owns commits and PRs, leave the changes uncommitted.
+3. Run the repository's typecheck and affected test files regularly during implementation. Run the full test suite once implementation is complete. When a parent's brief started you, follow its Validation field: when it says the parent runs the full suite, skip it and say so. Report unavailable checks or existing failures accurately, and don't fix failures the brief lists as already on the base branch.
+4. Commit the task's changes and push to the current branch, unless the user's instructions or repository rules specify another delivery path. Use the `pr` skill to prepare and open the pull request. When a parent's brief started you, follow its delivery instructions instead: when the parent owns commits and PRs, leave the changes uncommitted.
 
 Report the implemented behavior, validation results, and pull request URL, including any unresolved findings or skipped checks.

skills/engineering/interrogation/SKILL.md

@@ -38,25 +38,61 @@ Before spawning reviewers, state the intent explicitly. Derive this from:
 - PR description if one exists
 - The code itself
 
-Write one clear paragraph for each scope; with several PRs, each PR's intent comes from its ticket and description. If you're unsure about the intent, ask the user before proceeding.
+Write one clear paragraph for each scope; with several PRs, each PR's intent comes from its ticket and description. A PR's review guide is not a source: an agent wrote it. If you're unsure about the intent, ask the user before proceeding.
 
 ## Step 3, Delegate Reviewers
 
 Read and follow [delegate-subagents](../../orchestration/delegate-subagents/SKILL.md), or its installed copy from the active harness's skill catalog. Apply its instructions with the available tools; a harness-specific Skill tool is not required.
 
+### Where each review runs
+
+Reviewers are `delegate_task` children, so they inherit the checkout of the thread that dispatches them, and T3 labels them with that thread's branch. Run each scope's review from a thread bound to that scope's checkout:
+
+- **Scope in this thread's checkout** (the current branch, or local files): you are the lead. Do the rest of Step 3 and Steps 4–5 here.
+- **Scope in another checkout** (a PR in its own worktree, such as the PRs from `swarm-tickets`): you are the parent. Resolve the reviewer roster below, then launch one **lead thread** per PR, bound to that PR's checkout with `existing_worktree`, as [Launched workers](../../orchestration/delegate-subagents/SKILL.md#launched-workers) describes. Each lead dispatches that PR's reviewers and judges their findings. Launch a fresh lead rather than reusing the thread that wrote the code, so the author doesn't judge its own review.
+
+Title each lead `Interrogate PR #<N> (<ticket>) [interrogate-<date>-pr<N>-r1]`, and send it this brief:
+
+```text
+Read the skill at <absolute path to interrogation/SKILL.md> and act as the lead
+for one scope. A parent thread launched you: finish everything in this one turn.
+
+Scope: PR #<N> (<ticket>), base <base> at <commit>, head <commit>, checkout
+<absolute path>. This thread is bound to that checkout. Frozen diff: <path>.
+Intent: <the Step 2 paragraph>.
+Reviewers: <one line per reviewer: provider · model · options>.
+Repository guidance and glossary: <paths>.
+
+Do Step 3 for this scope only, with one change: dispatch every reviewer in one
+message of parallel delegate_task calls with mode "wait" and timeoutMs 1800000,
+so the reviews finish inside this turn. Count a reviewer that returns
+waitTimedOut as incomplete coverage and give its taskId. Then do Steps 4 and 5
+and return the verdict in the Output Format, starting with
+"## Verdict: PR #<N>". Don't edit the repository, apply fixes, commit, push,
+or touch PRs or databases.
+```
+
+The leads wait on their reviewers with `mode: "wait"` because the parent's `t3_thread_wait` returns when the lead's turn ends. A lead that ended its turn to wait for notifications would look finished before its reviews were in.
+
+As the parent, wait on each lead and read its verdict, the last assistant message, as Launched workers describes. A lead that failed or returned no verdict is missing coverage for its PR. Then go to the Output Format with the leads' verdicts.
+
+### Dispatching reviewers
+
+The parent resolves the roster (the next two paragraphs) before it launches leads, and a launched lead uses the roster in its brief. Everything after the roster is the lead's work.
+
 Call `orchestrator_capabilities` and resolve the user's requested models, or a reviewer roster in applicable project instructions, to live `providerInstanceId` and model IDs. An existing `interrogate reviewers` list can supply preferences; it is not a separate model catalog. Check child-task support, cross-provider constraints, and supported model options. Treat `auto` or `inherit-parent` as a request to inherit the caller's selection, rather than as a literal model ID.
 
-Without a requested roster, choose two distinct capable models, preferring different providers. Use a smaller roster if availability requires it and report the reduced diversity. State the selected providers/models before dispatch. Report an unavailable requested model instead of silently substituting a family default. Refresh capabilities and correct actionable dispatch errors; retain valid reviewers and identify any unavailable entries.
+Without a requested roster, choose two distinct capable models, preferring different providers. Use a smaller roster if availability requires it, including a provider the project turned off ("is disabled for project"), and report the reduced diversity. State the selected providers/models before dispatch. Report an unavailable requested model instead of silently substituting a family default. Refresh capabilities and correct actionable dispatch errors; retain valid reviewers and identify any unavailable entries.
 
 Read [the reviewer prompt](references/reviewer-prompt.md), [review rubric](references/rubric.md), and [code-quality lens](references/code-quality-review.md). Fill the prompt with the intent, checkout path, frozen review scope, surrounding context, repository guidance, and the domain glossary: `GLOSSARY.md`, or the glossaries `GLOSSARY-MAP.md` lists for the touched contexts. Insert the full rubric and code-quality lens into their placeholders. Structural improvements are review proposals; reviewers must leave the implementation unchanged.
 
-Reviewers receive only their supplied task prompt, so include the needed context or absolute paths to accessible snapshot artifacts. Keep each initial review independent of the other reviewers' findings and send the same filled prompt to every selected model.
+Reviewers receive only their supplied task prompt, so include the needed context or absolute paths to accessible snapshot artifacts. Keep each initial review independent of the other reviewers' findings and send the same filled prompt to every selected model. Don't send reviewers a PR's review guide: it would steer every reviewer the same way.
 
 Use T3-owned child tasks through `delegate_task`, with `role:"review"`, `mode:"async"`, and inherited permission modes. Pass the shared brief as `task` and the resolved selection as `target:{providerInstanceId,model}`. For an inherited selection, omit the corresponding target overrides. With several PRs, give each PR its own reviewers, one per selected model, with that PR's intent and diff. Title each task `Interrogate PR #<N> (<ticket>)` and give it a `clientRequestId` such as `interrogate-<date>-pr<N>-<model>-r1`. Launch independent reviewers together when the harness supports parallel tool calls. Retain one stable `clientRequestId` per reviewer/round and every returned `taskId` with its actual provider/model.
 
-The brief must prohibit repository edits, applying fixes, commits, pushes, PR creation, migrations, and database writes. `role:"review"` labels the task; it does not enforce a filesystem restriction, and T3 has no `readonly` or `subagent_type` argument. Child reviews belong to this conversation: never create reviewers with `t3_thread_launch` or `create_threads`.
+The brief must prohibit repository edits, applying fixes, commits, pushes, PR creation, migrations, and database writes. `role:"review"` labels the task; it does not enforce a filesystem restriction, and T3 has no `readonly` or `subagent_type` argument. Reviewers are always `delegate_task` children of their lead: never create reviewers with `t3_thread_launch` or `create_threads`.
 
-Follow `delegate-subagents` for completion notifications, `task_status` result collection, cancellation, and any additional review rounds. When only reviewers remain, end the turn and resume on their completion notifications. Collect published results before issuing the verdict; a completed child turn with pending descendants is still unfinished work. Failed, cancelled, or unavailable reviewers must be reported as incomplete coverage.
+Follow `delegate-subagents` for completion notifications, `task_status` result collection, cancellation, and any additional review rounds. When only reviewers remain, a lead in its own thread ends the turn and resumes on their completion notifications; a launched lead follows its brief. Collect published results before issuing the verdict; a completed child turn with pending descendants is still unfinished work. Failed, cancelled, or unavailable reviewers must be reported as incomplete coverage.
 
 ## Step 4, Synthesize
 
@@ -72,7 +108,7 @@ As results come back, build a unified picture:
 
 You are the lead reviewer, a pragmatic senior engineer, not a neutral aggregator.
 
-Read [the lead-judgment framework](references/lead-judgment.md) before categorizing findings. Apply the conversation context, project constraints, and pragmatic filtering that independent reviewers may lack. Verify each actionable claim against the reviewed snapshot and stated intent. A concrete lone-model finding can outweigh unsupported consensus. Missing coverage is not an endorsement.
+Read [the lead-judgment framework](references/lead-judgment.md) before categorizing findings. Apply the conversation context, project constraints, and pragmatic filtering that independent reviewers may lack. Verify each actionable claim against the reviewed snapshot and stated intent. A concrete lone-model finding can outweigh unsupported consensus. Missing coverage is not an endorsement. When a reviewed PR has a review guide (`read_pull_request_guide`), you may use its Look closely stops as a coverage check: a stop that no finding covers is one to check yourself.
 
 Categorize every finding using these buckets:
 
@@ -89,7 +125,7 @@ For each finding, include:
 
 ## Output Format
 
-Present the verdict in this structure. With several PRs, start with a table of PR, reviewers, and Act On count, then give one full verdict per PR.
+Present the verdict in this structure. With several PRs, start with a table of PR, lead thread, reviewers, and Act On count, then give one full verdict per PR. Link each lead thread as `[title](t3-thread://v1/<threadId>)`. Link a PR's review guide when one exists.
 
 ### Intent
 
@@ -125,7 +161,7 @@ Identify omitted reviewers, unavailable targets, and failed tasks. Distinguish t
 
 Stop after the verdict. Apply nothing until the user asks. When the user asks for fixes:
 
-- If the PRs came from `swarm-tickets`, its phase 7 (Revise) does the fixes. It sends each PR's Act On findings back to that ticket's original worker as a new round in the same workspace, then runs `pr` again for each changed PR.
+- If the PRs came from `swarm-tickets`, its phase 7 (Revise) does the fixes. It sends each PR's Act On findings to that ticket's worker thread as a new round, not to the lead thread, then runs `pr` again for each changed PR.
 - Otherwise, follow `delegate-subagents` phase 4 for a correction round, or fix the code yourself when the user asks you to.
 
 In both cases, list the findings being fixed and the ones left alone, so the fixer changes only what was accepted.

skills/engineering/pr/SKILL.md

@@ -45,10 +45,20 @@ author anything. Every claim rests on **proof**:
 6. **Publish.** Open or update the PR only when the user or the calling skill
    asks. If a PR already exists for the branch, update its title and body.
    Upload the images to the PR. When PR-linking tools are available, link the
-   PR to the thread. Done when the PR shows the drafted title and body and
-   every image renders.
-7. **Report.** Give the PR URL, or the full title and body when you did not
-   publish, then the validation results and any skipped checks.
+   PR to the thread by its URL, so T3 resolves the host. Done when the PR shows
+   the drafted title and body and every image renders.
+7. **Guide.** Only when the user, the calling skill, or the repository
+   instructions ask for a review guide. After the push, call
+   `write_pull_request_guides` with the PR's URL. It returns at once and a
+   guide takes minutes, so don't wait. Record the outcome: `started`,
+   `running`, or `failed` and why. "Review guides are off" or a repository
+   with no checkout here is a skipped step, not a blocker. When updating a
+   PR, call `read_pull_request_guide` first, and rewrite only a guide that
+   exists and is `stale`. Done when the guide's outcome is recorded, or the
+   step is skipped because nobody asked.
+8. **Report.** Give the PR URL, or the full title and body when you did not
+   publish, then the validation results, any skipped checks, and the review
+   guide's outcome when one was asked for.
 
 ## Sections
 
@@ -60,6 +70,6 @@ author anything. Every claim rests on **proof**:
 | **Before and After** | An image table per changed screen, each with one line on what differs. With no images: `No image attached.` followed by the reason. |
 | **Validation**       | A table of check, command, and result. Then the temporary steps, and what wasn't run.          |
 | **Risk**             | Contract changes, behaviour that existing clients will notice, and coverage that was lost.    |
-| Issue reference      | `Closes #N` when this PR completes the issue; `Refs #N` for partial or uncertain work.        |
+| Issue reference      | The closing reference `docs/agents/issue-tracker.md` documents, such as `Closes #N`, when this PR completes the issue; `Refs #N` for partial or uncertain work. |
 | Attribution          | A line the harness asks you to end PR descriptions with, such as `🤖 Generated with [Claude Code](https://claude.com/claude-code)`. It goes directly above the Model line. Leave it out when the harness doesn't ask for one. |
 | Model                | The last line: `Model: <display name>`, the display name of the model you run as (such as `Claude Opus 5.5`), not its model ID. When other models wrote the branch's code, such as delegated workers, list every display name, comma-separated. |