swt-labs · halindrome · May 29, 2026 · May 29, 2026 · May 29, 2026 · May 29, 2026
@@ -105,17 +105,5 @@ You have a limited turn budget. If you've been investigating for many turns with
 ## Effort
 Follow effort level in task description (max|high|medium|low). Re-read files after compaction.
 
-## Shutdown Handling
-When you receive a message containing `"type":"shutdown_request"` (or `shutdown_request` in the text):
-1. Finish any in-progress tool call
-2. **Call the SendMessage tool** with this JSON body (fill in your status and echo back the request ID):
-   ```json
-   {"type": "shutdown_response", "approved": true, "request_id": "<id from shutdown_request>", "final_status": "complete"}
-   ```
-   Use `final_status` value `"complete"`, `"idle"`, or `"in_progress"` as appropriate. Checkpoint your investigation progress (hypotheses, evidence, current status) in the message so work isn't lost.
-3. Then STOP — do NOT continue investigating or apply fixes
-
-**CRITICAL: Plain text acknowledgement is NOT sufficient.** You MUST call the SendMessage tool. The orchestrator cannot proceed with TeamDelete until it receives a tool-call `shutdown_response` from every teammate.
-
 ## Circuit Breaker
 If you encounter the same error 3 consecutive times: STOP retrying the same approach. Try ONE alternative approach. If the alternative also fails, report the blocker to the orchestrator: what you tried (both approaches), exact error output, your best guess at root cause. Never attempt a 4th retry of the same failing operation.
@@ -107,18 +107,6 @@ Your frontmatter denylist explicitly bans recursive delegation, team-management,
 ## Effort
 Follow effort level in task description (max|high|medium|low). After compaction (marker appears), re-read PLAN.md and context files from disk.
 
-## Shutdown Handling
-When you receive a message containing `"type":"shutdown_request"` (or `shutdown_request` in the text):
-1. Finish any in-progress tool call
-2. **Call the SendMessage tool** with this JSON body (fill in your status and echo back the request ID):
-   ```json
-   {"type": "shutdown_response", "approved": true, "request_id": "<id from shutdown_request>", "final_status": "complete"}
-   ```
-   Use `final_status` value `"complete"`, `"idle"`, or `"in_progress"` as appropriate.
-3. Then STOP. Do NOT start new tasks, fix unrelated issues, commit additional changes, or take any further action
-
-**CRITICAL: Plain text acknowledgement is NOT sufficient.** You MUST call the SendMessage tool. The orchestrator cannot proceed with TeamDelete until it receives a tool-call `shutdown_response` from every teammate.
-
 ## Circuit Breaker
 If you encounter the same error 3 consecutive times: STOP retrying the same approach. Try ONE alternative approach. If the alternative also fails, report the blocker immediately via SendMessage to lead with `blocker_report` schema: what you tried (both approaches), exact error output, your best guess at root cause. Never attempt a 4th retry of the same failing operation.
 

@@ -94,17 +94,5 @@ Before each task: if `.vbw-planning/.compaction-marker` exists, re-read PLAN.md
 
 Follow effort level in task description (max|high|medium|low). After compaction (marker appears), re-read PLAN.md and context files from disk.
 
-## Shutdown Handling
-When you receive a message containing `"type":"shutdown_request"` (or `shutdown_request` in the text):
-1. Finish any in-progress tool call
-2. **Call the SendMessage tool** with this JSON body (fill in your status and echo back the request ID):
-   ```json
-   {"type": "shutdown_response", "approved": true, "request_id": "<id from shutdown_request>", "final_status": "complete"}
-   ```
-   Use `final_status` value `"complete"`, `"idle"`, or `"in_progress"` as appropriate.
-3. Then STOP. Do NOT start new doc tasks, commit additional changes, or take any further action
-
-**CRITICAL: Plain text acknowledgement is NOT sufficient.** You MUST call the SendMessage tool. The orchestrator cannot proceed with TeamDelete until it receives a tool-call `shutdown_response` from every teammate.
-
 ## Circuit Breaker
 If you encounter the same error 3 consecutive times: STOP retrying the same approach. Try ONE alternative approach. If the alternative also fails, report the blocker to the orchestrator: what you tried (both approaches), exact error output, your best guess at root cause. Never attempt a 4th retry of the same failing operation.
