knowzcode 0.3.7 → 0.4.0

package/commands/work.md

@@ -1,1202 +1,1204 @@
----
-description: "Start a new KnowzCode development workflow with TDD, quality gates, and structured phases"
-argument-hint: "[feature_description]"
----
-
-# Work on New Feature
-
-Start a new KnowzCode development workflow session.
-
-**Usage**: `/kc:work "feature description"`
-**Example**: `/kc:work "Build user authentication with JWT"`
-
-**Primary Goal**: $ARGUMENTS
-
----
-
-## Step 0: Prerequisite Check
-
-Verify KnowzCode is initialized:
-1. Check if `knowzcode/` directory exists
-2. Check required files exist: `knowzcode_loop.md`, `knowzcode_tracker.md`, `knowzcode_project.md`, `knowzcode_architecture.md`
-
-If missing: inform user to run `/kc:init` first. STOP.
-
-## Step 1: Generate WorkGroup ID
-
-**Format**: `kc-{type}-{slug}-YYYYMMDD-HHMMSS`
-
-- `{type}`: feat, fix, refactor, or issue
-- `{slug}`: 2-4 word kebab-case from goal (remove common words: build, add, create, implement, the, a, with, for)
-- Truncate slug to max 25 characters
-
-## Step 2: Select Execution Mode
-
-Determine the execution mode using try-then-fallback:
-
-1. Note user preferences from `$ARGUMENTS`:
-   - `--sequential` → prefer Sequential Teams
-   - `--subagent` → force Subagent Delegation (skip team creation attempt)
-
-2. **If `--subagent` NOT specified**, attempt `TeamCreate(team_name="kc-{wgid}")`:
-   - **If TeamCreate succeeds** → Agent Teams is available. Choose mode:
-     - `--sequential` or Tier 2 → **Sequential Teams**: `**Execution Mode: Sequential Teams** — created team kc-{wgid}`
-     - Otherwise → **Parallel Teams** (default for Tier 3): `**Execution Mode: Parallel Teams** — created team kc-{wgid}`
-   - **If TeamCreate fails** (error, unrecognized tool, timeout) → **Subagent Delegation**: `**Execution Mode: Subagent Delegation** — Agent Teams not available, using Task() fallback`
-
-3. **If `--subagent` specified** → **Subagent Delegation** directly (no TeamCreate attempt):
-   - Announce: `**Execution Mode: Subagent Delegation** — per user request`
-
-For all Agent Teams modes (Sequential and Parallel):
-- You are the **team lead** in delegate mode — you coordinate phases, present quality gates, and manage the workflow. You NEVER write code, specs, or project files directly. All work is done by teammates. (Tip: the user can press Shift+Tab to system-enforce delegate mode.)
-- After completion or if the user cancels, shut down all active teammates and clean up the team (see Cleanup section)
-
-For Subagent Delegation:
-- For each phase, delegate via `Task()` with the parameters specified in phase sections below
-
-The user MUST see the execution mode announcement before any phase work begins. The phases, quality gates, and interactions are identical across all paths.
-
-> **Note:** Agent Teams is experimental and the API may change.
-
-## Step 2.4: Load Orchestration Config (Optional)
-
-If `knowzcode/knowzcode_orchestration.md` exists, parse its YAML blocks:
-
-1. `MAX_BUILDERS` = `max_builders` value (default: 5, clamp to 1-5)
-2. `SCOUT_MODE` = `scout_mode` value (default: "full")
-3. `DEFAULT_SPECIALISTS` = `default_specialists` value (default: [])
-4. `MCP_AGENTS_ENABLED` = `mcp_agents_enabled` value (default: true)
-5. `CODEBASE_SCANNER_ENABLED` = `codebase_scanner_enabled` value (default: true)
-6. `PARALLEL_SPEC_THRESHOLD` = `parallel_spec_threshold` value (default: 3, clamp to 2-10)
-
-Apply flag overrides (flags win over config):
-- `--max-builders=N` in `$ARGUMENTS` → override `MAX_BUILDERS`
-- `--no-scouts` in `$ARGUMENTS` → override `SCOUT_MODE = "none"`
-- `--no-mcp` in `$ARGUMENTS` → override `MCP_AGENTS_ENABLED = false`
-- `--no-scanners` in `$ARGUMENTS` → override `CODEBASE_SCANNER_ENABLED = false`
-- `--no-parallel-specs` in `$ARGUMENTS` → override `PARALLEL_SPEC_THRESHOLD = 999` (effectively disabled)
-
-If the file doesn't exist, use hardcoded defaults (current behavior).
-
-## Step 2.5: Autonomous Mode Detection
-
-Set `AUTONOMOUS_MODE = true` if ANY of these match:
-
-a. **Flags**: `$ARGUMENTS` contains `--autonomous` or `--auto`
-
-b. **Natural language** (case-insensitive match in `$ARGUMENTS` OR the user's preceding conversation message):
-   - Approval intent: "approve all", "pre-approve", "preapprove", "auto-approve"
-   - Mode intent: "autonomous mode", "autonomous", "unattended", "hands off", "hands-off"
-   - Proceed intent: "don't stop to ask", "don't ask me", "no approval needed", "just run through", "run it all", "run straight through", "proceed without asking", "skip the gates", "go all the way through"
-   - Delegation intent: "I trust your judgement", "use your best judgement", "defer to your judgement", "you decide"
-
-c. **Contextual** — if the user's message conveys clear intent for the lead to operate without stopping (even if none of the exact phrases above match), interpret that as autonomous mode. The spirit of the instruction matters more than exact phrasing.
-
-Default: `AUTONOMOUS_MODE = false`
-
-If `AUTONOMOUS_MODE = true`, announce after the execution mode announcement:
-> **Autonomous Mode: ACTIVE** — Gates presented for transparency but auto-approved.
-> Safety exceptions still pause: critical blockers, HIGH/CRITICAL security findings, >3 same-phase failures, complex architecture discrepancies, >3 gap-fix iterations per partition.
-
-## Step 2.6: Specialist Detection
-
-Set `SPECIALISTS_ENABLED = []` (empty list).
-
-If `DEFAULT_SPECIALISTS` is non-empty (from Step 2.4), initialize:
-`SPECIALISTS_ENABLED = DEFAULT_SPECIALISTS`
-
-Determine which specialists to activate (flags and natural language add to or override the baseline):
-- `--specialists` → enable all 3: `[security-officer, test-advisor, project-advisor]`
-- `--specialists=csv` → enable specific subset (comma-separated, e.g., `--specialists=security,test`):
-  - `security` → `security-officer`
-  - `test` → `test-advisor`
-  - `project` → `project-advisor`
-- `--no-specialists` → explicit opt-out, `SPECIALISTS_ENABLED = []`
-
-**Natural language detection** (case-insensitive match in `$ARGUMENTS` OR the user's preceding conversation message):
-- All specialists: "with specialists", "with officers", "full specialist panel"
-- security-officer: "security review", "threat model", "vulnerability scan", "pentest"
-- test-advisor: "test quality", "TDD enforcement", "test coverage", "test rigor"
-- project-advisor: "backlog", "future work", "brainstorm", "ideas"
-
-**Mode constraints:**
-- Tier 3 Parallel Teams: Full support (Group C)
-- Tier 3 Subagent Delegation: Supported via parallel `Task()` calls
-- Sequential Teams / Tier 2: Not supported — if specialists were detected, announce: `> **Specialists: SKIPPED** — not supported in {Sequential Teams / Tier 2} mode.`
-
-Default: `SPECIALISTS_ENABLED = []` (specialists are opt-in).
-
-If `SPECIALISTS_ENABLED` is non-empty, announce after the autonomous mode announcement (or after the execution mode announcement if autonomous is not active):
-> **Specialists: ACTIVE** — {comma-separated list of enabled specialists}
-
-## Step 3: Load Context Files (ONCE)
-
-Read these files ONCE (do NOT re-read between phases):
-- `knowzcode/knowzcode_loop.md`
-- `knowzcode/knowzcode_tracker.md`
-- `knowzcode/knowzcode_project.md`
-- `knowzcode/knowzcode_architecture.md`
-
-## Step 3.5: Pull Team Standards (MCP — Optional)
-
-If MCP is configured and enterprise compliance is enabled:
-1. Check `knowzcode/enterprise/compliance_manifest.md` for `mcp_compliance_enabled: true`
-2. If enabled: Read `knowzcode/knowzcode_vaults.md` to find vault matching type "enterprise", then `ask_question({resolved_enterprise_vault_id}, "team standards for {project_type}")`
-3. Merge returned standards into WorkGroup context for quality gate criteria
-
-If MCP is not configured or enterprise is not enabled, skip this step.
-
-## Step 4: Create WorkGroup File
-
-Create `knowzcode/workgroups/{WorkGroupID}.md`:
-```markdown
-# WorkGroup: {WorkGroupID}
-
-**Primary Goal**: {$ARGUMENTS}
-**Created**: {timestamp}
-**Status**: Active
-**Current Phase**: 1A - Impact Analysis
-**Autonomous Mode**: Active/Inactive
-
-## Change Set
-(Populated after Phase 1A)
-
-## Todos
-- KnowzCode: Initialize WorkGroup
-- KnowzCode: Complete Phase 1A impact analysis
-
-## Phase History
-| Phase | Status | Timestamp |
-|-------|--------|-----------|
-| 1A | In Progress | {timestamp} |
-```
-
-## Step 5: Input Classification
-
-**Question indicators** (suggest `/kc:plan` instead): starts with is/does/how/why/what/should, contains `?`, phrased as inquiry.
-
-**Implementation indicators** (proceed): starts with build/add/create/implement/fix/refactor, action-oriented verbs.
-
-If ambiguous, proceed with implementation.
-
-## Step 5.5: Complexity Classification
-
-Assess the goal against the codebase to determine the appropriate workflow tier.
-
-### Tier 1: Micro → redirect to `/kc:fix`
-- Single file, <50 lines, no ripple effects
-
-### Tier 2: Light (2-phase workflow)
-
-> **Note:** Light mode does not use orchestration config — single builder, no scouts, no specialists.
-
-ALL must be true:
-- ≤3 files touched
-- Single NodeID (1 new capability)
-- No architectural changes
-- No security-sensitive components (auth, payments, PII)
-- No external API integrations
-- Estimated <200 lines of change
-
-### Tier 3: Full (5-phase workflow)
-ANY triggers full:
-- >3 files or >1 NodeID
-- Architectural impact
-- Security-sensitive scope
-- External integrations
-- User explicitly requests: `--tier full`
-
-**Announce the detected tier to the user.** User can override:
-- "use full" or `--tier full` → Tier 3
-- "use light" or `--tier light` → Tier 2
-
-If `$ARGUMENTS` contains `--tier light`, force Tier 2. If `--tier full`, force Tier 3.
-
----
-
-## Tier 2: Light Workflow (2-phase fast path)
-
-When Tier 2 is selected, execute this streamlined workflow instead of the 5-phase Tier 3 below.
-
-### Light Phase 1 (Inline — lead does this, no agent)
-
-1. Quick impact scan: grep for related files, check existing specs
-2. Propose a Change Set (typically 1 NodeID)
-3. Draft a lightweight spec (or reference existing spec if found) — use the 4-section format from `knowzcode_loop.md` section 3.2. Minimum: 1 Rule, 1 Interface, 2 `VERIFY:` statements.
-4. Present combined Change Set + Spec for approval:
-
-```markdown
-## Light Mode: Change Set + Spec Approval
-
-**WorkGroupID**: {wgid}
-**Tier**: 2 (Light)
-**NodeID**: {NodeID} — {description}
-**Affected Files**: {list}
-
-**Spec Summary**:
-- Rules: {key decisions}
-- Interfaces: {public contracts}
-- VERIFY: {criteria list}
-
-Approve Change Set and spec to proceed to implementation?
-```
-
-5. **Autonomous Mode**: If `AUTONOMOUS_MODE = true`, log `[AUTO-APPROVED] Light mode gate` and proceed directly to implementation.
-   If `AUTONOMOUS_MODE = false`: If rejected — adjust based on feedback and re-present. If approved:
-   - Update `knowzcode_tracker.md` with NodeID status `[WIP]`
-   - Pre-implementation commit: `git add knowzcode/ && git commit -m "KnowzCode: Light spec approved for {wgid}"`
-
-### Light Phase 2A: Implementation (Builder agent)
-
-Spawn the builder using the standard Phase 2A prompt below (same for both tiers).
-
-The builder self-verifies against spec VERIFY criteria — no separate audit phase.
-
-### Light Phase 3 (Inline — lead does this, no agent)
-
-After builder completes successfully:
-1. Update spec to As-Built status
-2. Update `knowzcode_tracker.md`: NodeID status `[WIP]` → `[VERIFIED]`
-3. Write a brief log entry to `knowzcode_log.md`:
-   ```markdown
-   ---
-   **Type:** ARC-Completion
-   **Timestamp:** [timestamp]
-   **WorkGroupID:** [ID]
-   **NodeID(s):** [list]
-   **Logged By:** AI-Agent
-   **Details:** Light mode (Tier 2). {brief summary of implementation}.
-   ---
-   ```
-4. Final commit: `git add knowzcode/ <changed files> && git commit -m "feat: {goal} (WorkGroup {wgid})"`
-5. Report completion.
-
-**DONE** — 3 agents skipped (analyst, architect, reviewer, closer).
-
----
-
-## Tier 3: Full Workflow (5-phase)
-
-The standard 5-phase workflow. Used when complexity warrants full analysis, specification, audit, and finalization.
-
-Tier 3 supports three execution modes (determined in Step 2):
-- **Parallel Teams** (default) — Stage 0-3 orchestration with concurrent agents
-- **Sequential Teams** (`--sequential`) — one agent per phase, spawned and shut down sequentially
-- **Subagent Delegation** — Task() calls, no persistent agents
-
-## Step 6: Spec Detection (Optional Optimization)
-
-Check for existing specs covering this work:
-1. Extract key terms from goal
-2. Search `knowzcode/specs/*.md` for matching specs
-3. If comprehensive matching specs found, offer:
-   - **A) Quick Path** — skip discovery, use existing specs
-   - **B) Validation Path** (recommended) — quick check specs match codebase
-   - **C) Full Workflow** — complete Phase 1A discovery
-
-If no matches found, proceed to Phase 1A.
-
-### Refactor Task Check
-
-Scan `knowzcode/knowzcode_tracker.md` for outstanding `REFACTOR_` tasks that overlap with the current goal's scope. If found, mention them to the user during Phase 1A so the analyst can factor them into the Change Set.
-
----
-
-## Parallel Teams Orchestration (Tier 3 Default)
-
-When Parallel Teams mode is active, follow these 4 stages instead of spawning one agent per phase sequentially. The same phase spawn prompts (defined in the Phase Reference sections below) are reused — what changes is WHEN agents are spawned and HOW MANY run concurrently.
-
-### Stage 0: Team Creation + Parallel Discovery
-
-1. Create team `kc-{wgid}`
-2. Read knowzcode context files (lead does initial load for spawn prompts)
-3. **MCP Probe** — determine vault availability BEFORE spawning:
-   a. Read `knowzcode/knowzcode_vaults.md` — partition entries into CONFIGURED (non-empty ID) and UNCREATED (empty ID)
-   b. Call `list_vaults(includeStats=true)` **always** — regardless of whether any IDs exist in the file
-   c. If `list_vaults()` fails:
-      - Check if `knowzcode/knowzcode_vaults.md` has any CONFIGURED entries (non-empty ID)
-      - **If CONFIGURED entries exist**: Set `MCP_ACTIVE = true`, `VAULTS_CONFIGURED = true` — vault agents will verify connectivity independently via their Startup Verification. Announce `**MCP Status: Lead probe failed — delegating verification to vault agents**`. Proceed to Step 4.
-      - **If no CONFIGURED entries** (all empty IDs or no file): Set `MCP_ACTIVE = false`, announce `**MCP Status: Not connected**`, skip Group B spawn
-   d. If `list_vaults()` succeeds AND UNCREATED list is non-empty → present the **Vault Creation Prompt**:
-
-      ```markdown
-      ## Vault Setup
-
-      Your Knowz API key is valid and MCP is connected, but {N} default vault(s) haven't been created yet.
-      Creating vaults enables knowledge capture throughout the workflow:
-
-      | Vault | Type | Description | Written During |
-      |-------|------|-------------|----------------|
-      ```
-
-      Build table rows dynamically from the UNCREATED entries only. For each uncreated vault, derive the "Written During" column from its Write Conditions field in `knowzcode_vaults.md`. Example rows:
-      - `| Code Patterns | code | Learnings, gotchas, and architecture insights from the codebase | Phase 2A (implementation patterns), Phase 3 (workarounds, performance) |`
-      - `| Ecosystem Knowledge | ecosystem | Business rules, conventions, decisions, and cross-system details | Phase 1A (scope decisions), Phase 2B (security, quality), Phase 3 (conventions) |`
-      - `| Finalizations | finalizations | Final summaries documenting complete execution and outcomes | Phase 3 (completion record) |`
-
-      Then present options:
-      ```
-      Options:
-        **A) Create all {N} vaults** (recommended)
-        **B) Select which to create**
-        **C) Skip** — proceed without vaults (can create later with `/kc:connect-mcp --configure-vaults`)
-      ```
-
-   e. Handle user selection:
-      - **A**: For each UNCREATED entry, call MCP `create_vault(name, description)`. If `create_vault` is not available, fall back to matching by name against `list_vaults()` results. Update `knowzcode_vaults.md`: fill the ID field with the server-returned vault ID and change the H3 heading from `(not created)` to the vault ID. If creation fails for some vaults, update only successful ones, report failures, and let user decide.
-      - **B**: Ask which vaults to create, then create only selected ones using the same process as A.
-      - **C**: Log `"Vault creation skipped — knowledge capture disabled."` Continue.
-   f. After resolution, set:
-      - `MCP_ACTIVE = true` (MCP works regardless of vault creation outcome)
-      - `VAULTS_CONFIGURED = true` if at least 1 vault now has a valid ID, else `false`
-      - Announce: `**MCP Status: Connected — N vault(s) available**` or `**MCP Status: Connected — no vaults configured (knowledge capture disabled)**`
-4. **Spawn Group A**:
-   Create tasks first, pre-assign, then spawn with task IDs:
-   - If `SCOUT_MODE = "full"` (default): spawn 3 context scouts (specs, workgroups, backlog) + analyst + architect (5 agents):
-     - `TaskCreate("Scout: specs context")` → `TaskUpdate(owner: "context-scout-specs")`
-     - `TaskCreate("Scout: workgroups context")` → `TaskUpdate(owner: "context-scout-workgroups")`
-     - `TaskCreate("Scout: backlog context")` → `TaskUpdate(owner: "context-scout-backlog")`
-   - If `SCOUT_MODE = "minimal"`: spawn 1 context-scout (combined scan) + analyst + architect (3 agents):
-     - `TaskCreate("Scout: combined context")` → `TaskUpdate(owner: "context-scout")`
-   - If `SCOUT_MODE = "none"`: spawn analyst + architect only (2 agents). Analyst and architect scan the codebase independently without pre-loaded scout context.
-   - Always:
-     - `TaskCreate("Phase 1A: Impact analysis for {goal}")` → `TaskUpdate(owner: "analyst")`
-     - `TaskCreate("Pre-load architecture context and speculative research")` → `TaskUpdate(owner: "architect")`
-   - If `CODEBASE_SCANNER_ENABLED = true` (default):
-     - Derive two search focuses from the goal:
-       - **Scanner-Direct**: source code search — grep for goal keywords, read affected code paths
-       - **Scanner-Tests**: test discovery — search test directories for tests covering the goal area
-     - `TaskCreate("Scanner: direct codebase scan for {goal}")` → `TaskUpdate(owner: "scanner-direct")`
-     - `TaskCreate("Scanner: test coverage scan for {goal}")` → `TaskUpdate(owner: "scanner-tests")`
-   Spawn all Group A agents with their `{task-id}` in the spawn prompt (use spawn prompts from Phase Prompt Reference below).
-5. **Spawn Group B** (MCP agents — same turn as Group A): If `VAULTS_CONFIGURED = true` AND `MCP_AGENTS_ENABLED = true`:
-   Create tasks first, pre-assign, then spawn with task IDs:
-   - `TaskCreate("Knowz-scout: vault queries")` → `TaskUpdate(owner: "knowz-scout")`
-   - `TaskCreate("Knowz-scribe: listen")` → `TaskUpdate(owner: "knowz-scribe")`
-   Spawn both agents with their `{task-id}` in the spawn prompt.
-   If `VAULTS_CONFIGURED = false` or `MCP_AGENTS_ENABLED = false`, skip Group B and log: `Vault agents skipped — no vaults configured` or `Vault agents skipped — MCP agents disabled in orchestration config.`
-6. **Spawn Group C** (specialist agents — same turn as Groups A and B): If `SPECIALISTS_ENABLED` is non-empty:
-   Create tasks first, pre-assign, then spawn with task IDs:
-   - If `security-officer` in list: `TaskCreate("Security officer: initial threat scan")` → `TaskUpdate(owner: "security-officer")`
-   - If `test-advisor` in list: `TaskCreate("Test advisor: coverage baseline")` → `TaskUpdate(owner: "test-advisor")`
-   - If `project-advisor` in list: `TaskCreate("Project advisor: backlog context")` → `TaskUpdate(owner: "project-advisor")`
-   Spawn each enabled specialist with its `{task-id}` in the spawn prompt (use spawn prompts from Specialist Spawn Prompts section below).
-   If `SPECIALISTS_ENABLED` is empty, skip Group C.
-7. **Roster confirmation** — lead lists every spawned agent by name to the user. Include scanners and Group C specialists if active. If `VAULTS_CONFIGURED` was true but knowz-scout or knowz-scribe is missing from the roster, STOP and re-spawn the missing agent(s) before continuing.
-8. All spawned agents work immediately in parallel (context scouts are cheap Sonnet read-only agents; scanners are lightweight general-purpose agents; knowz-scribe is a cheap Haiku agent; specialists are Sonnet read-only agents). Agent count depends on orchestration config: 2-12 agents at Stage 0.
-9. Scouts broadcast findings → analyst and architect consume as messages. Specialists work independently on their Stage 0 tasks.
-
-**Key**: The analyst does NOT wait for scouts, scanners, or specialists to finish. It starts scanning the codebase immediately. Scout and scanner findings arrive as messages and enrich the analyst's work as they arrive. The analyst also streams `[PRELIMINARY]` NodeID findings to the architect as it discovers them (see Preliminary Findings Protocol). Specialist findings are consumed by the lead at gates.
-
-### Stage 1: Analysis + Specification
-
-1. Analyst completes Change Set (includes dependency map — see `agents/analyst.md`)
-2. Lead reads analyst's task summary
-3. Shut down scanners (scanner-direct, scanner-tests) if they were spawned — no longer needed after analysis
-3. **Specialist Change Set reviews** (if `SPECIALISTS_ENABLED` non-empty): Create review tasks blocked on analysis:
-   - If `security-officer` active: `TaskCreate("Security officer: Change Set review", addBlockedBy: [analysis-task-id])` → `TaskUpdate(owner: "security-officer")`. DM security-officer: `"**New Task**: #{task-id} — Review Change Set for security risk. Rate each NodeID."`
-   - If `test-advisor` active: `TaskCreate("Test advisor: Change Set test strategy", addBlockedBy: [analysis-task-id])` → `TaskUpdate(owner: "test-advisor")`. DM test-advisor: `"**New Task**: #{task-id} — Recommend test types per NodeID."`
-4. Lead presents **Quality Gate #1** to user:
-   - Change Set with NodeIDs, descriptions, affected files
-   - Dependency map showing which NodeIDs can be implemented in parallel
-   - Risk assessment
-   - Specialist Reports (if active — see gate template below)
-5. User approves (or rejects → re-run analyst with feedback)
-6. Lead sends DM to architect with the approved Change Set
-7. **Spec Drafting** — choose path based on NodeID count and `PARALLEL_SPEC_THRESHOLD`:
-
-   **Path A: Standard (fewer than PARALLEL_SPEC_THRESHOLD NodeIDs)**
-   - Lead creates spec-drafting tasks for architect (1 task per NodeID, `addBlockedBy: [analysis-task-id]`):
-     - `TaskCreate("Spec: NodeID-X")` → `TaskUpdate(taskId, owner: "architect")`
-     - DM architect with task IDs: `"**New Tasks**: #{id-1} Spec: NodeID-A, #{id-2} Spec: NodeID-B. Approved Change Set: {summary}"`
-   - Architect is already warm (pre-loaded + speculative research during Stage 0) → specs drafted FAST
-   - If Gate #1 rejected: shut down architect, re-run analyst with feedback, re-spawn architect after
-
-   **Path B: Parallel Spec Drafting (PARALLEL_SPEC_THRESHOLD or more NodeIDs)**
-   - Lead DMs architect the full approved Change Set and asks for a partition plan (see `agents/architect.md` — Parallel Spec Coordination)
-   - Architect proposes NodeID partitions (1-2 NodeIDs each, max 3 partitions, respecting same-spec and interface constraints)
-   - Lead spawns spec-drafter agents — one per partition:
-     - Spec-drafters use the `architect` agent definition with a scoped spawn prompt
-     - Each drafter gets: its NodeID partition, architect's research findings, cross-NodeID interface constraints, consolidation instructions
-     - `TaskCreate("Spec draft: NodeID-A, NodeID-B")` → `TaskUpdate(owner: "spec-drafter-1")`
-     - Max 3 spec-drafters: `ceil(NodeID_count / 2)`, capped at 3
-   - Spec-drafters draft specs in parallel
-   - After all spec-drafters complete: architect runs consistency review (cross-spec alignment, naming, VERIFY coverage)
-   - Shut down spec-drafters after consistency review
-   - If Gate #1 rejected: shut down architect and any spec-drafters, re-run analyst with feedback, re-spawn architect after
-
-8. Architect completes specs (Path A) or architect completes consistency review (Path B)
-9. **Test-advisor spec review** (if `test-advisor` in `SPECIALISTS_ENABLED`): After specs drafted, create spec testability review task:
-   - `TaskCreate("Test advisor: spec testability review", addBlockedBy: [spec-task-id])` → `TaskUpdate(owner: "test-advisor")`
-   - DM test-advisor: `"**New Task**: #{task-id} — Review specs for testability. Check VERIFY criteria are automatable."`
-10. Lead presents **Quality Gate #2** to user:
-    - Spec summaries with VERIFY criteria
-    - Specialist Reports (if active — see gate template below)
-11. User approves (or rejects → architect revises)
-12. Pre-implementation commit: `git add knowzcode/ && git commit -m "KnowzCode: Specs approved for {wgid}"`
-13. Shut down context-scouts (no longer needed after specs approved). Keep knowz-scout alive for vault queries during implementation.
-14. Keep analyst alive briefly (available for scope questions during early implementation)
-15. Keep architect alive through Stage 2 (consultative role — spec clarifications for builders, no code or spec edits)
-
-### Stage 2: Parallel Implementation + Incremental Review
-
-1. Lead examines dependency map from analyst:
-   - Group NodeIDs into independent partitions (no shared files between groups)
-   - Determine builder count: 1 builder per independent group, max `MAX_BUILDERS` (default 5, configurable in `knowzcode_orchestration.md`)
-
-2. Create builder tasks and spawn:
-   - `TaskCreate("Implement NodeIDs [A, B]", addBlockedBy: [spec-task-id])` → `TaskUpdate(owner: "builder-1")`
-   - `TaskCreate("Implement NodeIDs [C]", addBlockedBy: [spec-task-id])` → `TaskUpdate(owner: "builder-2")`
-   - `TaskCreate("Implement NodeIDs [D, E]", addBlockedBy: [spec-task-id])` → `TaskUpdate(owner: "builder-3")`
-   Spawn each builder with its `{task-id}` in the spawn prompt.
-   Each builder gets its partition's specs + affected files list.
-   **NO TWO BUILDERS TOUCH THE SAME FILE**
-
-3. Notify architect of builder spawn:
-   - Lead DMs architect: `"Builders spawned for Stage 2. Introduce yourself to: {builder-1, builder-2, ...}"`
-   - Architect sends brief availability message to each builder (see `agents/architect.md` — Proactive Availability)
-
-4. Each builder creates subtasks per NodeID in the task list:
-   - `"TDD: NodeID-A tests"` → `"TDD: NodeID-A implementation"` → `"TDD: NodeID-A verify"`
-   - Builder works through subtasks, marks each complete with summary
-
-5. Create reviewer tasks and spawn — one per builder partition:
-   - `TaskCreate("Audit partition 1: NodeIDs [A, B]", addBlockedBy: [implement-A-task-id])` → `TaskUpdate(owner: "reviewer-1")`
-   - `TaskCreate("Audit partition 2: NodeIDs [C]", addBlockedBy: [implement-C-task-id])` → `TaskUpdate(owner: "reviewer-2")`
-   - `TaskCreate("Audit partition 3: NodeIDs [D, E]", addBlockedBy: [implement-D-task-id])` → `TaskUpdate(owner: "reviewer-3")`
-   Spawn each reviewer with its `{task-id}` + partition's specs + VERIFY criteria.
-   Reviewer stays idle until its paired builder marks first NodeID implementation complete.
-   Each reviewer audits incrementally within its partition.
-
-6. **Specialist implementation reviews** (if `SPECIALISTS_ENABLED` non-empty): Create specialist review tasks alongside reviewer audit tasks, same `addBlockedBy`:
-   - If `security-officer` active — one task per partition (runs parallel to reviewer):
-     `TaskCreate("Security officer: review partition {N}", addBlockedBy: [implement-X-task-id])` → `TaskUpdate(owner: "security-officer")`
-     DM security-officer: `"**New Task**: #{task-id} — Vulnerability scan for partition {N}. NodeIDs: {list}."`
-   - If `test-advisor` active — one task per partition:
-     `TaskCreate("Test advisor: review partition {N} tests", addBlockedBy: [implement-X-task-id])` → `TaskUpdate(owner: "test-advisor")`
-     DM test-advisor: `"**New Task**: #{task-id} — Test quality review for partition {N}. NodeIDs: {list}."`
-   - If `project-advisor` active — one observation task (not per-partition):
-     `TaskCreate("Project advisor: observe implementation")` → `TaskUpdate(owner: "project-advisor")`
-     DM project-advisor: `"**New Task**: #{task-id} — Observe builder progress, note patterns and ideas. Deliver backlog proposals before gap loop."`
-   **Gate #3 is NOT blocked by specialists.** If a specialist hasn't finished, gate shows `[Pending: {specialist}]`. Lead proceeds.
-   **Project-advisor early shutdown**: After project-advisor delivers backlog proposals, shut it down (before the gap loop begins).
-
-7. Gap flow (per-partition, parallel — persistent agents, DM messaging):
-   a. Each reviewer marks audit task complete with structured gap report in summary
-   b. Lead creates fix task and pre-assigns:
-      `TaskCreate("Fix gaps: NodeID-A", addBlockedBy: [audit-task-id])` → `TaskUpdate(owner: "builder-N")`
-   c. Lead sends DM to builder with task ID and gap details:
-      > **New Task**: #{fix-task-id} — Fix gaps: NodeID-A
-      > **Gaps**: {file path, VERIFY criterion not met, expected vs actual}
-      > Fix each gap, re-run affected tests, report completion.
-   d. Builder claims fix task, fixes gaps, re-runs tests, marks fix task complete
-   e. Lead creates re-audit task and pre-assigns:
-      `TaskCreate("Re-audit: NodeID-A", addBlockedBy: [gap-fix-task-id])` → `TaskUpdate(owner: "reviewer-N")`
-   f. Lead sends DM to reviewer: `"**New Task**: #{reaudit-task-id} — Re-audit: NodeID-A. {gap list}"`
-   g. Each builder-reviewer pair repeats independently until clean — no cross-partition blocking
-   — All builders and reviewers stay alive through the entire gap loop (no respawning)
-
-8. Enterprise compliance (if enabled):
-   - Lead creates parallel compliance task for each reviewer (scoped to their partition)
-   - Reviewer checks compliance requirements from knowz-scout findings
-   - Runs alongside ARC audits
-
-9. Inter-agent communication during Stage 2:
-   - builder → architect: Spec clarification requests (direct messages)
-   - architect → builder: Design guidance and spec intent responses (direct messages)
-   - builder ↔ builder: Dependency coordination (direct messages — "I changed the User interface, FYI")
-   - builder → reviewer (same partition): Implementation complete notifications (via task system)
-   - reviewer → lead: Gap reports per partition (structured format via task summaries)
-   - lead → builder: Fix tasks (via task creation + DM)
-   - lead → reviewer: Re-audit requests (via task creation + DM)
-   - security-officer → builder-N: Security guidance for sensitive partitions (max 2 DMs per builder)
-   - test-advisor → builder-N: Test improvement feedback (max 2 DMs per builder)
-   - security-officer ↔ test-advisor: Cross-cutting test gaps in security paths (max 2 inter-specialist DMs)
-   - project-advisor → knowz-scribe: Idea captures for vault storage
-   - project-advisor → lead: Backlog proposals (before gap loop)
-
-10. After all NodeIDs implemented + audited across all partitions:
-    - Lead consolidates audit results from all reviewers
-    - Lead consolidates specialist reports (if `SPECIALISTS_ENABLED` non-empty — include even if some specialist tasks are still pending, noting `[Pending: {specialist}]`)
-    - Lead presents **Quality Gate #3**:
-      - Per-NodeID ARC completion % (from each partition's reviewer)
-      - Combined security posture
-      - Combined integration health
-      - Enterprise compliance (if applicable)
-      - Specialist Reports (if active — see gate template below)
-    - User decides: proceed / fix gaps / modify specs / cancel
-
-11. Shut down analyst, architect, all builders, and all reviewers
-
-### Stage 3: Finalization
-
-1. Shut down remaining specialists (security-officer, test-advisor) if still active. Project-advisor should already be shut down from mid-Stage 2.
-2. `TaskCreate("Phase 3: Finalize {wgid}", addBlockedBy: [last-audit-task-id])` → `TaskUpdate(owner: "closer")`
-   Spawn `closer` with `{task-id}` in spawn prompt.
-3. Closer tasks (can be parallel subtasks):
-   - Update all specs to FINAL as-built
-   - Update `knowzcode_tracker.md`: all NodeIDs `[WIP]` → `[VERIFIED]`
-   - Write ARC-Completion log entry
-   - Review architecture docs for discrepancies
-   - Schedule REFACTOR tasks for tech debt
-   - Create capture task for knowz-scribe (if active): `TaskCreate("Scribe: Capture Phase 3")` → `TaskUpdate(owner: "knowz-scribe")`, then send DM with task ID: `"Capture Phase 3: {wgid}. Your task: #{task-id}"`. Knowz-scout remains available for vault queries during finalization.
-   - Create final atomic commit
-4. Lead presents completion summary
-5. **Wait for scribe Phase 3 capture** (if knowz-scribe is active):
-   - Check scribe capture task via `TaskGet(task-id)` — wait until status is `completed`
-   - Also wait for scribe's Phase 3 confirmation DM
-   - **Timeout**: If >2 minutes after closer completes and scribe task still not complete → DM scribe: `"Status check: Phase 3 capture for {wgid}?"`
-   - **Hard timeout**: If another minute passes with no completion → proceed with shutdown and log `WARNING: Scribe Phase 3 capture did not complete for {wgid}. Vault writes may be incomplete.`
-6. Shutdown order: knowz-scout, knowz-scribe, closer, remaining agents
-7. Delete team
-
-### WorkGroup File Format (Parallel Mode)
-
-In Parallel Teams mode, the WorkGroup file uses per-NodeID phase tracking instead of a single `Current Phase`:
-
-```markdown
-## Change Set
-| NodeID | Phase | Builder | Status | Timestamp |
-|--------|-------|---------|--------|-----------|
-| Authentication | 2A | builder-1 | Implementing | ... |
-| UserProfile | 2B | builder-1 | Under review | ... |
-| LIB_DateFormat | 2A | builder-2 | Tests passing | ... |
-
-## Autonomous Mode
-Active/Inactive
-
-## Current Stage
-Stage 2: Parallel Implementation + Incremental Review
-```
-
-### Task Dependency Graph
-
-When creating tasks, model the dependency chain with `addBlockedBy` and pre-assign with `owner`:
-
-| Task | Blocked By | Owner |
-|------|-----------|-------|
-| Scout: specs context | (none) | context-scout-specs |
-| Scout: workgroups context | (none) | context-scout-workgroups |
-| Scout: backlog context | (none) | context-scout-backlog |
-| Knowz-scout: vault queries | (none — persistent) | knowz-scout |
-| Knowz-scribe: listen | (none — persistent) | knowz-scribe |
-| Scanner: direct codebase scan | (none) | scanner-direct |
-| Scanner: test coverage scan | (none) | scanner-tests |
-| Phase 1A analysis | (none — scouts + scanners enrich via broadcast) | analyst |
-| Architect pre-load + speculative research | (none — receives [PRELIMINARY] DMs from analyst) | architect |
-| Security officer: initial threat scan | (none — Group C) | security-officer |
-| Test advisor: coverage baseline | (none — Group C) | test-advisor |
-| Project advisor: backlog context | (none — Group C) | project-advisor |
-| Security officer: Change Set review | Phase 1A analysis | security-officer |
-| Test advisor: Change Set test strategy | Phase 1A analysis | test-advisor |
-| Spec: NodeID-X | Phase 1A (gate approval) | architect (Path A) or spec-drafter-N (Path B) |
-| Spec consistency review | All spec drafts complete (Path B only) | architect |
-| Test advisor: spec testability review | Spec: NodeID-X | test-advisor |
-| Implement: NodeID-X | Spec: NodeID-X | builder-N |
-| Audit: NodeID-X | Implement: NodeID-X | reviewer-N |
-| Security officer: review partition N | Implement: NodeID-X | security-officer |
-| Test advisor: review partition N tests | Implement: NodeID-X | test-advisor |
-| Project advisor: observe implementation | (none) | project-advisor |
-| Fix gaps: NodeID-X round N | Audit: NodeID-X (or re-audit N-1) | builder-N |
-| Re-audit: NodeID-X round N | Fix gaps round N | reviewer-N |
-| Phase 3 finalization | All audits approved | closer |
-| Scribe: Capture Phase 1A | Phase 1A (gate approval) | knowz-scribe |
-| Scribe: Capture Phase 2A | Implement: NodeID-X | knowz-scribe |
-| Scribe: Capture Phase 2B | All audits approved | knowz-scribe |
-| Scribe: Capture Phase 3 | Phase 3 finalization | knowz-scribe |
-
----
-
-## Sequential Teams / Subagent Flow (Tier 3 Fallback)
-
-> **Note:** Sequential Teams does not use orchestration config settings except `MCP_AGENTS_ENABLED`.
-
-When using Sequential Teams (`--sequential`) or Subagent Delegation, follow the traditional one-agent-per-phase flow. For each phase below: spawn the agent, create a task, wait for completion, present quality gate, shut down agent, proceed to next phase.
-
-### MCP Probe (Sequential/Subagent)
-
-Determine vault availability before Phase 1A:
-
-1. Read `knowzcode/knowzcode_vaults.md` — check for CONFIGURED entries (non-empty ID)
-2. Attempt `list_vaults(includeStats=true)`
-3. If succeeds AND UNCREATED entries exist → present the **Vault Creation Prompt** (same as Parallel Teams Step 3d). Handle selection identically.
-4. After resolution, announce MCP status to the user:
-   - `list_vaults()` succeeded: `**MCP Status: Connected — N vault(s) available**`
-   - `list_vaults()` failed but configured vaults exist: `**MCP Status: Lead probe failed — closer will verify at Phase 3**`
-   - No configured vaults: `**MCP Status: Not configured**`
-
-The closer agent independently verifies MCP at Phase 3 regardless of this result (see `agents/closer.md` — Startup MCP Verification). This probe is for the user announcement and vault creation opportunity only.
-
----
-
-## Phase Prompt Reference
-
-The spawn prompts below are shared by all execution modes. In Parallel Teams mode, the lead uses these prompts when spawning agents at the appropriate stage. In Sequential Teams / Subagent mode, agents are spawned one at a time in phase order.
-
-## Stage 0: Context Scouts (3 instances)
-
-**Agent**: `context-scout` (x3) | Read-only local context researchers
-
-Three instances of the same agent, each focused on a different local folder group:
-
-**context-scout-specs spawn prompt**:
-> You are `context-scout-specs` for WorkGroup `{wgid}`.
-> Read `agents/context-scout.md` for your full role definition.
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Focus area**: `knowzcode/specs/*.md` — scan existing specifications.
-> **Goal**: {goal}
-> **READ-ONLY.** Do NOT modify any files.
-> **Deliverable**: Broadcast relevant spec findings (NodeIDs, status, VERIFY criteria overlapping with goal).
-
-**context-scout-workgroups spawn prompt**:
-> You are `context-scout-workgroups` for WorkGroup `{wgid}`.
-> Read `agents/context-scout.md` for your full role definition.
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Focus area**: `knowzcode/workgroups/*.md` — scan previous WorkGroups for similar goals.
-> **Goal**: {goal}
-> **READ-ONLY.** Do NOT modify any files.
-> **Deliverable**: Broadcast prior WorkGroup context (what was tried, what succeeded/failed, patterns).
-
-**context-scout-backlog spawn prompt**:
-> You are `context-scout-backlog` for WorkGroup `{wgid}`.
-> Read `agents/context-scout.md` for your full role definition.
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Focus area**: `knowzcode/knowzcode_tracker.md`, `knowzcode/knowzcode_log.md`, `knowzcode/knowzcode_architecture.md`, `knowzcode/knowzcode_project.md`
-> **Goal**: {goal}
-> **READ-ONLY.** Do NOT modify any files.
-> **Deliverable**: Broadcast active WIP, REFACTOR tasks, architecture summary, and recent log patterns relevant to goal.
-
-**context-scout (combined) spawn prompt** (used when `SCOUT_MODE = "minimal"`):
-> You are `context-scout` for WorkGroup `{wgid}`.
-> Read `agents/context-scout.md` for your full role definition.
-> **Your Task**: #{task-id} — claim immediately. Mark completed with summary when done.
-> **Focus area**: ALL local context — `knowzcode/specs/*.md`, `knowzcode/workgroups/*.md`, `knowzcode/knowzcode_tracker.md`, `knowzcode/knowzcode_log.md`, `knowzcode/knowzcode_architecture.md`, `knowzcode/knowzcode_project.md`
-> **Goal**: {goal}
-> **READ-ONLY.** Do NOT modify any files.
-> **Deliverable**: Broadcast consolidated findings covering specs, prior workgroups, active WIP, REFACTOR tasks, and architecture context.
-
-**Dispatch**:
-- *Parallel Teams*:
-  - `SCOUT_MODE = "full"`: 3 context scouts spawned at Stage 0. Shut down after Gate #2.
-  - `SCOUT_MODE = "minimal"`: 1 context-scout (combined) spawned at Stage 0. Shut down after Gate #2.
-  - `SCOUT_MODE = "none"`: No scouts spawned.
-- *Sequential Teams*: Not applicable (scouts are Parallel Teams only).
-- *Subagent*:
-  - `SCOUT_MODE = "full"`: 3 parallel `Task()` calls (specs, workgroups, backlog).
-  - `SCOUT_MODE = "minimal"`: 1 `Task()` call with combined prompt.
-  - `SCOUT_MODE = "none"`: Skip scout tasks.
-
----
-
-## Stage 0: Codebase Scanners (2 instances — conditional)
-
-**Agent**: `general-purpose` (x2) | Lightweight codebase searchers (no agent definition file)
-
-Two temporary agents that scan the codebase in parallel with the analyst, broadcasting findings to accelerate impact analysis. Only spawned when `CODEBASE_SCANNER_ENABLED = true` (default).
-
-**scanner-direct spawn prompt**:
-> You are `scanner-direct` for WorkGroup `{wgid}`.
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Goal**: {goal}
-> **Focus**: Search source code for goal-related keywords and patterns.
->
-> **Steps**:
-> 1. Grep for goal keywords across source files (exclude node_modules, dist, build, .git)
-> 2. Read the top 5-8 matching files to understand affected code paths
-> 3. Identify module boundaries and cross-module dependencies
-> 4. Note public APIs and interfaces that may need changes
->
-> **READ-ONLY.** Do NOT modify any files.
-> **Deliverable**: Broadcast findings to all teammates — affected files, code paths, module boundaries, and interface patterns.
-> **Budget**: Complete within ~12 turns. Focus on breadth over depth.
-
-**scanner-tests spawn prompt**:
-> You are `scanner-tests` for WorkGroup `{wgid}`.
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Goal**: {goal}
-> **Focus**: Discover tests covering the goal area to understand test patterns and coverage shape.
->
-> **Steps**:
-> 1. Glob for test files: `**/*.test.*`, `**/*.spec.*`, `**/test_*`, `**/tests/**`
-> 2. Grep test files for goal-related keywords
-> 3. Read 3-5 matching test files to understand testing patterns (test framework, mocking strategy, fixture patterns)
-> 4. Check for integration/e2e tests related to the goal area
->
-> **READ-ONLY.** Do NOT modify any files.
-> **Deliverable**: Broadcast findings to all teammates — test file locations, testing patterns, coverage gaps, and fixture/mock patterns.
-> **Budget**: Complete within ~12 turns. Focus on breadth over depth.
-
-**Dispatch**:
-- *Parallel Teams*: Spawned at Stage 0 if `CODEBASE_SCANNER_ENABLED = true`. Use `subagent_type: "general-purpose"`, `maxTurns: 12`. Shut down after Stage 1 (analyst completes Change Set).
-- *Sequential Teams*: Not applicable (scanners are Parallel Teams only).
-- *Subagent*: `Task(subagent_type="general-purpose", description="Scan codebase for {focus}", maxTurns=12, prompt=<above>)` if `CODEBASE_SCANNER_ENABLED = true`.
-
----
-
-## Stage 0: Knowz Scout
-
-**Agent**: `knowz-scout` | MCP vault researcher and knowledge agent
-
-**Spawn prompt**:
-> You are the **knowz-scout** for WorkGroup `{wgid}`.
-> Read `agents/knowz-scout.md` for your full role definition.
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Goal**: {goal}
-> **Step 1**: Read `knowzcode/knowzcode_vaults.md` to discover configured vaults — their IDs, types, descriptions, and what knowledge each contains.
-> **Step 2**: For each configured vault, construct goal-relevant queries using the vault's description to guide what to ask. If a single vault covers all knowledge, consolidate queries there.
-> **Deliverable**: Broadcast vault knowledge findings to all teammates.
-
-**Dispatch**:
-- *Parallel Teams*: **Group B** — spawned at Stage 0 if `VAULTS_CONFIGURED = true`, no blockedBy. Persistent — stays alive through the entire workflow. Shut down after Phase 3 capture is complete.
-- *Sequential Teams*: Not applicable (scouts are Parallel Teams only).
-- *Subagent*: `Task(subagent_type="knowz-scout", description="Query vault for domain knowledge", prompt=<above>)` (only if MCP Probe passes)
-
----
-
-## Stage 0: Knowz Scribe
-
-**Agent**: `knowz-scribe` | Persistent vault write agent (Haiku)
-
-**Spawn prompt**:
-> You are the **knowz-scribe** for WorkGroup `{wgid}`.
-> Read `agents/knowz-scribe.md` for your full role definition.
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
-> **Vault config**: Read `knowzcode/knowzcode_vaults.md` to discover configured vaults and resolve vault IDs by type.
-> **You are a message-driven agent.** Wait for capture messages from teammates (e.g., "Capture Phase 1A: {wgid}"). On each message, read the WorkGroup file, extract relevant learnings, and write to the appropriate vault.
-> **Do NOT read or modify source code.** You only read knowzcode/ files and write to MCP vaults.
-
-**Dispatch**:
-- *Parallel Teams*: **Group B** — spawned at Stage 0 if `VAULTS_CONFIGURED = true`, no blockedBy. Persistent — stays alive through the entire workflow. Shut down after Phase 3 capture is complete.
-- *Sequential Teams*: Not applicable (knowz-scribe is Parallel Teams only).
-- *Subagent*: Not applicable — vault writes in subagent mode are handled by the closer during Phase 3 finalization (see Direct Write Fallback in `agents/closer.md`).
-
----
-
-## Specialist Spawn Prompts (Group C — opt-in via `--specialists`)
-
-The spawn prompts below are used when `SPECIALISTS_ENABLED` is non-empty. Specialists are spawned at Stage 0 alongside Groups A and B.
-
-**Dispatch** (all specialists):
-- *Parallel Teams*: Group C — spawned at Stage 0 if `SPECIALISTS_ENABLED` non-empty, no blockedBy. Security-officer and test-advisor persist through Gate #3. Project-advisor shuts down mid-Stage 2.
-- *Sequential Teams*: Not supported — announce skip reason.
-- *Subagent*: `Task()` calls with spawn prompts below.
-
-### Security Officer
-
-**Agent**: `security-officer` | Officer — CRITICAL/HIGH findings block gates
-
-**Spawn prompt**:
-> You are the **security-officer** for WorkGroup `{wgid}`.
-> Read `agents/security-officer.md` for your full role definition.
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Goal**: {goal}
-> **READ-ONLY.** Do NOT modify any files. Bash is for read-only security scanning only.
-> **Stage 0 Deliverable**: Build STRIDE-lite threat model. Scan for auth/PII/crypto/session patterns. Broadcast initial threat assessment.
-> **Authority**: CRITICAL/HIGH findings use `[SECURITY-BLOCK]` tag — lead MUST pause autonomous mode.
-> **Communication**: DM lead at gates. DM architect with security VERIFY criteria needs. DM builders in security-sensitive partitions (max 2 per builder). DM test-advisor for cross-cutting test gaps (max 2).
-> **Enterprise Compliance**: If `knowzcode/enterprise/compliance_manifest.md` exists and `compliance_enabled: true`, read active security guidelines and cross-reference findings with enterprise guideline IDs.
-
-### Test Advisor
-
-**Agent**: `test-advisor` | Advisor — informational only
-
-**Spawn prompt**:
-> You are the **test-advisor** for WorkGroup `{wgid}`.
-> Read `agents/test-advisor.md` for your full role definition.
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Goal**: {goal}
-> **READ-ONLY.** Do NOT modify any files. Bash is for read-only operations only (git log, coverage reports).
-> **Stage 0 Deliverable**: Establish test coverage baseline. Glob test files, run coverage if available. Broadcast baseline.
-> **Communication**: DM lead at gates. DM architect if VERIFY criteria aren't testable. DM builders with test improvement feedback (max 2 per builder). DM security-officer for cross-cutting security test gaps (max 2).
-> **Enterprise Compliance**: If `knowzcode/enterprise/compliance_manifest.md` exists and `compliance_enabled: true`, check enterprise ARC criteria for test coverage gaps.
-
-### Project Advisor
-
-**Agent**: `project-advisor` | Advisor — informational only
-
-**Spawn prompt**:
-> You are the **project-advisor** for WorkGroup `{wgid}`.
-> Read `agents/project-advisor.md` for your full role definition.
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Goal**: {goal}
-> **READ-ONLY.** Do NOT modify any files.
-> **Stage 0 Deliverable**: Read tracker for existing REFACTOR tasks and backlog context. DM lead with context summary.
-> **Lifecycle**: You shut down mid-Stage 2 after delivering backlog proposals — before the gap loop.
-> **Communication**: DM lead with backlog context and proposals. DM knowz-scribe with idea captures (if active). Do NOT DM builders or other specialists.
-> **Enterprise Compliance**: If `knowzcode/enterprise/compliance_manifest.md` exists, note compliance configuration gaps in backlog proposals.
-
----
-
-## Phase 1A: Impact Analysis
-
-**Agent**: `analyst` | **Loop.md**: Section 3.1
-
-**Spawn prompt**:
-> You are the **analyst** for WorkGroup `{wgid}`.
-> Read `agents/analyst.md` for your full role definition.
->
-> **Goal**: {goal}
-> **Context files**: Read sections 1-2 and 3.1 of `knowzcode/knowzcode_loop.md` (skip other phases), `knowzcode/knowzcode_tracker.md`, `knowzcode/knowzcode_project.md`, `knowzcode/knowzcode_architecture.md`
-> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
->
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Conventions**: Update WorkGroup file with results (prefix entries with `KnowzCode:`). If blocked, report blocker and notify lead.
-> **Codebase scanners**: Scanner agents are running in parallel — their findings will arrive as broadcast messages. Incorporate them into your analysis but do NOT wait for them.
-> **Preliminary Findings Protocol**: As you discover high-confidence NodeIDs, DM the architect with `[PRELIMINARY]` messages (max 3 — see `agents/analyst.md` for format). This lets the architect start speculative research early.
-> **Deliverable**: Change Set proposal written to the WorkGroup file. Include NodeIDs, descriptions, affected files, risk assessment, and dependency map (for Parallel Teams mode).
-
-**Dispatch**:
-- *Parallel Teams*: Spawned at Stage 0 alongside scouts, scanners, and architect. Starts immediately (no blockedBy).
-- *Sequential Teams*: Spawn teammate `analyst`, create task `Phase 1A: Impact analysis for "{goal}"`, wait for completion.
-- *Subagent*: `Task(subagent_type="analyst", description="Phase 1A impact analysis", prompt=<above>)`
-
-### Quality Gate #1
-
-Present the Change Set for user approval:
-
-```markdown
-## Approval Gate #1: Change Set
-
-**WorkGroupID**: {wgid}
-**Proposed Change Set** ({N} nodes):
-{NodeIDs with descriptions}
-
-**Dependency Map** (Parallel Teams):
-{NodeID parallelism groups}
-
-**Risk Assessment**: {Low/Medium/High}
-
-### Specialist Reports                    [only when SPECIALISTS_ENABLED non-empty]
-**Security Officer**: {risk assessment per NodeID, attack surface changes, threat model}
-**Architect**: {architecture impact, layer touch points, pattern alignment}
-**Test Advisor**: {coverage baseline, test strategy recommendations per NodeID}
-
-Approve this Change Set to proceed to specification?
-```
-
-**Autonomous Mode**: If `AUTONOMOUS_MODE = true`, present gate info for transparency, log `[AUTO-APPROVED] Gate #1`, and proceed immediately.
-If `AUTONOMOUS_MODE = false`: If rejected — re-run analyst with user feedback. If approved — update tracker, proceed.
-
-### MCP Learning Capture (Optional)
-
-If MCP is configured and knowz-scribe is active, after Change Set approval:
-- Create capture task: `TaskCreate("Scribe: Capture Phase 1A")` → `TaskUpdate(owner: "knowz-scribe")`
-- Send message to **knowz-scribe** with task ID: `"Capture Phase 1A: {wgid}. Your task: #{task-id}"` — the scribe reads the WorkGroup file, extracts scope/risk/decision data, and writes to the appropriate vault
-- `search_knowledge({resolved_domain_vault_id}, "patterns for {domain}")` — pull relevant past learnings to inform specification
-- Share any relevant findings with the architect in the Phase 1B prompt
-
----
-
-## Stage 0: Architect Pre-load (Parallel Teams)
-
-**Agent**: `architect` | Spawned at Stage 0 for context pre-loading and speculative research
-
-In Parallel Teams mode, the architect is spawned at Stage 0 (not at Phase 1B). It pre-loads architecture context and performs speculative research on `[PRELIMINARY]` NodeIDs from the analyst.
-
-**Stage 0 spawn prompt** (Parallel Teams only):
-> You are the **architect** for WorkGroup `{wgid}`.
-> Read `agents/architect.md` for your full role definition.
->
-> **Goal**: {goal}
-> **Context files**: Read sections 1-2 and 3.2 of `knowzcode/knowzcode_loop.md` (skip other phases), `knowzcode/knowzcode_project.md`, `knowzcode/knowzcode_architecture.md`
-> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
-> **Specs directory**: `knowzcode/specs/`
->
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Stage 0 Role**: Pre-load architecture context, then perform speculative research on any `[PRELIMINARY]` NodeID messages from the analyst (see Speculative Research Protocol in `agents/architect.md`). READ-ONLY research — do NOT write specs yet.
-> **Lifecycle**: You persist through the entire workflow. After Gate #1, you will receive spec-drafting tasks via DM. After Gate #2, you shift to consultative role for builders.
-
-After Gate #1, the lead sends the approved Change Set via DM and creates spec-drafting tasks. For spec-drafting prompts, see Phase 1B below.
-
----
-
-## Phase 1B: Specification
-
-**Agent**: `architect` | **Loop.md**: Section 3.2
-
-**Spec-drafting prompt** (sent via DM to already-warm architect in Parallel Teams, or as spawn prompt in Sequential/Subagent):
-> You are the **architect** for WorkGroup `{wgid}`.
-> Read `agents/architect.md` for your full role definition.
->
-> **Goal**: {goal}
-> **Approved Change Set**: {NodeIDs from Gate #1}
-> **Context files**: Read sections 1-2 and 3.2 of `knowzcode/knowzcode_loop.md` (skip other phases), `knowzcode/knowzcode_project.md`, `knowzcode/knowzcode_architecture.md`
-> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
-> **Specs directory**: `knowzcode/specs/`
->
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Conventions**: Update WorkGroup file with results (prefix entries with `KnowzCode:`). If blocked, report blocker and notify lead.
-> **Deliverable**: Finalized specs for all NodeIDs written to `knowzcode/specs/`.
-
-**Spec-drafter spawn prompt** (Path B — 3+ NodeIDs, Parallel Teams only):
-> You are `spec-drafter-{N}` for WorkGroup `{wgid}`.
-> Read `agents/architect.md` for your full role definition — you follow the same Spec Philosophy, Spec Format, and Consolidation Mandate.
->
-> **Goal**: {goal}
-> **Your NodeIDs**: {partition — 1-2 NodeIDs assigned to this drafter}
-> **Architect Research**: {research findings from architect's speculative research for these NodeIDs}
-> **Cross-NodeID Constraints**: {interface dependencies, shared specs, naming conventions from architect}
-> **Context files**: Read sections 1-2 and 3.2 of `knowzcode/knowzcode_loop.md`, `knowzcode/knowzcode_project.md`, `knowzcode/knowzcode_architecture.md`
-> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
-> **Specs directory**: `knowzcode/specs/`
->
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Deliverable**: Draft specs for your assigned NodeIDs written to `knowzcode/specs/`. The architect will review for consistency after all drafters finish.
-
-**Dispatch**:
-- *Parallel Teams*:
-  - **Path A** (< PARALLEL_SPEC_THRESHOLD NodeIDs): Architect is already warm from Stage 0 pre-load + speculative research. Lead sends DM with approved Change Set, then creates spec-drafting tasks. **Plan approval enabled** — add to prompt: `Present your spec design for lead review BEFORE writing final specs. Wait for approval.` If `AUTONOMOUS_MODE = true`: auto-approve `plan_approval_request` immediately. Log `[AUTO-APPROVED] Architect plan`.
-  - **Path B** (>= PARALLEL_SPEC_THRESHOLD NodeIDs): Lead asks architect for partition plan. Architect proposes partitions. Lead spawns spec-drafters (`subagent_type: "architect"`, `permissionMode: "acceptEdits"`, `maxTurns: 15`) with partition-scoped prompts. After all drafters complete, architect runs consistency review and reports to lead.
-- *Sequential Teams*: Spawn teammate `architect`, create task `Phase 1B: Draft specifications for {N} NodeIDs`. **Plan approval enabled** — add to prompt: `Present your spec design for lead review BEFORE writing final specs. Wait for approval.` Wait for `plan_approval_request`, review, respond with `plan_approval_response`. If `AUTONOMOUS_MODE = true`: auto-approve immediately. Log `[AUTO-APPROVED] Architect plan`.
-- *Subagent*: `Task(subagent_type="architect", description="Phase 1B specification drafting", prompt=<above> + "Present your spec design in your output for lead review.")`
-
-> **Note:** Plan approval (agent pauses for lead review) only works in Agent Teams mode via `permissionMode: plan`. In subagent mode, the architect presents its design in the output for post-hoc review. Spec-drafters (Path B) do NOT use plan approval — they follow the architect's partition briefing directly.
-
-### Quality Gate #2
-
-Present specs for batch approval:
-
-```markdown
-## Approval Gate #2: Specifications
-
-**Specs Drafted**: {count}
-| NodeID | File | Key VERIFY Criteria |
-|--------|------|---------------------|
-| ... | ... | ... |
-
-### Specialist Reports                    [only when SPECIALISTS_ENABLED non-empty]
-**Architect**: {specs align with component map, drift concerns, pattern consistency}
-**Test Advisor**: {spec testability assessment, recommended test types per NodeID}
-
-Review specs and approve to proceed to implementation?
-```
-
-**Autonomous Mode**: If `AUTONOMOUS_MODE = true`, present gate info for transparency, log `[AUTO-APPROVED] Gate #2`, and proceed immediately.
-If `AUTONOMOUS_MODE = false`: If rejected — re-run specs needing revision. If approved — pre-implementation commit, proceed.
-
-**Pre-Implementation Commit:**
-```bash
-git add knowzcode/
-git commit -m "KnowzCode: Specs approved for {WorkGroupID}"
-```
-
----
-
-## Phase 2A: Implementation
-
-**Agent**: `builder` | **Loop.md**: Section 3.3
-
-**Spawn prompt**:
-> You are the **builder** for WorkGroup `{wgid}`.
-> Read `agents/builder.md` for your full role definition.
->
-> **Goal**: {goal}
-> **Approved Change Set**: {NodeIDs}
-> **Specs**: {list of spec file paths from Phase 1B}
-> **Context files**: Read sections 1-2 and 3.3 of `knowzcode/knowzcode_loop.md` (skip other phases), `knowzcode/knowzcode_project.md`
-> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
->
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Conventions**: Update WorkGroup file with results (prefix entries with `KnowzCode:`). If blocked, report blocker and notify lead.
-> **TDD mandatory**: Write failing tests first, then implement, then refactor. Every NodeID must have tests.
-> **Blocker protocol**: If you hit a blocker, document it as a Blocker Report in the WorkGroup file (see loop.md Section 11 format) and report to the lead immediately instead of guessing.
-> **Deliverable**: All NodeIDs implemented with passing tests.
-
-**Dispatch**:
-- *Parallel Teams*: Multiple builders spawned at Stage 2, one per partition from the dependency map. Each builder gets its partition's NodeIDs and specs. Builders create per-NodeID subtasks for visibility. **Plan approval enabled** — add to prompt: `Present your implementation approach for lead review BEFORE writing code. Wait for approval.` If `AUTONOMOUS_MODE = true`: auto-approve `plan_approval_request` immediately. Log `[AUTO-APPROVED] Builder plan`.
-- *Sequential Teams*: Spawn teammate `builder`, create task `Phase 2A: Implement {N} NodeIDs with TDD`. **Plan approval enabled** — add to prompt: `Present your implementation approach for lead review BEFORE writing code. Wait for approval.` Wait for `plan_approval_request`, review, respond. If `AUTONOMOUS_MODE = true`: auto-approve immediately. Log `[AUTO-APPROVED] Builder plan`.
-- *Subagent*: `Task(subagent_type="builder", description="Phase 2A TDD implementation", mode="bypassPermissions", prompt=<above>)`
-
-### Phase 2A Output
-
-When complete, present implementation summary including files changed, tests written, and test results.
-
-### MCP Learning Capture (Optional)
-
-If MCP is configured and knowz-scribe is active, after implementation completes:
-- Create capture task: `TaskCreate("Scribe: Capture Phase 2A")` → `TaskUpdate(owner: "knowz-scribe")`
-- Send message to **knowz-scribe** with task ID: `"Capture Phase 2A: {wgid}. Your task: #{task-id}"` — the scribe reads implementation results from the WorkGroup file and captures patterns, workarounds, and performance optimizations to the `code` vault
-
----
-
-## Phase 2B: Completeness Audit
-
-**Agent**: `reviewer` | **Loop.md**: Section 3.4
-
-**Spawn prompt**:
-> You are the **reviewer** for WorkGroup `{wgid}`.
-> Read `agents/reviewer.md` for your full role definition.
->
-> **Goal**: {goal}
-> **Change Set**: {NodeIDs}
-> **Specs**: {list of spec file paths}
-> **Context files**: Read sections 1-2 and 3.4 of `knowzcode/knowzcode_loop.md` (skip other phases), `knowzcode/knowzcode_project.md`, `knowzcode/knowzcode_architecture.md`
-> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
->
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Conventions**: Update WorkGroup file with results (prefix entries with `KnowzCode:`). If blocked, report blocker and notify lead.
-> **This is a READ-ONLY audit.** Do not modify any source code or test files.
-> **Deliverable**: Audit report with ARC completion %, security posture, and gap list.
-
-**Dispatch**:
-- *Parallel Teams*: One reviewer per builder partition, spawned at Stage 2. Each reviewer gets its partition's NodeIDs and specs. Audit tasks use `addBlockedBy` per implementation task. Each reviewer uses structured gap report format (see `agents/reviewer.md`).
-- *Sequential Teams*: Spawn teammate `reviewer`, create task `Phase 2B: Completeness audit for {N} NodeIDs`, wait for completion.
-- *Subagent*: `Task(subagent_type="reviewer", description="Phase 2B completeness audit", prompt=<above>)`
-
-### Quality Gate #3
-
-Present audit results:
-
-```markdown
-## Approval Gate #3: Audit Results
-
-**ARC Completion**: {X}%
-**Security Posture**: {status}
-**Gaps Found**: {count}
-
-### Specialist Reports                    [only when SPECIALISTS_ENABLED non-empty]
-**Security Officer**: Findings: {N} | Critical: {N} | High: {N} | {details or [Pending]}
-**Architect**: Drift: {Yes/No} | Pattern Violations: {N} | {details}
-**Test Advisor**: TDD Compliance: {%} | Missing Edge Cases: {N} | Quality: {Good/Adequate/Poor} | {details or [Pending]}
-**Project Advisor**: New REFACTOR tasks: {N} | Ideas captured to vault: {N}
-
-**Recommendation**: {proceed / return to implementation}
-
-How would you like to proceed?
-```
-
-**Autonomous Mode**: If `AUTONOMOUS_MODE = true`:
-- **Safety check**: If any security finding rated HIGH or CRITICAL (from reviewer OR security-officer `[SECURITY-BLOCK]`) → **PAUSE** autonomous mode for this gate. Announce: `> **Autonomous Mode Paused** — HIGH/CRITICAL security finding requires manual review.`
-- **Safety check**: If ARC completion < 50% → **PAUSE** autonomous mode for this gate. Announce: `> **Autonomous Mode Paused** — ARC completion below 50% requires manual review.`
-- If safety checks pass and gaps found → log `[AUTO-APPROVED] Gate #3 — proceeding to gap loop`, auto-proceed to gap loop.
-- If safety checks pass and no gaps → log `[AUTO-APPROVED] Gate #3`, auto-proceed to Phase 3.
-
-If `AUTONOMOUS_MODE = false`: User decides — proceed / fix gaps / modify specs / cancel.
-
-### Gap Loop (when user chooses to fix gaps)
-
-**Parallel Teams mode** (per-partition, persistent agents — no respawning):
-1. Lead reads each reviewer's structured gap report from task summary
-2. Lead creates fix task and pre-assigns:
-   `TaskCreate("Fix gaps: NodeID-X", addBlockedBy: [audit-task-id])` → `TaskUpdate(owner: "builder-N")`
-3. Lead sends DM to builder with task ID and gap details:
-   `"**New Task**: #{fix-task-id} — Fix gaps: NodeID-X. {file path, VERIFY criterion, expected vs actual}"`
-4. Builder claims fix task, fixes gaps, re-runs tests, marks fix task complete
-5. Lead creates re-audit task and pre-assigns:
-   `TaskCreate("Re-audit: NodeID-X", addBlockedBy: [gap-fix-task-id])` → `TaskUpdate(owner: "reviewer-N")`
-6. Lead sends DM to reviewer: `"**New Task**: #{reaudit-task-id} — Re-audit: NodeID-X. {gap list}"`
-7. Each builder-reviewer pair repeats independently until clean — no cross-partition blocking
-8. All builders and reviewers stay alive throughout
-9. **3-iteration cap per partition**: If a partition exceeds 3 gap-fix iterations without resolution, **PAUSE** autonomous mode for that partition (even if `AUTONOMOUS_MODE = true`). Announce: `> **Autonomous Mode Paused** — Partition {N} failed 3 gap-fix iterations. Manual review required.`
-
-**Sequential Teams mode**: Spawn a NEW `builder` with the standard Phase 2A prompt plus gap fix context. Then re-run Phase 2B (spawn a new reviewer). Repeat until user approves at Gate #3.
-
-**Subagent mode**: Launch parallel `Task()` calls — one for gap fix (builder), then one for re-audit (reviewer). Repeat as needed.
-
-### MCP Learning Capture (Optional)
-
-If MCP is configured and knowz-scribe is active, after audit approval:
-- Create capture task: `TaskCreate("Scribe: Capture Phase 2B")` → `TaskUpdate(owner: "knowz-scribe")`
-- Send message to **knowz-scribe** with task ID: `"Capture Phase 2B: {wgid}. Your task: #{task-id}"` — the scribe reads audit results from the WorkGroup file and writes findings to the appropriate vault
-
----
-
-## Phase 3: Finalization
-
-**Agent**: `closer` | **Loop.md**: Section 3.5
-
-**Spawn prompt (Parallel Teams)**:
-> You are the **closer** for WorkGroup `{wgid}`.
-> Read `agents/closer.md` for your full role definition.
->
-> **Goal**: {goal}
-> **Change Set**: {NodeIDs}
-> **Specs**: {list of spec file paths}
-> **Context files**: Read sections 1-2, 3.5, 6, and 7 of `knowzcode/knowzcode_loop.md` (skip other phases), `knowzcode/knowzcode_tracker.md`, `knowzcode/knowzcode_project.md`, `knowzcode/knowzcode_architecture.md`, `knowzcode/knowzcode_log.md`
-> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
->
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Conventions**: Update WorkGroup file with results (prefix entries with `KnowzCode:`). If blocked, report blocker and notify lead.
-> **Vault writes**: Knowz-scribe is active. Create a capture task (`TaskCreate("Scribe: Capture Phase 3")` → `TaskUpdate(owner: "knowz-scribe")`), then send `"Capture Phase 3: {wgid}. Your task: #{task-id}"` to delegate learning capture and audit trail writes. Do NOT call `create_knowledge` directly.
-> **Deliverable**: Atomic finalization — update specs to FINAL, update tracker, write log entry, update architecture if needed, delegate learning capture to knowz-scribe, and create final commit.
-
-**Spawn prompt (Sequential Teams / Subagent)**:
-> You are the **closer** for WorkGroup `{wgid}`.
-> Read `agents/closer.md` for your full role definition.
->
-> **Goal**: {goal}
-> **Change Set**: {NodeIDs}
-> **Specs**: {list of spec file paths}
-> **Context files**: Read sections 1-2, 3.5, 6, and 7 of `knowzcode/knowzcode_loop.md` (skip other phases), `knowzcode/knowzcode_tracker.md`, `knowzcode/knowzcode_project.md`, `knowzcode/knowzcode_architecture.md`, `knowzcode/knowzcode_log.md`
-> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
->
-> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
-> **Conventions**: Update WorkGroup file with results (prefix entries with `KnowzCode:`). If blocked, report blocker and notify lead.
-> **Vault writes**: No knowz-scribe — you own all vault writes. Follow the Direct Write Fallback in `agents/closer.md`.
-> **Deliverable**: Atomic finalization — update specs to FINAL, update tracker, write log entry, update architecture if needed, write learnings to vaults, and create final commit.
-
-**Dispatch**:
-- *Parallel Teams*: Spawned at Stage 3 (`addBlockedBy`: last audit/re-audit task). Use the **Parallel Teams** spawn prompt. All other agents shut down before closer starts, except knowz-scout and knowz-scribe (stay alive for Phase 3 capture).
-- *Sequential Teams*: Spawn teammate `closer`, create task `Phase 3: Finalize WorkGroup {wgid}`, wait for completion. Use the **Sequential Teams / Subagent** spawn prompt.
-- *Subagent*: `Task(subagent_type="closer", description="Phase 3 finalization", prompt=<Sequential/Subagent spawn prompt above>)`
-
-### Phase 3 Output
-
-When complete, if MCP is configured and knowz-scribe is active:
-- The closer creates a capture task (`TaskCreate("Scribe: Capture Phase 3")` → `TaskUpdate(owner: "knowz-scribe")`) and sends a message with the task ID: `"Capture Phase 3: {wgid}. Your task: #{task-id}"`. The lead waits for the scribe's capture task to complete before shutdown.
-
-Update workgroup to "Closed" and report:
-
-```markdown
-## Workflow Complete
-
-**WorkGroupID**: {wgid}
-**Primary Goal**: {$ARGUMENTS}
-**Status**: VERIFIED and CLOSED
-
-- NodeIDs completed: {list}
-- Specs finalized: {count}
-- Tech debt scheduled: {count REFACTOR_ tasks}
-```
-
----
-
-## Cleanup
-
-### After Phase 3 Completes
-
-**Agent Teams Mode** (Parallel or Sequential):
-1. Shut down all active teammates. Wait for each to confirm shutdown.
-2. Once all teammates have shut down, clean up the team (delete the `kc-{wgid}` team).
-   No teammates or team resources should remain after the workflow ends.
-
-**Subagent Mode**: No cleanup needed — `Task()` calls are self-contained.
-
-### If User Cancels Mid-Workflow
-
-Follow the abandonment protocol from `knowzcode_loop.md` Section 12:
-
-1. **Revert uncommitted changes** — if implementation was in progress, revert source code changes (keep knowzcode files)
-2. **Update tracker** — set all affected NodeIDs back to their pre-WorkGroup status
-3. **Log abandonment** — create a log entry with type `WorkGroup-Abandoned` including the reason and phase at abandonment
-4. **Close WorkGroup file** — mark the WorkGroup as `Abandoned` with timestamp and reason
-5. **Preserve learnings** — if any useful patterns were discovered, capture them before closing
-6. **Team teardown** — (Agent Teams only) shut down all active teammates and delete the team
-7. **Parallel mode**: If cancelled mid-Stage-2, revert uncommitted code changes and mark WorkGroup abandoned
-
-The WorkGroup file remains in `knowzcode/workgroups/` for reference. It can be resumed later with `/kc:work` referencing the same goal.
-
----
-
-## Handling Failures
-
-- Phase 1A rejected: re-run analyst with feedback
-- Phase 1B rejected: re-run architect with specific issues (Parallel Teams: architect is already warm)
-- Phase 2A blocker encountered: present Blocker Report (per loop.md Section 11) to user with 5 recovery options: (1) modify spec, (2) change approach, (3) split WorkGroup, (4) accept partial with documented gap, (5) cancel WorkGroup
-- Phase 2B audit shows gaps: return to 2A with gap list (see Gap Loop above)
-- If >3 failures on same phase: PAUSE and ask user for direction (applies even when `AUTONOMOUS_MODE = true` — this is a safety exception)
-
-## KnowzCode: Prefix Enforcement
-
-Every todo in workgroup files MUST start with `KnowzCode:`. Pass this to all agents.
+---
+description: "Start a new KnowzCode development workflow with TDD, quality gates, and structured phases"
+argument-hint: "[feature_description]"
+---
+
+# Work on New Feature
+
+Start a new KnowzCode development workflow session.
+
+**Usage**: `/kc:work "feature description"`
+**Example**: `/kc:work "Build user authentication with JWT"`
+
+**Primary Goal**: $ARGUMENTS
+
+---
+
+## Step 0: Prerequisite Check
+
+Verify KnowzCode is initialized:
+1. Check if `knowzcode/` directory exists
+2. Check required files exist: `knowzcode_loop.md`, `knowzcode_tracker.md`, `knowzcode_project.md`, `knowzcode_architecture.md`
+
+If missing: inform user to run `/kc:init` first. STOP.
+
+## Step 1: Generate WorkGroup ID
+
+**Format**: `kc-{type}-{slug}-YYYYMMDD-HHMMSS`
+
+- `{type}`: feat, fix, refactor, or issue
+- `{slug}`: 2-4 word kebab-case from goal (remove common words: build, add, create, implement, the, a, with, for)
+- Truncate slug to max 25 characters
+
+## Step 2: Select Execution Mode
+
+Determine the execution mode using try-then-fallback:
+
+1. Note user preferences from `$ARGUMENTS`:
+   - `--sequential` → prefer Sequential Teams
+   - `--subagent` → force Subagent Delegation (skip team creation attempt)
+
+2. **If `--subagent` NOT specified**, attempt `TeamCreate(team_name="kc-{wgid}")`:
+   - **If TeamCreate succeeds** → Agent Teams is available. Choose mode:
+     - `--sequential` or Tier 2 → **Sequential Teams**: `**Execution Mode: Sequential Teams** — created team kc-{wgid}`
+     - Otherwise → **Parallel Teams** (default for Tier 3): `**Execution Mode: Parallel Teams** — created team kc-{wgid}`
+   - **If TeamCreate fails** (error, unrecognized tool, timeout) → **Subagent Delegation**: `**Execution Mode: Subagent Delegation** — Agent Teams not available, using Task() fallback`
+
+3. **If `--subagent` specified** → **Subagent Delegation** directly (no TeamCreate attempt):
+   - Announce: `**Execution Mode: Subagent Delegation** — per user request`
+
+For all Agent Teams modes (Sequential and Parallel):
+- You are the **team lead** in delegate mode — you coordinate phases, present quality gates, and manage the workflow. You NEVER write code, specs, or project files directly. All work is done by teammates. (Tip: the user can press Shift+Tab to system-enforce delegate mode.)
+- After completion or if the user cancels, shut down all active teammates and clean up the team (see Cleanup section)
+
+For Subagent Delegation:
+- For each phase, delegate via `Task()` with the parameters specified in phase sections below
+
+The user MUST see the execution mode announcement before any phase work begins. The phases, quality gates, and interactions are identical across all paths.
+
+> **Note:** Agent Teams is experimental and the API may change.
+
+## Step 2.4: Load Orchestration Config (Optional)
+
+If `knowzcode/knowzcode_orchestration.md` exists, parse its YAML blocks:
+
+1. `MAX_BUILDERS` = `max_builders` value (default: 5, clamp to 1-5)
+2. `SCOUT_MODE` = `scout_mode` value (default: "full")
+3. `DEFAULT_SPECIALISTS` = `default_specialists` value (default: [])
+4. `MCP_AGENTS_ENABLED` = `mcp_agents_enabled` value (default: true)
+5. `CODEBASE_SCANNER_ENABLED` = `codebase_scanner_enabled` value (default: true)
+6. `PARALLEL_SPEC_THRESHOLD` = `parallel_spec_threshold` value (default: 3, clamp to 2-10)
+
+Apply flag overrides (flags win over config):
+- `--max-builders=N` in `$ARGUMENTS` → override `MAX_BUILDERS`
+- `--no-scouts` in `$ARGUMENTS` → override `SCOUT_MODE = "none"`
+- `--no-mcp` in `$ARGUMENTS` → override `MCP_AGENTS_ENABLED = false`
+- `--no-scanners` in `$ARGUMENTS` → override `CODEBASE_SCANNER_ENABLED = false`
+- `--no-parallel-specs` in `$ARGUMENTS` → override `PARALLEL_SPEC_THRESHOLD = 999` (effectively disabled)
+
+If the file doesn't exist, use hardcoded defaults (current behavior).
+
+## Step 2.5: Autonomous Mode Detection
+
+Set `AUTONOMOUS_MODE = true` if ANY of these match:
+
+a. **Flags**: `$ARGUMENTS` contains `--autonomous` or `--auto`
+
+b. **Natural language** (case-insensitive match in `$ARGUMENTS` OR the user's preceding conversation message):
+   - Approval intent: "approve all", "pre-approve", "preapprove", "auto-approve"
+   - Mode intent: "autonomous mode", "autonomous", "unattended", "hands off", "hands-off"
+   - Proceed intent: "don't stop to ask", "don't ask me", "no approval needed", "just run through", "run it all", "run straight through", "proceed without asking", "skip the gates", "go all the way through"
+   - Delegation intent: "I trust your judgement", "use your best judgement", "defer to your judgement", "you decide"
+
+c. **Contextual** — if the user's message conveys clear intent for the lead to operate without stopping (even if none of the exact phrases above match), interpret that as autonomous mode. The spirit of the instruction matters more than exact phrasing.
+
+Default: `AUTONOMOUS_MODE = false`
+
+If `AUTONOMOUS_MODE = true`, announce after the execution mode announcement:
+> **Autonomous Mode: ACTIVE** — Gates presented for transparency but auto-approved.
+> Safety exceptions still pause: critical blockers, HIGH/CRITICAL security findings, >3 same-phase failures, complex architecture discrepancies, >3 gap-fix iterations per partition.
+
+## Step 2.6: Specialist Detection
+
+Set `SPECIALISTS_ENABLED = []` (empty list).
+
+If `DEFAULT_SPECIALISTS` is non-empty (from Step 2.4), initialize:
+`SPECIALISTS_ENABLED = DEFAULT_SPECIALISTS`
+
+Determine which specialists to activate (flags and natural language add to or override the baseline):
+- `--specialists` → enable all 3: `[security-officer, test-advisor, project-advisor]`
+- `--specialists=csv` → enable specific subset (comma-separated, e.g., `--specialists=security,test`):
+  - `security` → `security-officer`
+  - `test` → `test-advisor`
+  - `project` → `project-advisor`
+- `--no-specialists` → explicit opt-out, `SPECIALISTS_ENABLED = []`
+
+**Natural language detection** (case-insensitive match in `$ARGUMENTS` OR the user's preceding conversation message):
+- All specialists: "with specialists", "with officers", "full specialist panel"
+- security-officer: "security review", "threat model", "vulnerability scan", "pentest"
+- test-advisor: "test quality", "TDD enforcement", "test coverage", "test rigor"
+- project-advisor: "backlog", "future work", "brainstorm", "ideas"
+
+**Mode constraints:**
+- Tier 3 Parallel Teams: Full support (Group C)
+- Tier 3 Subagent Delegation: Supported via parallel `Task()` calls
+- Sequential Teams / Tier 2: Not supported — if specialists were detected, announce: `> **Specialists: SKIPPED** — not supported in {Sequential Teams / Tier 2} mode.`
+
+Default: `SPECIALISTS_ENABLED = []` (specialists are opt-in).
+
+If `SPECIALISTS_ENABLED` is non-empty, announce after the autonomous mode announcement (or after the execution mode announcement if autonomous is not active):
+> **Specialists: ACTIVE** — {comma-separated list of enabled specialists}
+
+## Step 3: Load Context Files (ONCE)
+
+Read these files ONCE (do NOT re-read between phases):
+- `knowzcode/knowzcode_loop.md`
+- `knowzcode/knowzcode_tracker.md`
+- `knowzcode/knowzcode_project.md`
+- `knowzcode/knowzcode_architecture.md`
+
+## Step 3.5: Pull Team Standards (MCP — Optional)
+
+If MCP is configured and enterprise compliance is enabled:
+1. Check `knowzcode/enterprise/compliance_manifest.md` for `mcp_compliance_enabled: true`
+2. If enabled: Read `knowzcode/knowzcode_vaults.md` to find vault matching type "enterprise", then `ask_question({resolved_enterprise_vault_id}, "team standards for {project_type}")`
+3. Merge returned standards into WorkGroup context for quality gate criteria
+
+If MCP is not configured or enterprise is not enabled, skip this step.
+
+## Step 4: Create WorkGroup File
+
+Create `knowzcode/workgroups/{WorkGroupID}.md`:
+```markdown
+# WorkGroup: {WorkGroupID}
+
+**Primary Goal**: {$ARGUMENTS}
+**Created**: {timestamp}
+**Status**: Active
+**Current Phase**: 1A - Impact Analysis
+**Autonomous Mode**: Active/Inactive
+
+## Change Set
+(Populated after Phase 1A)
+
+## Todos
+- KnowzCode: Initialize WorkGroup
+- KnowzCode: Complete Phase 1A impact analysis
+
+## Phase History
+| Phase | Status | Timestamp |
+|-------|--------|-----------|
+| 1A | In Progress | {timestamp} |
+```
+
+## Step 5: Input Classification
+
+**Question indicators** (suggest `/kc:plan` instead): starts with is/does/how/why/what/should, contains `?`, phrased as inquiry.
+
+**Implementation indicators** (proceed): starts with build/add/create/implement/fix/refactor, action-oriented verbs.
+
+If ambiguous, proceed with implementation.
+
+## Step 5.5: Complexity Classification
+
+Assess the goal against the codebase to determine the appropriate workflow tier.
+
+### Tier 1: Micro → redirect to `/kc:fix`
+- Single file, <50 lines, no ripple effects
+
+### Tier 2: Light (2-phase workflow)
+
+> **Note:** Light mode does not use orchestration config — single builder, no scouts, no specialists.
+
+ALL must be true:
+- ≤3 files touched
+- Single NodeID (1 new capability)
+- No architectural changes
+- No security-sensitive components (auth, payments, PII)
+- No external API integrations
+- Estimated <200 lines of change
+
+### Tier 3: Full (5-phase workflow)
+ANY triggers full:
+- >3 files or >1 NodeID
+- Architectural impact
+- Security-sensitive scope
+- External integrations
+- User explicitly requests: `--tier full`
+
+**Announce the detected tier to the user.** User can override:
+- "use full" or `--tier full` → Tier 3
+- "use light" or `--tier light` → Tier 2
+
+If `$ARGUMENTS` contains `--tier light`, force Tier 2. If `--tier full`, force Tier 3.
+
+---
+
+## Tier 2: Light Workflow (2-phase fast path)
+
+When Tier 2 is selected, execute this streamlined workflow instead of the 5-phase Tier 3 below.
+
+### Light Phase 1 (Inline — lead does this, no agent)
+
+1. Quick impact scan: grep for related files, check existing specs
+2. Propose a Change Set (typically 1 NodeID)
+3. Draft a lightweight spec (or reference existing spec if found) — use the 4-section format from `knowzcode_loop.md` section 3.2. Minimum: 1 Rule, 1 Interface, 2 `VERIFY:` statements.
+4. Present combined Change Set + Spec for approval:
+
+```markdown
+## Light Mode: Change Set + Spec Approval
+
+**WorkGroupID**: {wgid}
+**Tier**: 2 (Light)
+**NodeID**: {NodeID} — {description}
+**Affected Files**: {list}
+
+**Spec Summary**:
+- Rules: {key decisions}
+- Interfaces: {public contracts}
+- VERIFY: {criteria list}
+
+Approve Change Set and spec to proceed to implementation?
+```
+
+5. **Autonomous Mode**: If `AUTONOMOUS_MODE = true`, log `[AUTO-APPROVED] Light mode gate` and proceed directly to implementation.
+   If `AUTONOMOUS_MODE = false`: If rejected — adjust based on feedback and re-present. If approved:
+   - Update `knowzcode_tracker.md` with NodeID status `[WIP]`
+   - Pre-implementation commit: `git add knowzcode/ && git commit -m "KnowzCode: Light spec approved for {wgid}"`
+
+### Light Phase 2A: Implementation (Builder agent)
+
+Spawn the builder using the standard Phase 2A prompt below (same for both tiers).
+
+The builder self-verifies against spec VERIFY criteria — no separate audit phase.
+
+### Light Phase 3 (Inline — lead does this, no agent)
+
+After builder completes successfully:
+1. Update spec to As-Built status
+2. Update `knowzcode_tracker.md`: NodeID status `[WIP]` → `[VERIFIED]`
+3. Write a brief log entry to `knowzcode_log.md`:
+   ```markdown
+   ---
+   **Type:** ARC-Completion
+   **Timestamp:** [timestamp]
+   **WorkGroupID:** [ID]
+   **NodeID(s):** [list]
+   **Logged By:** AI-Agent
+   **Details:** Light mode (Tier 2). {brief summary of implementation}.
+   ---
+   ```
+4. Final commit: `git add knowzcode/ <changed files> && git commit -m "feat: {goal} (WorkGroup {wgid})"`
+5. Report completion.
+6. **Progress capture** (if MCP is configured): Read `knowzcode/knowzcode_vaults.md`, resolve vault IDs. Write a brief scope-and-outcome learning to the ecosystem vault via `create_knowledge`. Check for duplicates first via `search_knowledge`.
+
+**DONE** — 3 agents skipped (analyst, architect, reviewer, closer).
+
+---
+
+## Tier 3: Full Workflow (5-phase)
+
+The standard 5-phase workflow. Used when complexity warrants full analysis, specification, audit, and finalization.
+
+Tier 3 supports three execution modes (determined in Step 2):
+- **Parallel Teams** (default) — Stage 0-3 orchestration with concurrent agents
+- **Sequential Teams** (`--sequential`) — one agent per phase, spawned and shut down sequentially
+- **Subagent Delegation** — Task() calls, no persistent agents
+
+## Step 6: Spec Detection (Optional Optimization)
+
+Check for existing specs covering this work:
+1. Extract key terms from goal
+2. Search `knowzcode/specs/*.md` for matching specs
+3. If comprehensive matching specs found, offer:
+   - **A) Quick Path** — skip discovery, use existing specs
+   - **B) Validation Path** (recommended) — quick check specs match codebase
+   - **C) Full Workflow** — complete Phase 1A discovery
+
+If no matches found, proceed to Phase 1A.
+
+### Refactor Task Check
+
+Scan `knowzcode/knowzcode_tracker.md` for outstanding `REFACTOR_` tasks that overlap with the current goal's scope. If found, mention them to the user during Phase 1A so the analyst can factor them into the Change Set.
+
+---
+
+## Parallel Teams Orchestration (Tier 3 Default)
+
+When Parallel Teams mode is active, follow these 4 stages instead of spawning one agent per phase sequentially. The same phase spawn prompts (defined in the Phase Reference sections below) are reused — what changes is WHEN agents are spawned and HOW MANY run concurrently.
+
+### Stage 0: Team Creation + Parallel Discovery
+
+1. Create team `kc-{wgid}`
+2. Read knowzcode context files (lead does initial load for spawn prompts)
+3. **MCP Probe** — determine vault availability BEFORE spawning:
+   a. Read `knowzcode/knowzcode_vaults.md` — partition entries into CONFIGURED (non-empty ID) and UNCREATED (empty ID)
+   b. Call `list_vaults(includeStats=true)` **always** — regardless of whether any IDs exist in the file
+   c. If `list_vaults()` fails:
+      - Check if `knowzcode/knowzcode_vaults.md` has any CONFIGURED entries (non-empty ID)
+      - **If CONFIGURED entries exist**: Set `MCP_ACTIVE = true`, `VAULTS_CONFIGURED = true` — vault agents will verify connectivity independently via their Startup Verification. Announce `**MCP Status: Lead probe failed — delegating verification to vault agents**`. Proceed to Step 4.
+      - **If no CONFIGURED entries** (all empty IDs or no file): Set `MCP_ACTIVE = false`, announce `**MCP Status: Not connected**`, skip Group B spawn
+   d. If `list_vaults()` succeeds AND UNCREATED list is non-empty → present the **Vault Creation Prompt**:
+
+      ```markdown
+      ## Vault Setup
+
+      Your Knowz API key is valid and MCP is connected, but {N} default vault(s) haven't been created yet.
+      Creating vaults enables knowledge capture throughout the workflow:
+
+      | Vault | Type | Description | Written During |
+      |-------|------|-------------|----------------|
+      ```
+
+      Build table rows dynamically from the UNCREATED entries only. For each uncreated vault, derive the "Written During" column from its Write Conditions field in `knowzcode_vaults.md`. Example rows:
+      - `| Code Patterns | code | Learnings, gotchas, and architecture insights from the codebase | Phase 2A (implementation patterns), Phase 3 (workarounds, performance) |`
+      - `| Ecosystem Knowledge | ecosystem | Business rules, conventions, decisions, and cross-system details | Phase 1A (scope decisions), Phase 2B (security, quality), Phase 3 (conventions) |`
+      - `| Finalizations | finalizations | Final summaries documenting complete execution and outcomes | Phase 3 (completion record) |`
+
+      Then present options:
+      ```
+      Options:
+        **A) Create all {N} vaults** (recommended)
+        **B) Select which to create**
+        **C) Skip** — proceed without vaults (can create later with `/kc:connect-mcp --configure-vaults`)
+      ```
+
+   e. Handle user selection:
+      - **A**: For each UNCREATED entry, call MCP `create_vault(name, description)`. If `create_vault` is not available, fall back to matching by name against `list_vaults()` results. Update `knowzcode_vaults.md`: fill the ID field with the server-returned vault ID and change the H3 heading from `(not created)` to the vault ID. If creation fails for some vaults, update only successful ones, report failures, and let user decide.
+      - **B**: Ask which vaults to create, then create only selected ones using the same process as A.
+      - **C**: Log `"Vault creation skipped — knowledge capture disabled."` Continue.
+   f. After resolution, set:
+      - `MCP_ACTIVE = true` (MCP works regardless of vault creation outcome)
+      - `VAULTS_CONFIGURED = true` if at least 1 vault now has a valid ID, else `false`
+      - Announce: `**MCP Status: Connected — N vault(s) available**` or `**MCP Status: Connected — no vaults configured (knowledge capture disabled)**`
+4. **Spawn Group A**:
+   Create tasks first, pre-assign, then spawn with task IDs:
+   - If `SCOUT_MODE = "full"` (default): spawn 3 context scouts (specs, workgroups, backlog) + analyst + architect (5 agents):
+     - `TaskCreate("Scout: specs context")` → `TaskUpdate(owner: "context-scout-specs")`
+     - `TaskCreate("Scout: workgroups context")` → `TaskUpdate(owner: "context-scout-workgroups")`
+     - `TaskCreate("Scout: backlog context")` → `TaskUpdate(owner: "context-scout-backlog")`
+   - If `SCOUT_MODE = "minimal"`: spawn 1 context-scout (combined scan) + analyst + architect (3 agents):
+     - `TaskCreate("Scout: combined context")` → `TaskUpdate(owner: "context-scout")`
+   - If `SCOUT_MODE = "none"`: spawn analyst + architect only (2 agents). Analyst and architect scan the codebase independently without pre-loaded scout context.
+   - Always:
+     - `TaskCreate("Phase 1A: Impact analysis for {goal}")` → `TaskUpdate(owner: "analyst")`
+     - `TaskCreate("Pre-load architecture context and speculative research")` → `TaskUpdate(owner: "architect")`
+   - If `CODEBASE_SCANNER_ENABLED = true` (default):
+     - Derive two search focuses from the goal:
+       - **Scanner-Direct**: source code search — grep for goal keywords, read affected code paths
+       - **Scanner-Tests**: test discovery — search test directories for tests covering the goal area
+     - `TaskCreate("Scanner: direct codebase scan for {goal}")` → `TaskUpdate(owner: "scanner-direct")`
+     - `TaskCreate("Scanner: test coverage scan for {goal}")` → `TaskUpdate(owner: "scanner-tests")`
+   Spawn all Group A agents with their `{task-id}` in the spawn prompt (use spawn prompts from Phase Prompt Reference below).
+5. **Spawn Group B** (MCP agents — same turn as Group A): If `VAULTS_CONFIGURED = true` AND `MCP_AGENTS_ENABLED = true`:
+   Create tasks first, pre-assign, then spawn with task IDs:
+   - `TaskCreate("Knowz-scout: vault queries")` → `TaskUpdate(owner: "knowz-scout")`
+   - `TaskCreate("Knowz-scribe: listen")` → `TaskUpdate(owner: "knowz-scribe")`
+   Spawn both agents with their `{task-id}` in the spawn prompt.
+   If `VAULTS_CONFIGURED = false` or `MCP_AGENTS_ENABLED = false`, skip Group B and log: `Vault agents skipped — no vaults configured` or `Vault agents skipped — MCP agents disabled in orchestration config.`
+6. **Spawn Group C** (specialist agents — same turn as Groups A and B): If `SPECIALISTS_ENABLED` is non-empty:
+   Create tasks first, pre-assign, then spawn with task IDs:
+   - If `security-officer` in list: `TaskCreate("Security officer: initial threat scan")` → `TaskUpdate(owner: "security-officer")`
+   - If `test-advisor` in list: `TaskCreate("Test advisor: coverage baseline")` → `TaskUpdate(owner: "test-advisor")`
+   - If `project-advisor` in list: `TaskCreate("Project advisor: backlog context")` → `TaskUpdate(owner: "project-advisor")`
+   Spawn each enabled specialist with its `{task-id}` in the spawn prompt (use spawn prompts from Specialist Spawn Prompts section below).
+   If `SPECIALISTS_ENABLED` is empty, skip Group C.
+7. **Roster confirmation** — lead lists every spawned agent by name to the user. Include scanners and Group C specialists if active. If `VAULTS_CONFIGURED` was true but knowz-scout or knowz-scribe is missing from the roster, STOP and re-spawn the missing agent(s) before continuing.
+8. All spawned agents work immediately in parallel (context scouts are cheap Sonnet read-only agents; scanners are lightweight general-purpose agents; knowz-scribe is a cheap Haiku agent; specialists are Sonnet read-only agents). Agent count depends on orchestration config: 2-12 agents at Stage 0.
+9. Scouts broadcast findings → analyst and architect consume as messages. Specialists work independently on their Stage 0 tasks.
+
+**Key**: The analyst does NOT wait for scouts, scanners, or specialists to finish. It starts scanning the codebase immediately. Scout and scanner findings arrive as messages and enrich the analyst's work as they arrive. The analyst also streams `[PRELIMINARY]` NodeID findings to the architect as it discovers them (see Preliminary Findings Protocol). Specialist findings are consumed by the lead at gates.
+
+### Stage 1: Analysis + Specification
+
+1. Analyst completes Change Set (includes dependency map — see `agents/analyst.md`)
+2. Lead reads analyst's task summary
+3. Shut down scanners (scanner-direct, scanner-tests) if they were spawned — no longer needed after analysis
+3. **Specialist Change Set reviews** (if `SPECIALISTS_ENABLED` non-empty): Create review tasks blocked on analysis:
+   - If `security-officer` active: `TaskCreate("Security officer: Change Set review", addBlockedBy: [analysis-task-id])` → `TaskUpdate(owner: "security-officer")`. DM security-officer: `"**New Task**: #{task-id} — Review Change Set for security risk. Rate each NodeID."`
+   - If `test-advisor` active: `TaskCreate("Test advisor: Change Set test strategy", addBlockedBy: [analysis-task-id])` → `TaskUpdate(owner: "test-advisor")`. DM test-advisor: `"**New Task**: #{task-id} — Recommend test types per NodeID."`
+4. Lead presents **Quality Gate #1** to user:
+   - Change Set with NodeIDs, descriptions, affected files
+   - Dependency map showing which NodeIDs can be implemented in parallel
+   - Risk assessment
+   - Specialist Reports (if active — see gate template below)
+5. User approves (or rejects → re-run analyst with feedback)
+6. Lead sends DM to architect with the approved Change Set
+7. **Spec Drafting** — choose path based on NodeID count and `PARALLEL_SPEC_THRESHOLD`:
+
+   **Path A: Standard (fewer than PARALLEL_SPEC_THRESHOLD NodeIDs)**
+   - Lead creates spec-drafting tasks for architect (1 task per NodeID, `addBlockedBy: [analysis-task-id]`):
+     - `TaskCreate("Spec: NodeID-X")` → `TaskUpdate(taskId, owner: "architect")`
+     - DM architect with task IDs: `"**New Tasks**: #{id-1} Spec: NodeID-A, #{id-2} Spec: NodeID-B. Approved Change Set: {summary}"`
+   - Architect is already warm (pre-loaded + speculative research during Stage 0) → specs drafted FAST
+   - If Gate #1 rejected: shut down architect, re-run analyst with feedback, re-spawn architect after
+
+   **Path B: Parallel Spec Drafting (PARALLEL_SPEC_THRESHOLD or more NodeIDs)**
+   - Lead DMs architect the full approved Change Set and asks for a partition plan (see `agents/architect.md` — Parallel Spec Coordination)
+   - Architect proposes NodeID partitions (1-2 NodeIDs each, max 3 partitions, respecting same-spec and interface constraints)
+   - Lead spawns spec-drafter agents — one per partition:
+     - Spec-drafters use the `architect` agent definition with a scoped spawn prompt
+     - Each drafter gets: its NodeID partition, architect's research findings, cross-NodeID interface constraints, consolidation instructions
+     - `TaskCreate("Spec draft: NodeID-A, NodeID-B")` → `TaskUpdate(owner: "spec-drafter-1")`
+     - Max 3 spec-drafters: `ceil(NodeID_count / 2)`, capped at 3
+   - Spec-drafters draft specs in parallel
+   - After all spec-drafters complete: architect runs consistency review (cross-spec alignment, naming, VERIFY coverage)
+   - Shut down spec-drafters after consistency review
+   - If Gate #1 rejected: shut down architect and any spec-drafters, re-run analyst with feedback, re-spawn architect after
+
+8. Architect completes specs (Path A) or architect completes consistency review (Path B)
+9. **Test-advisor spec review** (if `test-advisor` in `SPECIALISTS_ENABLED`): After specs drafted, create spec testability review task:
+   - `TaskCreate("Test advisor: spec testability review", addBlockedBy: [spec-task-id])` → `TaskUpdate(owner: "test-advisor")`
+   - DM test-advisor: `"**New Task**: #{task-id} — Review specs for testability. Check VERIFY criteria are automatable."`
+10. Lead presents **Quality Gate #2** to user:
+    - Spec summaries with VERIFY criteria
+    - Specialist Reports (if active — see gate template below)
+11. User approves (or rejects → architect revises)
+12. Pre-implementation commit: `git add knowzcode/ && git commit -m "KnowzCode: Specs approved for {wgid}"`
+13. Shut down context-scouts (no longer needed after specs approved). Keep knowz-scout alive for vault queries during implementation.
+14. Keep analyst alive briefly (available for scope questions during early implementation)
+15. Keep architect alive through Stage 2 (consultative role — spec clarifications for builders, no code or spec edits)
+
+### Stage 2: Parallel Implementation + Incremental Review
+
+1. Lead examines dependency map from analyst:
+   - Group NodeIDs into independent partitions (no shared files between groups)
+   - Determine builder count: 1 builder per independent group, max `MAX_BUILDERS` (default 5, configurable in `knowzcode_orchestration.md`)
+
+2. Create builder tasks and spawn:
+   - `TaskCreate("Implement NodeIDs [A, B]", addBlockedBy: [spec-task-id])` → `TaskUpdate(owner: "builder-1")`
+   - `TaskCreate("Implement NodeIDs [C]", addBlockedBy: [spec-task-id])` → `TaskUpdate(owner: "builder-2")`
+   - `TaskCreate("Implement NodeIDs [D, E]", addBlockedBy: [spec-task-id])` → `TaskUpdate(owner: "builder-3")`
+   Spawn each builder with its `{task-id}` in the spawn prompt.
+   Each builder gets its partition's specs + affected files list.
+   **NO TWO BUILDERS TOUCH THE SAME FILE**
+
+3. Notify architect of builder spawn:
+   - Lead DMs architect: `"Builders spawned for Stage 2. Introduce yourself to: {builder-1, builder-2, ...}"`
+   - Architect sends brief availability message to each builder (see `agents/architect.md` — Proactive Availability)
+
+4. Each builder creates subtasks per NodeID in the task list:
+   - `"TDD: NodeID-A tests"` → `"TDD: NodeID-A implementation"` → `"TDD: NodeID-A verify"`
+   - Builder works through subtasks, marks each complete with summary
+
+5. Create reviewer tasks and spawn — one per builder partition:
+   - `TaskCreate("Audit partition 1: NodeIDs [A, B]", addBlockedBy: [implement-A-task-id])` → `TaskUpdate(owner: "reviewer-1")`
+   - `TaskCreate("Audit partition 2: NodeIDs [C]", addBlockedBy: [implement-C-task-id])` → `TaskUpdate(owner: "reviewer-2")`
+   - `TaskCreate("Audit partition 3: NodeIDs [D, E]", addBlockedBy: [implement-D-task-id])` → `TaskUpdate(owner: "reviewer-3")`
+   Spawn each reviewer with its `{task-id}` + partition's specs + VERIFY criteria.
+   Reviewer stays idle until its paired builder marks first NodeID implementation complete.
+   Each reviewer audits incrementally within its partition.
+
+6. **Specialist implementation reviews** (if `SPECIALISTS_ENABLED` non-empty): Create specialist review tasks alongside reviewer audit tasks, same `addBlockedBy`:
+   - If `security-officer` active — one task per partition (runs parallel to reviewer):
+     `TaskCreate("Security officer: review partition {N}", addBlockedBy: [implement-X-task-id])` → `TaskUpdate(owner: "security-officer")`
+     DM security-officer: `"**New Task**: #{task-id} — Vulnerability scan for partition {N}. NodeIDs: {list}."`
+   - If `test-advisor` active — one task per partition:
+     `TaskCreate("Test advisor: review partition {N} tests", addBlockedBy: [implement-X-task-id])` → `TaskUpdate(owner: "test-advisor")`
+     DM test-advisor: `"**New Task**: #{task-id} — Test quality review for partition {N}. NodeIDs: {list}."`
+   - If `project-advisor` active — one observation task (not per-partition):
+     `TaskCreate("Project advisor: observe implementation")` → `TaskUpdate(owner: "project-advisor")`
+     DM project-advisor: `"**New Task**: #{task-id} — Observe builder progress, note patterns and ideas. Deliver backlog proposals before gap loop."`
+   **Gate #3 is NOT blocked by specialists.** If a specialist hasn't finished, gate shows `[Pending: {specialist}]`. Lead proceeds.
+   **Project-advisor early shutdown**: After project-advisor delivers backlog proposals, shut it down (before the gap loop begins).
+
+7. Gap flow (per-partition, parallel — persistent agents, DM messaging):
+   a. Each reviewer marks audit task complete with structured gap report in summary
+   b. Lead creates fix task and pre-assigns:
+      `TaskCreate("Fix gaps: NodeID-A", addBlockedBy: [audit-task-id])` → `TaskUpdate(owner: "builder-N")`
+   c. Lead sends DM to builder with task ID and gap details:
+      > **New Task**: #{fix-task-id} — Fix gaps: NodeID-A
+      > **Gaps**: {file path, VERIFY criterion not met, expected vs actual}
+      > Fix each gap, re-run affected tests, report completion.
+   d. Builder claims fix task, fixes gaps, re-runs tests, marks fix task complete
+   e. Lead creates re-audit task and pre-assigns:
+      `TaskCreate("Re-audit: NodeID-A", addBlockedBy: [gap-fix-task-id])` → `TaskUpdate(owner: "reviewer-N")`
+   f. Lead sends DM to reviewer: `"**New Task**: #{reaudit-task-id} — Re-audit: NodeID-A. {gap list}"`
+   g. Each builder-reviewer pair repeats independently until clean — no cross-partition blocking
+   — All builders and reviewers stay alive through the entire gap loop (no respawning)
+
+8. Enterprise compliance (if enabled):
+   - Lead creates parallel compliance task for each reviewer (scoped to their partition)
+   - Reviewer checks compliance requirements from knowz-scout findings
+   - Runs alongside ARC audits
+
+9. Inter-agent communication during Stage 2:
+   - builder → architect: Spec clarification requests (direct messages)
+   - architect → builder: Design guidance and spec intent responses (direct messages)
+   - builder ↔ builder: Dependency coordination (direct messages — "I changed the User interface, FYI")
+   - builder → reviewer (same partition): Implementation complete notifications (via task system)
+   - reviewer → lead: Gap reports per partition (structured format via task summaries)
+   - lead → builder: Fix tasks (via task creation + DM)
+   - lead → reviewer: Re-audit requests (via task creation + DM)
+   - security-officer → builder-N: Security guidance for sensitive partitions (max 2 DMs per builder)
+   - test-advisor → builder-N: Test improvement feedback (max 2 DMs per builder)
+   - security-officer ↔ test-advisor: Cross-cutting test gaps in security paths (max 2 inter-specialist DMs)
+   - project-advisor → knowz-scribe: Idea captures for vault storage
+   - project-advisor → lead: Backlog proposals (before gap loop)
+
+10. After all NodeIDs implemented + audited across all partitions:
+    - Lead consolidates audit results from all reviewers
+    - Lead consolidates specialist reports (if `SPECIALISTS_ENABLED` non-empty — include even if some specialist tasks are still pending, noting `[Pending: {specialist}]`)
+    - Lead presents **Quality Gate #3**:
+      - Per-NodeID ARC completion % (from each partition's reviewer)
+      - Combined security posture
+      - Combined integration health
+      - Enterprise compliance (if applicable)
+      - Specialist Reports (if active — see gate template below)
+    - User decides: proceed / fix gaps / modify specs / cancel
+
+11. Shut down analyst, architect, all builders, and all reviewers
+
+### Stage 3: Finalization
+
+1. Shut down remaining specialists (security-officer, test-advisor) if still active. Project-advisor should already be shut down from mid-Stage 2.
+2. `TaskCreate("Phase 3: Finalize {wgid}", addBlockedBy: [last-audit-task-id])` → `TaskUpdate(owner: "closer")`
+   Spawn `closer` with `{task-id}` in spawn prompt.
+3. Closer tasks (can be parallel subtasks):
+   - Update all specs to FINAL as-built
+   - Update `knowzcode_tracker.md`: all NodeIDs `[WIP]` → `[VERIFIED]`
+   - Write ARC-Completion log entry
+   - Review architecture docs for discrepancies
+   - Schedule REFACTOR tasks for tech debt
+   - Create capture task for knowz-scribe (if active): `TaskCreate("Scribe: Capture Phase 3")` → `TaskUpdate(owner: "knowz-scribe")`, then send DM with task ID: `"Capture Phase 3: {wgid}. Your task: #{task-id}"`. Knowz-scout remains available for vault queries during finalization.
+   - Create final atomic commit
+4. Lead presents completion summary
+5. **Wait for scribe Phase 3 capture** (if knowz-scribe is active):
+   - Check scribe capture task via `TaskGet(task-id)` — wait until status is `completed`
+   - Also wait for scribe's Phase 3 confirmation DM
+   - **Timeout**: If >2 minutes after closer completes and scribe task still not complete → DM scribe: `"Status check: Phase 3 capture for {wgid}?"`
+   - **Hard timeout**: If another minute passes with no completion → proceed with shutdown and log `WARNING: Scribe Phase 3 capture did not complete for {wgid}. Vault writes may be incomplete.`
+6. Shutdown order: knowz-scout, knowz-scribe, closer, remaining agents
+7. Delete team
+
+### WorkGroup File Format (Parallel Mode)
+
+In Parallel Teams mode, the WorkGroup file uses per-NodeID phase tracking instead of a single `Current Phase`:
+
+```markdown
+## Change Set
+| NodeID | Phase | Builder | Status | Timestamp |
+|--------|-------|---------|--------|-----------|
+| Authentication | 2A | builder-1 | Implementing | ... |
+| UserProfile | 2B | builder-1 | Under review | ... |
+| LIB_DateFormat | 2A | builder-2 | Tests passing | ... |
+
+## Autonomous Mode
+Active/Inactive
+
+## Current Stage
+Stage 2: Parallel Implementation + Incremental Review
+```
+
+### Task Dependency Graph
+
+When creating tasks, model the dependency chain with `addBlockedBy` and pre-assign with `owner`:
+
+| Task | Blocked By | Owner |
+|------|-----------|-------|
+| Scout: specs context | (none) | context-scout-specs |
+| Scout: workgroups context | (none) | context-scout-workgroups |
+| Scout: backlog context | (none) | context-scout-backlog |
+| Knowz-scout: vault queries | (none — persistent) | knowz-scout |
+| Knowz-scribe: listen | (none — persistent) | knowz-scribe |
+| Scanner: direct codebase scan | (none) | scanner-direct |
+| Scanner: test coverage scan | (none) | scanner-tests |
+| Phase 1A analysis | (none — scouts + scanners enrich via broadcast) | analyst |
+| Architect pre-load + speculative research | (none — receives [PRELIMINARY] DMs from analyst) | architect |
+| Security officer: initial threat scan | (none — Group C) | security-officer |
+| Test advisor: coverage baseline | (none — Group C) | test-advisor |
+| Project advisor: backlog context | (none — Group C) | project-advisor |
+| Security officer: Change Set review | Phase 1A analysis | security-officer |
+| Test advisor: Change Set test strategy | Phase 1A analysis | test-advisor |
+| Spec: NodeID-X | Phase 1A (gate approval) | architect (Path A) or spec-drafter-N (Path B) |
+| Spec consistency review | All spec drafts complete (Path B only) | architect |
+| Test advisor: spec testability review | Spec: NodeID-X | test-advisor |
+| Implement: NodeID-X | Spec: NodeID-X | builder-N |
+| Audit: NodeID-X | Implement: NodeID-X | reviewer-N |
+| Security officer: review partition N | Implement: NodeID-X | security-officer |
+| Test advisor: review partition N tests | Implement: NodeID-X | test-advisor |
+| Project advisor: observe implementation | (none) | project-advisor |
+| Fix gaps: NodeID-X round N | Audit: NodeID-X (or re-audit N-1) | builder-N |
+| Re-audit: NodeID-X round N | Fix gaps round N | reviewer-N |
+| Phase 3 finalization | All audits approved | closer |
+| Scribe: Capture Phase 1A | Phase 1A (gate approval) | knowz-scribe |
+| Scribe: Capture Phase 2A | Implement: NodeID-X | knowz-scribe |
+| Scribe: Capture Phase 2B | All audits approved | knowz-scribe |
+| Scribe: Capture Phase 3 | Phase 3 finalization | knowz-scribe |
+
+---
+
+## Sequential Teams / Subagent Flow (Tier 3 Fallback)
+
+> **Note:** Sequential Teams does not use orchestration config settings except `MCP_AGENTS_ENABLED`.
+
+When using Sequential Teams (`--sequential`) or Subagent Delegation, follow the traditional one-agent-per-phase flow. For each phase below: spawn the agent, create a task, wait for completion, present quality gate, shut down agent, proceed to next phase.
+
+### MCP Probe (Sequential/Subagent)
+
+Determine vault availability before Phase 1A:
+
+1. Read `knowzcode/knowzcode_vaults.md` — check for CONFIGURED entries (non-empty ID)
+2. Attempt `list_vaults(includeStats=true)`
+3. If succeeds AND UNCREATED entries exist → present the **Vault Creation Prompt** (same as Parallel Teams Step 3d). Handle selection identically.
+4. After resolution, announce MCP status to the user:
+   - `list_vaults()` succeeded: `**MCP Status: Connected — N vault(s) available**`
+   - `list_vaults()` failed but configured vaults exist: `**MCP Status: Lead probe failed — closer will verify at Phase 3**`
+   - No configured vaults: `**MCP Status: Not configured**`
+
+The closer agent independently verifies MCP at Phase 3 regardless of this result (see `agents/closer.md` — Startup MCP Verification). This probe is for the user announcement and vault creation opportunity only.
+
+---
+
+## Phase Prompt Reference
+
+The spawn prompts below are shared by all execution modes. In Parallel Teams mode, the lead uses these prompts when spawning agents at the appropriate stage. In Sequential Teams / Subagent mode, agents are spawned one at a time in phase order.
+
+## Stage 0: Context Scouts (3 instances)
+
+**Agent**: `context-scout` (x3) | Read-only local context researchers
+
+Three instances of the same agent, each focused on a different local folder group:
+
+**context-scout-specs spawn prompt**:
+> You are `context-scout-specs` for WorkGroup `{wgid}`.
+> Read `agents/context-scout.md` for your full role definition.
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Focus area**: `knowzcode/specs/*.md` — scan existing specifications.
+> **Goal**: {goal}
+> **READ-ONLY.** Do NOT modify any files.
+> **Deliverable**: Broadcast relevant spec findings (NodeIDs, status, VERIFY criteria overlapping with goal).
+
+**context-scout-workgroups spawn prompt**:
+> You are `context-scout-workgroups` for WorkGroup `{wgid}`.
+> Read `agents/context-scout.md` for your full role definition.
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Focus area**: `knowzcode/workgroups/*.md` — scan previous WorkGroups for similar goals.
+> **Goal**: {goal}
+> **READ-ONLY.** Do NOT modify any files.
+> **Deliverable**: Broadcast prior WorkGroup context (what was tried, what succeeded/failed, patterns).
+
+**context-scout-backlog spawn prompt**:
+> You are `context-scout-backlog` for WorkGroup `{wgid}`.
+> Read `agents/context-scout.md` for your full role definition.
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Focus area**: `knowzcode/knowzcode_tracker.md`, `knowzcode/knowzcode_log.md`, `knowzcode/knowzcode_architecture.md`, `knowzcode/knowzcode_project.md`
+> **Goal**: {goal}
+> **READ-ONLY.** Do NOT modify any files.
+> **Deliverable**: Broadcast active WIP, REFACTOR tasks, architecture summary, and recent log patterns relevant to goal.
+
+**context-scout (combined) spawn prompt** (used when `SCOUT_MODE = "minimal"`):
+> You are `context-scout` for WorkGroup `{wgid}`.
+> Read `agents/context-scout.md` for your full role definition.
+> **Your Task**: #{task-id} — claim immediately. Mark completed with summary when done.
+> **Focus area**: ALL local context — `knowzcode/specs/*.md`, `knowzcode/workgroups/*.md`, `knowzcode/knowzcode_tracker.md`, `knowzcode/knowzcode_log.md`, `knowzcode/knowzcode_architecture.md`, `knowzcode/knowzcode_project.md`
+> **Goal**: {goal}
+> **READ-ONLY.** Do NOT modify any files.
+> **Deliverable**: Broadcast consolidated findings covering specs, prior workgroups, active WIP, REFACTOR tasks, and architecture context.
+
+**Dispatch**:
+- *Parallel Teams*:
+  - `SCOUT_MODE = "full"`: 3 context scouts spawned at Stage 0. Shut down after Gate #2.
+  - `SCOUT_MODE = "minimal"`: 1 context-scout (combined) spawned at Stage 0. Shut down after Gate #2.
+  - `SCOUT_MODE = "none"`: No scouts spawned.
+- *Sequential Teams*: Not applicable (scouts are Parallel Teams only).
+- *Subagent*:
+  - `SCOUT_MODE = "full"`: 3 parallel `Task()` calls (specs, workgroups, backlog).
+  - `SCOUT_MODE = "minimal"`: 1 `Task()` call with combined prompt.
+  - `SCOUT_MODE = "none"`: Skip scout tasks.
+
+---
+
+## Stage 0: Codebase Scanners (2 instances — conditional)
+
+**Agent**: `general-purpose` (x2) | Lightweight codebase searchers (no agent definition file)
+
+Two temporary agents that scan the codebase in parallel with the analyst, broadcasting findings to accelerate impact analysis. Only spawned when `CODEBASE_SCANNER_ENABLED = true` (default).
+
+**scanner-direct spawn prompt**:
+> You are `scanner-direct` for WorkGroup `{wgid}`.
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Goal**: {goal}
+> **Focus**: Search source code for goal-related keywords and patterns.
+>
+> **Steps**:
+> 1. Grep for goal keywords across source files (exclude node_modules, dist, build, .git)
+> 2. Read the top 5-8 matching files to understand affected code paths
+> 3. Identify module boundaries and cross-module dependencies
+> 4. Note public APIs and interfaces that may need changes
+>
+> **READ-ONLY.** Do NOT modify any files.
+> **Deliverable**: Broadcast findings to all teammates — affected files, code paths, module boundaries, and interface patterns.
+> **Budget**: Complete within ~12 turns. Focus on breadth over depth.
+
+**scanner-tests spawn prompt**:
+> You are `scanner-tests` for WorkGroup `{wgid}`.
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Goal**: {goal}
+> **Focus**: Discover tests covering the goal area to understand test patterns and coverage shape.
+>
+> **Steps**:
+> 1. Glob for test files: `**/*.test.*`, `**/*.spec.*`, `**/test_*`, `**/tests/**`
+> 2. Grep test files for goal-related keywords
+> 3. Read 3-5 matching test files to understand testing patterns (test framework, mocking strategy, fixture patterns)
+> 4. Check for integration/e2e tests related to the goal area
+>
+> **READ-ONLY.** Do NOT modify any files.
+> **Deliverable**: Broadcast findings to all teammates — test file locations, testing patterns, coverage gaps, and fixture/mock patterns.
+> **Budget**: Complete within ~12 turns. Focus on breadth over depth.
+
+**Dispatch**:
+- *Parallel Teams*: Spawned at Stage 0 if `CODEBASE_SCANNER_ENABLED = true`. Use `subagent_type: "general-purpose"`, `maxTurns: 12`. Shut down after Stage 1 (analyst completes Change Set).
+- *Sequential Teams*: Not applicable (scanners are Parallel Teams only).
+- *Subagent*: `Task(subagent_type="general-purpose", description="Scan codebase for {focus}", maxTurns=12, prompt=<above>)` if `CODEBASE_SCANNER_ENABLED = true`.
+
+---
+
+## Stage 0: Knowz Scout
+
+**Agent**: `knowz-scout` | MCP vault researcher and knowledge agent
+
+**Spawn prompt**:
+> You are the **knowz-scout** for WorkGroup `{wgid}`.
+> Read `agents/knowz-scout.md` for your full role definition.
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Goal**: {goal}
+> **Step 1**: Read `knowzcode/knowzcode_vaults.md` to discover configured vaults — their IDs, types, descriptions, and what knowledge each contains.
+> **Step 2**: For each configured vault, construct goal-relevant queries using the vault's description to guide what to ask. If a single vault covers all knowledge, consolidate queries there.
+> **Deliverable**: Broadcast vault knowledge findings to all teammates.
+
+**Dispatch**:
+- *Parallel Teams*: **Group B** — spawned at Stage 0 if `VAULTS_CONFIGURED = true`, no blockedBy. Persistent — stays alive through the entire workflow. Shut down after Phase 3 capture is complete.
+- *Sequential Teams*: Not applicable (scouts are Parallel Teams only).
+- *Subagent*: `Task(subagent_type="knowz-scout", description="Query vault for domain knowledge", prompt=<above>)` (only if MCP Probe passes)
+
+---
+
+## Stage 0: Knowz Scribe
+
+**Agent**: `knowz-scribe` | Persistent vault write agent (Haiku)
+
+**Spawn prompt**:
+> You are the **knowz-scribe** for WorkGroup `{wgid}`.
+> Read `agents/knowz-scribe.md` for your full role definition.
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
+> **Vault config**: Read `knowzcode/knowzcode_vaults.md` to discover configured vaults and resolve vault IDs by type.
+> **You are a message-driven agent.** Wait for capture messages from teammates (e.g., "Capture Phase 1A: {wgid}"). On each message, read the WorkGroup file, extract relevant learnings, and write to the appropriate vault.
+> **Do NOT read or modify source code.** You only read knowzcode/ files and write to MCP vaults.
+
+**Dispatch**:
+- *Parallel Teams*: **Group B** — spawned at Stage 0 if `VAULTS_CONFIGURED = true`, no blockedBy. Persistent — stays alive through the entire workflow. Shut down after Phase 3 capture is complete.
+- *Sequential Teams*: Not applicable (knowz-scribe is Parallel Teams only).
+- *Subagent*: Not applicable — vault writes in subagent mode are handled by the closer during Phase 3 finalization (see Direct Write Fallback in `agents/closer.md`).
+
+---
+
+## Specialist Spawn Prompts (Group C — opt-in via `--specialists`)
+
+The spawn prompts below are used when `SPECIALISTS_ENABLED` is non-empty. Specialists are spawned at Stage 0 alongside Groups A and B.
+
+**Dispatch** (all specialists):
+- *Parallel Teams*: Group C — spawned at Stage 0 if `SPECIALISTS_ENABLED` non-empty, no blockedBy. Security-officer and test-advisor persist through Gate #3. Project-advisor shuts down mid-Stage 2.
+- *Sequential Teams*: Not supported — announce skip reason.
+- *Subagent*: `Task()` calls with spawn prompts below.
+
+### Security Officer
+
+**Agent**: `security-officer` | Officer — CRITICAL/HIGH findings block gates
+
+**Spawn prompt**:
+> You are the **security-officer** for WorkGroup `{wgid}`.
+> Read `agents/security-officer.md` for your full role definition.
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Goal**: {goal}
+> **READ-ONLY.** Do NOT modify any files. Bash is for read-only security scanning only.
+> **Stage 0 Deliverable**: Build STRIDE-lite threat model. Scan for auth/PII/crypto/session patterns. Broadcast initial threat assessment.
+> **Authority**: CRITICAL/HIGH findings use `[SECURITY-BLOCK]` tag — lead MUST pause autonomous mode.
+> **Communication**: DM lead at gates. DM architect with security VERIFY criteria needs. DM builders in security-sensitive partitions (max 2 per builder). DM test-advisor for cross-cutting test gaps (max 2).
+> **Enterprise Compliance**: If `knowzcode/enterprise/compliance_manifest.md` exists and `compliance_enabled: true`, read active security guidelines and cross-reference findings with enterprise guideline IDs.
+
+### Test Advisor
+
+**Agent**: `test-advisor` | Advisor — informational only
+
+**Spawn prompt**:
+> You are the **test-advisor** for WorkGroup `{wgid}`.
+> Read `agents/test-advisor.md` for your full role definition.
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Goal**: {goal}
+> **READ-ONLY.** Do NOT modify any files. Bash is for read-only operations only (git log, coverage reports).
+> **Stage 0 Deliverable**: Establish test coverage baseline. Glob test files, run coverage if available. Broadcast baseline.
+> **Communication**: DM lead at gates. DM architect if VERIFY criteria aren't testable. DM builders with test improvement feedback (max 2 per builder). DM security-officer for cross-cutting security test gaps (max 2).
+> **Enterprise Compliance**: If `knowzcode/enterprise/compliance_manifest.md` exists and `compliance_enabled: true`, check enterprise ARC criteria for test coverage gaps.
+
+### Project Advisor
+
+**Agent**: `project-advisor` | Advisor — informational only
+
+**Spawn prompt**:
+> You are the **project-advisor** for WorkGroup `{wgid}`.
+> Read `agents/project-advisor.md` for your full role definition.
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Goal**: {goal}
+> **READ-ONLY.** Do NOT modify any files.
+> **Stage 0 Deliverable**: Read tracker for existing REFACTOR tasks and backlog context. DM lead with context summary.
+> **Lifecycle**: You shut down mid-Stage 2 after delivering backlog proposals — before the gap loop.
+> **Communication**: DM lead with backlog context and proposals. DM knowz-scribe with idea captures (if active). Do NOT DM builders or other specialists.
+> **Enterprise Compliance**: If `knowzcode/enterprise/compliance_manifest.md` exists, note compliance configuration gaps in backlog proposals.
+
+---
+
+## Phase 1A: Impact Analysis
+
+**Agent**: `analyst` | **Loop.md**: Section 3.1
+
+**Spawn prompt**:
+> You are the **analyst** for WorkGroup `{wgid}`.
+> Read `agents/analyst.md` for your full role definition.
+>
+> **Goal**: {goal}
+> **Context files**: Read sections 1-2 and 3.1 of `knowzcode/knowzcode_loop.md` (skip other phases), `knowzcode/knowzcode_tracker.md`, `knowzcode/knowzcode_project.md`, `knowzcode/knowzcode_architecture.md`
+> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
+>
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Conventions**: Update WorkGroup file with results (prefix entries with `KnowzCode:`). If blocked, report blocker and notify lead.
+> **Codebase scanners**: Scanner agents are running in parallel — their findings will arrive as broadcast messages. Incorporate them into your analysis but do NOT wait for them.
+> **Preliminary Findings Protocol**: As you discover high-confidence NodeIDs, DM the architect with `[PRELIMINARY]` messages (max 3 — see `agents/analyst.md` for format). This lets the architect start speculative research early.
+> **Deliverable**: Change Set proposal written to the WorkGroup file. Include NodeIDs, descriptions, affected files, risk assessment, and dependency map (for Parallel Teams mode).
+
+**Dispatch**:
+- *Parallel Teams*: Spawned at Stage 0 alongside scouts, scanners, and architect. Starts immediately (no blockedBy).
+- *Sequential Teams*: Spawn teammate `analyst`, create task `Phase 1A: Impact analysis for "{goal}"`, wait for completion.
+- *Subagent*: `Task(subagent_type="analyst", description="Phase 1A impact analysis", prompt=<above>)`
+
+### Quality Gate #1
+
+Present the Change Set for user approval:
+
+```markdown
+## Approval Gate #1: Change Set
+
+**WorkGroupID**: {wgid}
+**Proposed Change Set** ({N} nodes):
+{NodeIDs with descriptions}
+
+**Dependency Map** (Parallel Teams):
+{NodeID parallelism groups}
+
+**Risk Assessment**: {Low/Medium/High}
+
+### Specialist Reports                    [only when SPECIALISTS_ENABLED non-empty]
+**Security Officer**: {risk assessment per NodeID, attack surface changes, threat model}
+**Architect**: {architecture impact, layer touch points, pattern alignment}
+**Test Advisor**: {coverage baseline, test strategy recommendations per NodeID}
+
+Approve this Change Set to proceed to specification?
+```
+
+**Autonomous Mode**: If `AUTONOMOUS_MODE = true`, present gate info for transparency, log `[AUTO-APPROVED] Gate #1`, and proceed immediately.
+If `AUTONOMOUS_MODE = false`: If rejected — re-run analyst with user feedback. If approved — update tracker, proceed.
+
+### Lead Responsibility: Progress Capture
+
+**Lead responsibility.** After gate approval, the lead triggers progress capture. If knowz-scribe is active (Parallel Teams with vaults configured):
+- Create capture task: `TaskCreate("Scribe: Capture Phase 1A")` → `TaskUpdate(owner: "knowz-scribe")`
+- Send message to **knowz-scribe** with task ID: `"Capture Phase 1A: {wgid}. Your task: #{task-id}"` — the scribe reads the WorkGroup file, extracts scope/risk/decision data, and writes to the appropriate vault
+- `search_knowledge({resolved_domain_vault_id}, "patterns for {domain}")` — pull relevant past learnings to inform specification
+- Share any relevant findings with the architect in the Phase 1B prompt
+
+---
+
+## Stage 0: Architect Pre-load (Parallel Teams)
+
+**Agent**: `architect` | Spawned at Stage 0 for context pre-loading and speculative research
+
+In Parallel Teams mode, the architect is spawned at Stage 0 (not at Phase 1B). It pre-loads architecture context and performs speculative research on `[PRELIMINARY]` NodeIDs from the analyst.
+
+**Stage 0 spawn prompt** (Parallel Teams only):
+> You are the **architect** for WorkGroup `{wgid}`.
+> Read `agents/architect.md` for your full role definition.
+>
+> **Goal**: {goal}
+> **Context files**: Read sections 1-2 and 3.2 of `knowzcode/knowzcode_loop.md` (skip other phases), `knowzcode/knowzcode_project.md`, `knowzcode/knowzcode_architecture.md`
+> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
+> **Specs directory**: `knowzcode/specs/`
+>
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Stage 0 Role**: Pre-load architecture context, then perform speculative research on any `[PRELIMINARY]` NodeID messages from the analyst (see Speculative Research Protocol in `agents/architect.md`). READ-ONLY research — do NOT write specs yet.
+> **Lifecycle**: You persist through the entire workflow. After Gate #1, you will receive spec-drafting tasks via DM. After Gate #2, you shift to consultative role for builders.
+
+After Gate #1, the lead sends the approved Change Set via DM and creates spec-drafting tasks. For spec-drafting prompts, see Phase 1B below.
+
+---
+
+## Phase 1B: Specification
+
+**Agent**: `architect` | **Loop.md**: Section 3.2
+
+**Spec-drafting prompt** (sent via DM to already-warm architect in Parallel Teams, or as spawn prompt in Sequential/Subagent):
+> You are the **architect** for WorkGroup `{wgid}`.
+> Read `agents/architect.md` for your full role definition.
+>
+> **Goal**: {goal}
+> **Approved Change Set**: {NodeIDs from Gate #1}
+> **Context files**: Read sections 1-2 and 3.2 of `knowzcode/knowzcode_loop.md` (skip other phases), `knowzcode/knowzcode_project.md`, `knowzcode/knowzcode_architecture.md`
+> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
+> **Specs directory**: `knowzcode/specs/`
+>
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Conventions**: Update WorkGroup file with results (prefix entries with `KnowzCode:`). If blocked, report blocker and notify lead.
+> **Deliverable**: Finalized specs for all NodeIDs written to `knowzcode/specs/`.
+
+**Spec-drafter spawn prompt** (Path B — 3+ NodeIDs, Parallel Teams only):
+> You are `spec-drafter-{N}` for WorkGroup `{wgid}`.
+> Read `agents/architect.md` for your full role definition — you follow the same Spec Philosophy, Spec Format, and Consolidation Mandate.
+>
+> **Goal**: {goal}
+> **Your NodeIDs**: {partition — 1-2 NodeIDs assigned to this drafter}
+> **Architect Research**: {research findings from architect's speculative research for these NodeIDs}
+> **Cross-NodeID Constraints**: {interface dependencies, shared specs, naming conventions from architect}
+> **Context files**: Read sections 1-2 and 3.2 of `knowzcode/knowzcode_loop.md`, `knowzcode/knowzcode_project.md`, `knowzcode/knowzcode_architecture.md`
+> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
+> **Specs directory**: `knowzcode/specs/`
+>
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Deliverable**: Draft specs for your assigned NodeIDs written to `knowzcode/specs/`. The architect will review for consistency after all drafters finish.
+
+**Dispatch**:
+- *Parallel Teams*:
+  - **Path A** (< PARALLEL_SPEC_THRESHOLD NodeIDs): Architect is already warm from Stage 0 pre-load + speculative research. Lead sends DM with approved Change Set, then creates spec-drafting tasks. **Plan approval enabled** — add to prompt: `Present your spec design for lead review BEFORE writing final specs. Wait for approval.` If `AUTONOMOUS_MODE = true`: auto-approve `plan_approval_request` immediately. Log `[AUTO-APPROVED] Architect plan`.
+  - **Path B** (>= PARALLEL_SPEC_THRESHOLD NodeIDs): Lead asks architect for partition plan. Architect proposes partitions. Lead spawns spec-drafters (`subagent_type: "architect"`, `permissionMode: "acceptEdits"`, `maxTurns: 15`) with partition-scoped prompts. After all drafters complete, architect runs consistency review and reports to lead.
+- *Sequential Teams*: Spawn teammate `architect`, create task `Phase 1B: Draft specifications for {N} NodeIDs`. **Plan approval enabled** — add to prompt: `Present your spec design for lead review BEFORE writing final specs. Wait for approval.` Wait for `plan_approval_request`, review, respond with `plan_approval_response`. If `AUTONOMOUS_MODE = true`: auto-approve immediately. Log `[AUTO-APPROVED] Architect plan`.
+- *Subagent*: `Task(subagent_type="architect", description="Phase 1B specification drafting", prompt=<above> + "Present your spec design in your output for lead review.")`
+
+> **Note:** Plan approval (agent pauses for lead review) only works in Agent Teams mode via `permissionMode: plan`. In subagent mode, the architect presents its design in the output for post-hoc review. Spec-drafters (Path B) do NOT use plan approval — they follow the architect's partition briefing directly.
+
+### Quality Gate #2
+
+Present specs for batch approval:
+
+```markdown
+## Approval Gate #2: Specifications
+
+**Specs Drafted**: {count}
+| NodeID | File | Key VERIFY Criteria |
+|--------|------|---------------------|
+| ... | ... | ... |
+
+### Specialist Reports                    [only when SPECIALISTS_ENABLED non-empty]
+**Architect**: {specs align with component map, drift concerns, pattern consistency}
+**Test Advisor**: {spec testability assessment, recommended test types per NodeID}
+
+Review specs and approve to proceed to implementation?
+```
+
+**Autonomous Mode**: If `AUTONOMOUS_MODE = true`, present gate info for transparency, log `[AUTO-APPROVED] Gate #2`, and proceed immediately.
+If `AUTONOMOUS_MODE = false`: If rejected — re-run specs needing revision. If approved — pre-implementation commit, proceed.
+
+**Pre-Implementation Commit:**
+```bash
+git add knowzcode/
+git commit -m "KnowzCode: Specs approved for {WorkGroupID}"
+```
+
+---
+
+## Phase 2A: Implementation
+
+**Agent**: `builder` | **Loop.md**: Section 3.3
+
+**Spawn prompt**:
+> You are the **builder** for WorkGroup `{wgid}`.
+> Read `agents/builder.md` for your full role definition.
+>
+> **Goal**: {goal}
+> **Approved Change Set**: {NodeIDs}
+> **Specs**: {list of spec file paths from Phase 1B}
+> **Context files**: Read sections 1-2 and 3.3 of `knowzcode/knowzcode_loop.md` (skip other phases), `knowzcode/knowzcode_project.md`
+> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
+>
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Conventions**: Update WorkGroup file with results (prefix entries with `KnowzCode:`). If blocked, report blocker and notify lead.
+> **TDD mandatory**: Write failing tests first, then implement, then refactor. Every NodeID must have tests.
+> **Blocker protocol**: If you hit a blocker, document it as a Blocker Report in the WorkGroup file (see loop.md Section 11 format) and report to the lead immediately instead of guessing.
+> **Deliverable**: All NodeIDs implemented with passing tests.
+
+**Dispatch**:
+- *Parallel Teams*: Multiple builders spawned at Stage 2, one per partition from the dependency map. Each builder gets its partition's NodeIDs and specs. Builders create per-NodeID subtasks for visibility. **Plan approval enabled** — add to prompt: `Present your implementation approach for lead review BEFORE writing code. Wait for approval.` If `AUTONOMOUS_MODE = true`: auto-approve `plan_approval_request` immediately. Log `[AUTO-APPROVED] Builder plan`.
+- *Sequential Teams*: Spawn teammate `builder`, create task `Phase 2A: Implement {N} NodeIDs with TDD`. **Plan approval enabled** — add to prompt: `Present your implementation approach for lead review BEFORE writing code. Wait for approval.` Wait for `plan_approval_request`, review, respond. If `AUTONOMOUS_MODE = true`: auto-approve immediately. Log `[AUTO-APPROVED] Builder plan`.
+- *Subagent*: `Task(subagent_type="builder", description="Phase 2A TDD implementation", mode="bypassPermissions", prompt=<above>)`
+
+### Phase 2A Output
+
+When complete, present implementation summary including files changed, tests written, and test results.
+
+### Lead Responsibility: Progress Capture
+
+**Lead responsibility.** After gate approval, the lead triggers progress capture. If knowz-scribe is active (Parallel Teams with vaults configured):
+- Create capture task: `TaskCreate("Scribe: Capture Phase 2A")` → `TaskUpdate(owner: "knowz-scribe")`
+- Send message to **knowz-scribe** with task ID: `"Capture Phase 2A: {wgid}. Your task: #{task-id}"` — the scribe reads implementation results from the WorkGroup file and captures patterns, workarounds, and performance optimizations to the `code` vault
+
+---
+
+## Phase 2B: Completeness Audit
+
+**Agent**: `reviewer` | **Loop.md**: Section 3.4
+
+**Spawn prompt**:
+> You are the **reviewer** for WorkGroup `{wgid}`.
+> Read `agents/reviewer.md` for your full role definition.
+>
+> **Goal**: {goal}
+> **Change Set**: {NodeIDs}
+> **Specs**: {list of spec file paths}
+> **Context files**: Read sections 1-2 and 3.4 of `knowzcode/knowzcode_loop.md` (skip other phases), `knowzcode/knowzcode_project.md`, `knowzcode/knowzcode_architecture.md`
+> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
+>
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Conventions**: Update WorkGroup file with results (prefix entries with `KnowzCode:`). If blocked, report blocker and notify lead.
+> **This is a READ-ONLY audit.** Do not modify any source code or test files.
+> **Deliverable**: Audit report with ARC completion %, security posture, and gap list.
+
+**Dispatch**:
+- *Parallel Teams*: One reviewer per builder partition, spawned at Stage 2. Each reviewer gets its partition's NodeIDs and specs. Audit tasks use `addBlockedBy` per implementation task. Each reviewer uses structured gap report format (see `agents/reviewer.md`).
+- *Sequential Teams*: Spawn teammate `reviewer`, create task `Phase 2B: Completeness audit for {N} NodeIDs`, wait for completion.
+- *Subagent*: `Task(subagent_type="reviewer", description="Phase 2B completeness audit", prompt=<above>)`
+
+### Quality Gate #3
+
+Present audit results:
+
+```markdown
+## Approval Gate #3: Audit Results
+
+**ARC Completion**: {X}%
+**Security Posture**: {status}
+**Gaps Found**: {count}
+
+### Specialist Reports                    [only when SPECIALISTS_ENABLED non-empty]
+**Security Officer**: Findings: {N} | Critical: {N} | High: {N} | {details or [Pending]}
+**Architect**: Drift: {Yes/No} | Pattern Violations: {N} | {details}
+**Test Advisor**: TDD Compliance: {%} | Missing Edge Cases: {N} | Quality: {Good/Adequate/Poor} | {details or [Pending]}
+**Project Advisor**: New REFACTOR tasks: {N} | Ideas captured to vault: {N}
+
+**Recommendation**: {proceed / return to implementation}
+
+How would you like to proceed?
+```
+
+**Autonomous Mode**: If `AUTONOMOUS_MODE = true`:
+- **Safety check**: If any security finding rated HIGH or CRITICAL (from reviewer OR security-officer `[SECURITY-BLOCK]`) → **PAUSE** autonomous mode for this gate. Announce: `> **Autonomous Mode Paused** — HIGH/CRITICAL security finding requires manual review.`
+- **Safety check**: If ARC completion < 50% → **PAUSE** autonomous mode for this gate. Announce: `> **Autonomous Mode Paused** — ARC completion below 50% requires manual review.`
+- If safety checks pass and gaps found → log `[AUTO-APPROVED] Gate #3 — proceeding to gap loop`, auto-proceed to gap loop.
+- If safety checks pass and no gaps → log `[AUTO-APPROVED] Gate #3`, auto-proceed to Phase 3.
+
+If `AUTONOMOUS_MODE = false`: User decides — proceed / fix gaps / modify specs / cancel.
+
+### Gap Loop (when user chooses to fix gaps)
+
+**Parallel Teams mode** (per-partition, persistent agents — no respawning):
+1. Lead reads each reviewer's structured gap report from task summary
+2. Lead creates fix task and pre-assigns:
+   `TaskCreate("Fix gaps: NodeID-X", addBlockedBy: [audit-task-id])` → `TaskUpdate(owner: "builder-N")`
+3. Lead sends DM to builder with task ID and gap details:
+   `"**New Task**: #{fix-task-id} — Fix gaps: NodeID-X. {file path, VERIFY criterion, expected vs actual}"`
+4. Builder claims fix task, fixes gaps, re-runs tests, marks fix task complete
+5. Lead creates re-audit task and pre-assigns:
+   `TaskCreate("Re-audit: NodeID-X", addBlockedBy: [gap-fix-task-id])` → `TaskUpdate(owner: "reviewer-N")`
+6. Lead sends DM to reviewer: `"**New Task**: #{reaudit-task-id} — Re-audit: NodeID-X. {gap list}"`
+7. Each builder-reviewer pair repeats independently until clean — no cross-partition blocking
+8. All builders and reviewers stay alive throughout
+9. **3-iteration cap per partition**: If a partition exceeds 3 gap-fix iterations without resolution, **PAUSE** autonomous mode for that partition (even if `AUTONOMOUS_MODE = true`). Announce: `> **Autonomous Mode Paused** — Partition {N} failed 3 gap-fix iterations. Manual review required.`
+
+**Sequential Teams mode**: Spawn a NEW `builder` with the standard Phase 2A prompt plus gap fix context. Then re-run Phase 2B (spawn a new reviewer). Repeat until user approves at Gate #3.
+
+**Subagent mode**: Launch parallel `Task()` calls — one for gap fix (builder), then one for re-audit (reviewer). Repeat as needed.
+
+### Lead Responsibility: Progress Capture
+
+**Lead responsibility.** After gate approval, the lead triggers progress capture. If knowz-scribe is active (Parallel Teams with vaults configured):
+- Create capture task: `TaskCreate("Scribe: Capture Phase 2B")` → `TaskUpdate(owner: "knowz-scribe")`
+- Send message to **knowz-scribe** with task ID: `"Capture Phase 2B: {wgid}. Your task: #{task-id}"` — the scribe reads audit results from the WorkGroup file and writes findings to the appropriate vault
+
+---
+
+## Phase 3: Finalization
+
+**Agent**: `closer` | **Loop.md**: Section 3.5
+
+**Spawn prompt (Parallel Teams)**:
+> You are the **closer** for WorkGroup `{wgid}`.
+> Read `agents/closer.md` for your full role definition.
+>
+> **Goal**: {goal}
+> **Change Set**: {NodeIDs}
+> **Specs**: {list of spec file paths}
+> **Context files**: Read sections 1-2, 3.5, 6, and 7 of `knowzcode/knowzcode_loop.md` (skip other phases), `knowzcode/knowzcode_tracker.md`, `knowzcode/knowzcode_project.md`, `knowzcode/knowzcode_architecture.md`, `knowzcode/knowzcode_log.md`
+> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
+>
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Conventions**: Update WorkGroup file with results (prefix entries with `KnowzCode:`). If blocked, report blocker and notify lead.
+> **Vault writes**: Knowz-scribe is active. Create a capture task (`TaskCreate("Scribe: Capture Phase 3")` → `TaskUpdate(owner: "knowz-scribe")`), then send `"Capture Phase 3: {wgid}. Your task: #{task-id}"` to delegate learning capture and audit trail writes. Do NOT call `create_knowledge` directly.
+> **Deliverable**: Atomic finalization — update specs to FINAL, update tracker, write log entry, update architecture if needed, delegate learning capture to knowz-scribe, and create final commit.
+
+**Spawn prompt (Sequential Teams / Subagent)**:
+> You are the **closer** for WorkGroup `{wgid}`.
+> Read `agents/closer.md` for your full role definition.
+>
+> **Goal**: {goal}
+> **Change Set**: {NodeIDs}
+> **Specs**: {list of spec file paths}
+> **Context files**: Read sections 1-2, 3.5, 6, and 7 of `knowzcode/knowzcode_loop.md` (skip other phases), `knowzcode/knowzcode_tracker.md`, `knowzcode/knowzcode_project.md`, `knowzcode/knowzcode_architecture.md`, `knowzcode/knowzcode_log.md`
+> **WorkGroup file**: `knowzcode/workgroups/{wgid}.md`
+>
+> **Your Task**: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
+> **Conventions**: Update WorkGroup file with results (prefix entries with `KnowzCode:`). If blocked, report blocker and notify lead.
+> **Vault writes**: No knowz-scribe — you own all vault writes. Follow the Direct Write Fallback in `agents/closer.md`.
+> **MCP Status**: {MCP_ACTIVE} — Vaults configured: {VAULTS_CONFIGURED}. Vault config: `knowzcode/knowzcode_vaults.md`.
+> **Deliverable**: Atomic finalization — update specs to FINAL, update tracker, write log entry, update architecture if needed, write learnings to vaults, and create final commit.
+
+**Dispatch**:
+- *Parallel Teams*: Spawned at Stage 3 (`addBlockedBy`: last audit/re-audit task). Use the **Parallel Teams** spawn prompt. All other agents shut down before closer starts, except knowz-scout and knowz-scribe (stay alive for Phase 3 capture).
+- *Sequential Teams*: Spawn teammate `closer`, create task `Phase 3: Finalize WorkGroup {wgid}`, wait for completion. Use the **Sequential Teams / Subagent** spawn prompt.
+- *Subagent*: `Task(subagent_type="closer", description="Phase 3 finalization", prompt=<Sequential/Subagent spawn prompt above>)`
+
+### Phase 3 Output
+
+When complete, if MCP is configured and knowz-scribe is active:
+- The closer creates a capture task (`TaskCreate("Scribe: Capture Phase 3")` → `TaskUpdate(owner: "knowz-scribe")`) and sends a message with the task ID: `"Capture Phase 3: {wgid}. Your task: #{task-id}"`. The lead waits for the scribe's capture task to complete before shutdown.
+
+Update workgroup to "Closed" and report:
+
+```markdown
+## Workflow Complete
+
+**WorkGroupID**: {wgid}
+**Primary Goal**: {$ARGUMENTS}
+**Status**: VERIFIED and CLOSED
+
+- NodeIDs completed: {list}
+- Specs finalized: {count}
+- Tech debt scheduled: {count REFACTOR_ tasks}
+```
+
+---
+
+## Cleanup
+
+### After Phase 3 Completes
+
+**Agent Teams Mode** (Parallel or Sequential):
+1. Shut down all active teammates. Wait for each to confirm shutdown.
+2. Once all teammates have shut down, clean up the team (delete the `kc-{wgid}` team).
+   No teammates or team resources should remain after the workflow ends.
+
+**Subagent Mode**: No cleanup needed — `Task()` calls are self-contained.
+
+### If User Cancels Mid-Workflow
+
+Follow the abandonment protocol from `knowzcode_loop.md` Section 12:
+
+1. **Revert uncommitted changes** — if implementation was in progress, revert source code changes (keep knowzcode files)
+2. **Update tracker** — set all affected NodeIDs back to their pre-WorkGroup status
+3. **Log abandonment** — create a log entry with type `WorkGroup-Abandoned` including the reason and phase at abandonment
+4. **Close WorkGroup file** — mark the WorkGroup as `Abandoned` with timestamp and reason
+5. **Preserve learnings** — if any useful patterns were discovered, capture them before closing
+6. **Team teardown** — (Agent Teams only) shut down all active teammates and delete the team
+7. **Parallel mode**: If cancelled mid-Stage-2, revert uncommitted code changes and mark WorkGroup abandoned
+
+The WorkGroup file remains in `knowzcode/workgroups/` for reference. It can be resumed later with `/kc:work` referencing the same goal.
+
+---
+
+## Handling Failures
+
+- Phase 1A rejected: re-run analyst with feedback
+- Phase 1B rejected: re-run architect with specific issues (Parallel Teams: architect is already warm)
+- Phase 2A blocker encountered: present Blocker Report (per loop.md Section 11) to user with 5 recovery options: (1) modify spec, (2) change approach, (3) split WorkGroup, (4) accept partial with documented gap, (5) cancel WorkGroup
+- Phase 2B audit shows gaps: return to 2A with gap list (see Gap Loop above)
+- If >3 failures on same phase: PAUSE and ask user for direction (applies even when `AUTONOMOUS_MODE = true` — this is a safety exception)
+
+## KnowzCode: Prefix Enforcement
+
+Every todo in workgroup files MUST start with `KnowzCode:`. Pass this to all agents.