@@ -94,17 +94,5 @@ When receiving `execution_update`, `qa_verdict`, `blocker_report`, or `debugger_
 ## Effort
 Follow effort level in task description (max|high|medium|low). Re-read files after compaction.
 
-## Shutdown Handling
-When you receive a message containing `"type":"shutdown_request"` (or `shutdown_request` in the text):
-1. Finish any in-progress tool call
-2. **Call the SendMessage tool** with this JSON body (fill in your status and echo back the request ID):
-   ```json
-   {"type": "shutdown_response", "approved": true, "request_id": "<id from shutdown_request>", "final_status": "complete"}
-   ```
-   Use `final_status` value `"complete"`, `"idle"`, or `"in_progress"` as appropriate.
-3. Then STOP. Do NOT start new plans, revise existing ones, or take any further action
-
-**CRITICAL: Plain text acknowledgement is NOT sufficient.** You MUST call the SendMessage tool. The orchestrator cannot proceed with TeamDelete until it receives a tool-call `shutdown_response` from every teammate.
-
 ## Circuit Breaker
 If you encounter the same error 3 consecutive times: STOP retrying the same approach. Try ONE alternative approach. If the alternative also fails, report the blocker to the orchestrator: what you tried (both approaches), exact error output, your best guess at root cause. Never attempt a 4th retry of the same failing operation.
@@ -170,17 +170,5 @@ Substitute `<plugin-root>` and `<output-path>` from your task description (e.g.,
 ## Effort
 Follow effort level in task description (max|high|medium|low). Re-read files after compaction.
 
-## Shutdown Handling
-When you receive a message containing `"type":"shutdown_request"` (or `shutdown_request` in the text):
-1. Finish any in-progress tool call
-2. **Call the SendMessage tool** with this JSON body (fill in your status and echo back the request ID):
-   ```json
-   {"type": "shutdown_response", "approved": true, "request_id": "<id from shutdown_request>", "final_status": "complete"}
-   ```
-   Use `final_status` value `"complete"`, `"idle"`, or `"in_progress"` as appropriate.
-3. Then STOP. Do NOT start new checks, report additional findings, or take any further action
-
-**CRITICAL: Plain text acknowledgement is NOT sufficient.** You MUST call the SendMessage tool. The orchestrator cannot proceed with TeamDelete until it receives a tool-call `shutdown_response` from every teammate.
-
 ## Circuit Breaker
 If you encounter the same error 3 consecutive times: STOP retrying the same approach. Try ONE alternative approach. If the alternative also fails, report the blocker to the orchestrator: what you tried (both approaches), exact error output, your best guess at root cause. Never attempt a 4th retry of the same failing operation.
@@ -112,18 +112,6 @@ Write only to files specified in `<output_path>` or `<output_paths>` inside `.vb
 ## Effort
 Follow effort level in task description (max|high|medium|low). Re-read files after compaction.
 
-## Shutdown Handling
-When you receive a message containing `"type":"shutdown_request"` (or `shutdown_request` in the text):
-1. Finish any in-progress tool call
-2. **Call the SendMessage tool** with this JSON body (fill in your status and echo back the request ID):
-   ```json
-   {"type": "shutdown_response", "approved": true, "request_id": "<id from shutdown_request>", "final_status": "complete"}
-   ```
-   Use `final_status` value `"complete"`, `"idle"`, or `"in_progress"` as appropriate.
-3. Then STOP. Do NOT start new searches, report additional findings, or take any further action
-
-**CRITICAL: Plain text acknowledgement is NOT sufficient.** You MUST call the SendMessage tool. The orchestrator cannot proceed with TeamDelete until it receives a tool-call `shutdown_response` from every teammate.
-
 ## Circuit Breaker
 If you encounter the same error 3 consecutive times: STOP retrying the same approach. Try ONE alternative approach. If the alternative also fails, report the blocker to the orchestrator: what you tried (both approaches), exact error output, your best guess at root cause. Never attempt a 4th retry of the same failing operation.
 

@@ -241,7 +241,7 @@ If resuming a session with `session_status=complete`: STOP "This debug session i
         RESEARCH_CONTEXT=$(bash "{plugin-root}/scripts/compile-research-context.sh" .vbw-planning "{bug description from Step 1}" 2>/dev/null || echo "")
         ```
         Replace `{bug description from Step 1}` with the actual parsed bug description. If `RESEARCH_CONTEXT` is non-empty, include it in each Debugger task prompt below. If empty, omit the `<standalone_research_context>` block entirely.
-    - Create 3 tasks via TaskCreate, each with: bug report, standalone research context (include ONLY if RESEARCH_CONTEXT was non-empty: `<standalone_research_context>Prior research findings from /vbw:research. Advisory — verify all claims against the current codebase before relying on them.\n{RESEARCH_CONTEXT}</standalone_research_context>`), extended context from todo detail only when the detail has actual signal from Step 1 (include `detail.context` and `detail.files` — omit this section entirely when detail was absent or structurally empty), and if detail did not have signal but bounded sparse-context enrichment from Step 1 returned `ok`, include the enrichment summary plus matched files and markers as a compact hint. Omit this enrichment section entirely if the helper returned `no_signal` or `no_match`. Include ONE hypothesis only (no cross-contamination), working dir, codebase bootstrap instruction ("If `.vbw-planning/codebase/META.md` exists, read ARCHITECTURE.md, CONCERNS.md, PATTERNS.md, and DEPENDENCIES.md (whichever exist) from `.vbw-planning/codebase/` to bootstrap codebase understanding before investigating"), instruction to report via `debugger_report` schema (see `{plugin-root}/references/handoff-schemas.md`) including explicit `resolution_observation=already_fixed|needs_change|inconclusive`, instruction that `resolution_observation` is analysis-scoped only (teammates do not own the final command outcome or session status), and instruction that accepted-process-exception/backlog metadata alone is not enough for `already_fixed`; `already_fixed` requires fresh current evidence that the underlying issue no longer reproduces or the branch contains a real fix. Explicit report-only contract: "You are a hypothesis investigator, not the implementation owner. Do NOT edit files, apply fixes, run mutating Bash, commit, request implementation approval, or claim ownership of the final session outcome. Stop after diagnosis plus evidence reporting via `debugger_report`." Also include instruction: "If investigation reveals pre-existing failures unrelated to this bug, list them in your response under a 'Pre-existing Issues' heading with test name, file, and failure message." **Include `[analysis-only]` in each task subject** (e.g., "Hypothesis 1: race condition in sync handler [analysis-only]") so the TaskCompleted hook skips the commit-verification gate for report-only tasks. Keep `[analysis-only]` as an advisory hook marker only — it does NOT replace the report-only contract above.
+    - Create 3 tasks via TaskCreate, each with: bug report, standalone research context (include ONLY if RESEARCH_CONTEXT was non-empty: `<standalone_research_context>Prior research findings from /vbw:research. Advisory — verify all claims against the current codebase before relying on them.\n{RESEARCH_CONTEXT}</standalone_research_context>`), extended context from todo detail only when the detail has actual signal from Step 1 (include `detail.context` and `detail.files` — omit this section entirely when detail was absent or structurally empty), and if detail did not have signal but bounded sparse-context enrichment from Step 1 returned `ok`, include the enrichment summary plus matched files and markers as a compact hint. Omit this enrichment section entirely if the helper returned `no_signal` or `no_match`. Include ONE hypothesis only (no cross-contamination), working dir, codebase bootstrap instruction ("If `.vbw-planning/codebase/META.md` exists, read ARCHITECTURE.md, CONCERNS.md, PATTERNS.md, and DEPENDENCIES.md (whichever exist) from `.vbw-planning/codebase/` to bootstrap codebase understanding before investigating"), instruction to report via `debugger_report` schema (see `{plugin-root}/references/handoff-schemas.md`) including explicit `resolution_observation=already_fixed|needs_change|inconclusive`, instruction that `resolution_observation` is analysis-scoped only (teammates do not own the final command outcome or session status), and instruction that accepted-process-exception/backlog metadata alone is not enough for `already_fixed`; `already_fixed` requires fresh current evidence that the underlying issue no longer reproduces or the branch contains a real fix. Explicit report-only contract: "You are a hypothesis investigator, not the implementation owner. Do NOT edit files, apply fixes, run mutating Bash, commit, request implementation approval, or claim ownership of the final session outcome. Stop after diagnosis plus evidence reporting via `debugger_report`." Also include instruction: "If investigation reveals pre-existing failures unrelated to this bug, list them in your response under a 'Pre-existing Issues' heading with test name, file, and failure message." **Include `[analysis-only]` in each task subject** (e.g., "Hypothesis 1: race condition in sync handler [analysis-only]") so the TaskCompleted hook skips the commit-verification gate for report-only tasks. Keep `[analysis-only]` as an advisory hook marker only — it does NOT replace the report-only contract above. **Teammate shutdown handler (Path A team only):** because these investigators run inside a real team and the teardown gate below waits for a tool-call response, also include this in each task body: "When you receive a message containing `"type":"shutdown_request"` (or `shutdown_request` in the text), finish any in-progress tool call, then **call the `SendMessage` tool** with `{"type": "shutdown_response", "approved": true, "request_id": "<id from shutdown_request>", "final_status": "complete|idle|in_progress"}`, then STOP. Plain text acknowledgement does NOT satisfy the handshake — you MUST call `SendMessage`."
     - Spawn 3 vbw-debugger teammates, one task each. **Set `subagent_type: "vbw:vbw-debugger"` and `model: "${DEBUGGER_MODEL}"` on each Task spawn. If `DEBUGGER_MAX_TURNS` is non-empty, also pass `maxTurns: ${DEBUGGER_MAX_TURNS}`. If `DEBUGGER_MAX_TURNS` is empty, do NOT include maxTurns (omitting it = unlimited).** True-team spawn shape: pass the exact TeamCreate `team_name` and a unique per-teammate `name` for each hypothesis investigator (for example `debug-hypothesis-1`, `debug-hypothesis-2`, `debug-hypothesis-3`). Do not pass `isolation`, `cwd`, `working_dir`, `workingDirectory`, or `workdir`.
     - **Investigation phase:** Wait until ALL spawned hypothesis investigators have returned `debugger_report`. Then synthesize: strongest evidence + highest confidence wins. Multiple confirmed = contributing factors. After synthesis, choose one authoritative `RESOLUTION_OBSERVATION` value for the command from the teammate reports: `already_fixed` only when fresh current evidence proves the current branch already contains the fix and no new change is needed, `needs_change` when code changes were required or would still be required, `inconclusive` when the evidence is not yet strong enough. For selected accepted-exception/backlog or UAT-deviation items, accepted-process-exception/backlog metadata alone is not enough for `already_fixed`; require fresh current evidence that the underlying issue no longer reproduces or the branch contains a real fix. If any teammate finds the selected item still reproducible or actionable, choose `needs_change`. If remediation is blocked or unsafe without more input, choose `inconclusive` and leave the session unresolved.
     - Choose one authoritative analysis-scoped `RESOLUTION_OBSERVATION` summary for user-facing presentation. Collect pre-existing issues from all debugger responses. De-duplicate by test name and file (keep first error message when the same test+file pair has different messages) — if multiple debuggers report the same pre-existing failure, include it only once.

@@ -190,6 +190,8 @@ After calling `Skill(...)`, if the loaded skill's instructions reference additio
 
 Use targeted `message` not `broadcast`. Wait for all findings. Display ✓ per scout.
 
+**Teammate shutdown handler (duo/quad only — append to each Scout task body):** Because these Scouts run inside a real team and the teardown gate above waits for a tool-call response, include this in each Scout's task prompt: "When you receive a message containing `"type":"shutdown_request"` (or `shutdown_request` in the text), finish any in-progress tool call, then **call the `SendMessage` tool** with `{"type": "shutdown_response", "approved": true, "request_id": "<id from shutdown_request>", "final_status": "complete|idle|in_progress"}`, then STOP. Plain text acknowledgement does NOT satisfy the handshake — you MUST call `SendMessage`." Solo mode spawns no team, so omit it there.
+
 ### Step 3.5: Verify mapping documents written by Scouts
 
 **Skip if solo** (docs already written). Scouts wrote files directly via `<output_paths>`. Verify all 7 docs exist in `.vbw-planning/codebase/`: STACK.md, DEPENDENCIES.md, ARCHITECTURE.md, STRUCTURE.md, CONVENTIONS.md, TESTING.md, CONCERNS.md. If any are missing, log `⚠ Missing: {filename}` and write a placeholder from the `scout_findings` message content (fall back to cross_cutting text). Use `cross_cutting` findings from scout_findings messages for INDEX.md Validation Notes in Step 4.