knowzcode 0.3.3 → 0.3.7

package/.claude-plugin/marketplace.json

@@ -6,14 +6,14 @@
   },
   "metadata": {
     "description": "Official KnowzCode plugin marketplace - Platform-agnostic AI development methodology",
-    "version": "0.3.3"
+    "version": "0.3.7"
   },
   "plugins": [
     {
       "name": "kc",
       "source": "./",
       "description": "KnowzCode - Platform-agnostic AI development methodology with TDD, quality gates, and structured workflows",
-      "version": "0.3.3",
+      "version": "0.3.7",
       "author": {
         "name": "Alex Headscarf"
       },

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "kc",
   "description": "KnowzCode - Platform-agnostic AI development methodology with TDD, quality gates, and structured workflows",
-  "version": "0.3.3",
+  "version": "0.3.7",
   "author": {
     "name": "Alex Headscarf"
   }

package/README.md

@@ -6,7 +6,7 @@
 
 [![License: MIT + Commons Clause](https://img.shields.io/badge/License-MIT_+_Commons_Clause-yellow.svg)](LICENSE)
 [![Claude Code Plugin](https://img.shields.io/badge/Claude_Code-Plugin-purple)](https://github.com/knowz-io/knowzcode)
-[![Version](https://img.shields.io/badge/version-0.3.3-blue)](https://github.com/knowz-io/knowzcode/releases)
+[![Version](https://img.shields.io/badge/version-0.3.7-blue)](https://github.com/knowz-io/knowzcode/releases)
 
 [Installation](#installation) · [Quick Start](#quick-start) · [When to Use It](#when-to-use-knowzcode) · [How It Works](#how-it-works) · [Commands](#commands) · [Docs](#documentation)
 

package/agents/closer.md

@@ -4,7 +4,7 @@ description: "KnowzCode: Finalization — specs, tracker, log, architecture, lea
 tools: Read, Write, Edit, Glob, Grep
 model: opus
 permissionMode: acceptEdits
-maxTurns: 20
+maxTurns: 25
 ---
 
 # Closer
@@ -16,6 +16,16 @@ Your expertise: Finalization of specs, tracker, log, architecture docs, and lear
 
 Execute the finalization phase after implementation is verified. Update all KnowzCode artifacts to reflect the completed work, then create a final commit.
 
+## Startup MCP Verification
+
+On spawn, verify MCP connectivity before beginning finalization:
+
+1. Read `knowzcode/knowzcode_vaults.md` — check for configured vaults (non-empty ID)
+2. If no configured vaults → skip vault writes (nothing to write to)
+3. If configured vaults exist → call `list_vaults()` to verify MCP connectivity
+   - If succeeds → proceed with vault writes during Learning Capture
+   - If fails → queue all captures to `knowzcode/pending_captures.md` during Learning Capture
+
 ## Finalization Protocol
 
 Follow the steps in `knowzcode_loop.md` section 3.5:
@@ -56,28 +66,105 @@ During finalization:
 
 ## Learning Capture
 
-Scan the WorkGroup for insight-worthy patterns using the signal types from `knowzcode_loop.md` section 7 (Pattern, Decision, Workaround, Performance, Security, Convention).
+Scan the WorkGroup for insight-worthy patterns using the signal types from `knowzcode_loop.md` section 7 (Pattern, Decision, Workaround, Performance, Security, Convention, Integration, Scope).
 
 ### Knowz-Scribe Delegation (Parallel Teams)
 
 If knowz-scribe is active (Parallel Teams mode with MCP connected):
-- Send message to **knowz-scribe**: `"Capture Phase 3: {wgid}"` — the scribe handles all vault writes (appropriate vaults by type)
+- Create capture task: `TaskCreate("Scribe: Capture Phase 3")` → `TaskUpdate(owner: "knowz-scribe")`
+- Send DM to **knowz-scribe** with task ID: `"Capture Phase 3: {wgid}. Your task: #{task-id}"`
 - Do NOT call `create_knowledge` directly — the scribe owns all vault writes
+- Note: The lead waits for the scribe's capture task to complete before shutdown. The closer does NOT wait — create the task, send the DM, and continue finalization.
 
 ### Direct Write Fallback (Sequential/Subagent)
 
-If knowz-scribe is NOT active but MCP is configured:
-1. Read `knowzcode/knowzcode_vaults.md` to discover configured vaults
-2. For each learning type, find the appropriate vault by type:
-   - Pattern/Workaround/Performance → vault with type `code`
-   - Decision/Convention/Security/Integration → vault with type `ecosystem`
-   - Completion records → vault with type `finalizations`
-   - If a single vault covers all types (or only a `research`/`domain`/`platform` alias vault exists), write everything there
-3. Only write if the targeted vault is configured — skip gracefully if not
-4. **Title prefixes**: `Pattern:`, `Decision:`, `Workaround:`, `Performance:`, `Security:`, `Convention:`
-5. For enterprise audit trail: find vault matching type "enterprise", push completion record if configured and compliance is enabled
-
-If MCP is not available, skip learning capture and audit trail — all other finalization works normally.
+If knowz-scribe is NOT active but MCP is available (verified at startup):
+
+> **Content Detail Principle**: Vault entries are retrieved via semantic search — write detailed, self-contained content with full reasoning, technology names, and code examples. See `knowzcode/knowzcode_vaults.md` (canonical source for content filters).
+
+#### Step 1: Read Context
+
+1. Read `knowzcode/knowzcode_vaults.md` to discover configured vaults, their IDs, write conditions, and content filters
+2. Skip vault entries with empty ID fields — these haven't been created on the server yet
+3. Treat backwards-compat aliases identically: `research`/`domain`/`platform` = `ecosystem`, `sessions` = `finalizations`
+4. If a single vault is configured (regardless of type), route everything there
+
+#### Step 2: Determine Target Vaults
+
+Use the **Learning Category Routing** table to map each detected learning to the correct vault type:
+
+| Learning Category | Target Vault Type | Title Prefix |
+|-------------------|-------------------|--------------|
+| Pattern | `code` | `Pattern:` |
+| Workaround | `code` | `Workaround:` |
+| Performance | `code` | `Performance:` |
+| Decision | `ecosystem` | `Decision:` |
+| Convention | `ecosystem` | `Convention:` |
+| Security | `ecosystem` | `Security:` |
+| Integration | `ecosystem` | `Integration:` |
+| Scope | `ecosystem` | `Scope:` |
+| Completion record | `finalizations` | `Completion:` |
+| Audit trail | user's enterprise vault (if configured) | `Audit:` |
+
+Only write if the targeted vault is configured — skip gracefully if not.
+
+#### Step 3: Format Content
+
+For each target vault, apply its **Content Filter** as defined in `knowzcode/knowzcode_vaults.md`:
+
+- `code` vault: `[CONTEXT]` / `[PATTERN]` / `[EXAMPLE]` / `[TAGS]`
+- `ecosystem` vault: `[CONTEXT]` / `[INSIGHT]` / `[RATIONALE]` / `[TAGS]`
+- `finalizations` vault: `[GOAL]` / `[OUTCOME]` / `[NODES]` / `[DURATION]` / `[SUMMARY]` / `[TAGS]`
+
+Follow the Content Detail Principle: write self-contained entries with full reasoning, specific technology names, code examples, and file paths. Every entry must be useful without any other context — it will be found via semantic search months later.
+
+- **Title**: Use the prefix from the routing table + descriptive summary with technology names
+- **Tags**: learning category, `phase-3`, domain tags, technology names
+- **Source**: `KnowzCode WorkGroup {wgid}`
+
+#### Step 4: Dedup Check
+
+Before each write, call `search_knowledge(title, vaultId, 3)` on the target vault. If a result with a substantially similar title AND content already exists, skip the write. Log dedup catches in the WorkGroup file.
+
+#### Step 5: Write
+
+Call `create_knowledge` with the formatted payload for each target vault.
+
+#### Phase 3 Extraction Guide
+
+When scanning the WorkGroup for learnings, extract:
+- **Architectural learnings**: Structural discoveries, component relationships that were not obvious, integration patterns that emerged during implementation
+- **Convention patterns established**: New team conventions with full rationale and examples
+- **Consolidation decisions**: What was merged or refactored during finalization and why
+- **Implementation patterns**: Any Pattern/Workaround/Performance insights captured in the WorkGroup during Phase 2A that were not already written by a scribe
+- **Scope decisions**: What was included/excluded and the rationale (from Phase 1A)
+- **Security findings**: From Phase 2B audit, with severity and remediation
+
+#### Enterprise Audit Trail
+
+If `knowzcode/enterprise/compliance_manifest.md` exists and `mcp_compliance_enabled: true`:
+1. Find vault matching type "enterprise" in `knowzcode/knowzcode_vaults.md`
+2. Push completion record with goal, NodeIDs, audit score, and decisions
+3. Push architecture drift findings if any detected during finalization
+
+### MCP Graceful Degradation
+
+If MCP calls fail during vault writes (or MCP was unavailable at startup):
+
+1. **Queue locally**: Append each capture to `knowzcode/pending_captures.md`:
+   ```markdown
+   ### {timestamp} — {title}
+   - **Intent**: Phase 3 capture
+   - **Category**: {Pattern|Decision|Workaround|Performance|Security|Convention|Integration|Scope|Completion}
+   - **Target Vault Type**: {code|ecosystem|enterprise|finalizations}
+   - **Source**: closer / WorkGroup {wgid}
+   - **Content**: {full formatted content that would have been written to the vault}
+   ```
+2. Log the MCP failure in the WorkGroup file: `"KnowzCode: MCP unavailable — queued {N} capture(s) to pending_captures.md"`
+3. Note in the finalization report that captures were queued locally
+4. The pending file can be flushed later via `/kc:learn --flush` or by a future scribe instance
+
+**Never drop knowledge.** If MCP is down, queue it. All other finalization steps (specs, tracker, log, architecture, commit) proceed normally regardless of MCP status.
 
 ## Exit Expectations
 

package/agents/knowz-scribe.md

@@ -40,22 +40,32 @@ This catches MCP issues at Stage 0 instead of 10+ minutes later at first capture
 
 ## Capture Request Format
 
-You receive messages from the lead or other agents in this format:
+You receive capture requests from the lead or other agents in three forms:
 
-```
-Capture Phase {phase}: {wgid}
-```
+### Phase Captures (task-tracked)
+Format: `"Capture Phase {phase}: {wgid}. Your task: #{task-id}"`
 
-Examples:
-- `Capture Phase 1A: WG-feat-auth-20260212` — scope decision approved
-- `Capture Phase 2A: WG-feat-auth-20260212` — implementation patterns discovered
-- `Capture Phase 2B: WG-feat-auth-20260212` — audit results
-- `Capture Phase 3: WG-feat-auth-20260212` — finalization learnings
+Triggered at quality gates. Read the WorkGroup file, extract phase-specific content, write to appropriate vaults.
+
+### Explicit Ad-Hoc: `"Log: {description}"`
+A teammate has identified knowledge worth capturing and is telling you to write it.
+You MUST write it — decide which vault based on content type using the Learning Category Routing table.
+Apply standard dedup checking. If a task ID is included, track it.
+
+### Soft Ad-Hoc: `"Consider: {description}"`
+A teammate is forwarding something that MIGHT be worth capturing — a catch-all.
+Evaluate the content against the Learning Category signal types (Pattern, Decision, Workaround, Performance, Security, Convention).
+If it's insight-worthy and not duplicative, write it. If not, skip silently.
+The sender is not asking you to log it — they're asking you to use your judgement.
 
 ## Write Process
 
 For each capture request:
 
+### Step 0: Claim Task
+
+If a pre-created task exists for this capture (task ID provided in the capture message), claim it immediately (`TaskUpdate(taskId, status: "in_progress")`). After completing all vault writes for this capture, mark the task complete with a summary (count of items written + vault names). If no task ID was provided (ad-hoc messages), proceed without task tracking.
+
 ### Step 1: Read Context
 
 1. Read the WorkGroup file (`knowzcode/workgroups/{wgid}.md`) to extract relevant content for the phase
@@ -90,9 +100,11 @@ If multiple vaults match the target type, use the first one listed in `knowzcode
 
 For each target vault, apply its **Content Filter** to format the `create_knowledge` payload:
 
-- **Title**: Use the appropriate prefix (`Pattern:`, `Decision:`, `Workaround:`, `Performance:`, `Security:`, `Convention:`, `Scope:`, `Audit:`, `Integration:`, `Completion:`)
-- **Content**: Follow the content filter structure defined for the vault type
-- **Tags**: Include learning category, phase, and domain-relevant tags
+> **Content Detail Principle**: Vault entries are retrieved via semantic search, not read directly like local files. Every entry must be self-contained and detailed — include full reasoning, specific technology names, code examples, file paths, and error messages. A terse entry like `"[Risk] Medium"` is useless when retrieved months later. See `knowzcode/knowzcode_vaults.md` for the full principle and examples.
+
+- **Title**: Use the appropriate prefix (`Pattern:`, `Decision:`, `Workaround:`, `Performance:`, `Security:`, `Convention:`, `Scope:`, `Audit:`, `Integration:`, `Completion:`) followed by a descriptive summary including key technology names for search discoverability
+- **Content**: Follow the content filter structure defined for the vault type — fill every field with enough detail that the entry is useful without any other context
+- **Tags**: Include learning category, phase, domain-relevant tags, and specific technology names
 - **Source**: `KnowzCode WorkGroup {wgid}`
 
 ### Step 4: Dedup Check
@@ -107,49 +119,62 @@ Call `create_knowledge` with the formatted payload for each target vault.
 
 ### Phase 1A (Scope Approved)
 Extract from WorkGroup:
-- NodeIDs in the change set
-- Risk assessment
-- User approval decision
+- **NodeIDs**: List each with its description, affected files, and domain area
+- **Risk assessment**: Include the full reasoning — what could break, which files are high-risk, what mitigation is planned. Never write just "Medium"
+- **Scope decisions**: What was included/excluded and why — alternatives the user considered
 - Write to: `ecosystem` vault (or single vault)
 
 ### Phase 2A (Implementation Complete)
 Extract from WorkGroup:
-- Implementation patterns and workarounds discovered during build
-- New utilities or abstractions created
-- Performance optimizations applied
+- **Patterns discovered**: Describe the pattern, why it was needed, how it works, and include file paths or code snippets. E.g., "Created retry wrapper in src/utils/retry.ts using exponential backoff with jitter for all external API calls"
+- **Workarounds**: What limitation was hit, what the workaround does, and any upstream fix to watch for
+- **New utilities or abstractions**: What was created, its API surface, and where it's used
+- **Performance optimizations**: Before/after metrics, the technique used, and any trade-offs
 - Write to: `code` vault for patterns/workarounds/performance, `ecosystem` vault for decisions
 
 ### Phase 2B (Audit Complete)
 Extract from WorkGroup:
-- Audit score and findings
-- Security issues found
-- Gap resolution decisions
+- **Audit findings**: Completion percentage, specific gaps with file paths and line references
+- **Security issues**: Describe the vulnerability, affected code paths, severity reasoning, and how it was (or should be) fixed
+- **Gap resolution decisions**: What was deferred vs fixed, and the rationale for each decision
 - Write to: `ecosystem` vault for audit learnings, user's enterprise vault for audit trail (if configured + compliance enabled)
 
 ### Phase 3 (Finalization)
 Extract from WorkGroup:
-- Architectural learnings and consolidation decisions
-- Convention patterns established
-- Any remaining insight-worthy content
+- **Architectural learnings**: Structural discoveries, component relationships that weren't obvious, integration patterns that emerged
+- **Convention patterns established**: New team conventions with full rationale and examples
+- **Consolidation decisions**: What was merged or refactored during finalization and why
 - Write to: appropriate vault per learning category routing
 
 ## Communication
 
-- **Report to lead only on**: errors (MCP failures, vault not found) or dedup catches
-- **Silent on success** — do not broadcast write confirmations to the team
+- **Report to lead on**: errors (MCP failures, vault not found) or dedup catches
+- **Task-based confirmation**: Mark pre-created capture tasks complete with summary (count + vault names) — this is the primary confirmation mechanism
+- **Phase 3 DM confirmation REQUIRED**: After processing Phase 3, send confirmation DM to lead: `"Phase 3 capture complete: {N} items written to {vault names}"`
+- **Silent on success for other phases** — task completion is sufficient, do not broadcast
 - Respond to direct queries from teammates about what has been captured
 
 ## MCP Graceful Degradation
 
-If MCP calls fail:
-1. Log the failure
-2. Report the error to the lead via direct message
-3. Do not retry immediately — wait for the next capture request or lead instruction
-4. The workflow continues without vault writes
+If MCP calls fail or MCP is unavailable:
+1. **Queue locally**: Append the capture to `knowzcode/pending_captures.md` using this format:
+   ```markdown
+   ### {timestamp} — {title}
+   - **Intent**: {Phase capture | Log | Consider}
+   - **Category**: {Pattern|Decision|Workaround|Performance|Security|Convention}
+   - **Target Vault Type**: {code|ecosystem|enterprise|finalizations}
+   - **Source**: {agent name} / WorkGroup {wgid}
+   - **Content**: {description or extracted learning}
+   ```
+2. Report the MCP failure to the lead via DM: `"MCP unavailable — queued {N} capture(s) to pending_captures.md"`
+3. If MCP recovers mid-session, flush pending captures to vaults on the next capture request
+4. Mark the capture task complete (if task-tracked) with note: `"Queued locally — MCP unavailable"`
+
+Never drop knowledge. If MCP is down, queue it. The pending file can be flushed later via `/kc:learn --flush` or by a future scribe instance.
 
 ## Exit Expectations
 
-- All capture requests processed
-- Dedup catches reported to lead
-- Errors reported to lead
-- Ready for shutdown after closer completes
+- All capture tasks marked complete
+- Phase 3 confirmation DM sent to lead
+- Dedup catches and errors reported to lead
+- Ready for shutdown only after all capture tasks are complete

package/agents/project-advisor.md

@@ -69,10 +69,11 @@ Near the end of Stage 2 (before the gap loop), DM lead with structured proposals
 
 ## Knowz-Scribe Integration
 
-If knowz-scribe is active, DM it with idea captures:
-> "Capture idea: {description}. Category: {Pattern|Decision|Convention}. Source: WorkGroup {wgid}."
+If knowz-scribe is active, DM it with idea captures. Include enough detail for the scribe to write a rich vault entry — terse one-liners produce poor search results when stored in the vault.
 
-The scribe routes to the correct vault based on category.
+> "Log: {Detailed description including the specific technology, component, and rationale — e.g. 'Discovered that the Express auth middleware should validate JWT clockTolerance=0 to prevent revoked tokens being accepted during the tolerance window. Affects src/middleware/auth.ts and all protected routes.'}. Category: {Pattern|Decision|Convention}. Source: WorkGroup {wgid}."
+
+The scribe routes to the correct vault based on category. The more context you provide in the DM, the more useful the vault entry will be when retrieved via search months later.
 
 ## Enterprise Compliance (Optional)
 

package/commands/connect-mcp.md

@@ -88,9 +88,9 @@ Configure the KnowzCode MCP server using Claude Code's built-in MCP management.
    - Store parsed values for use in configuration
 
 2. **Check for existing configuration**
-   - Check if MCP server already configured: `claude mcp get knowzcode`
+   - Check if MCP server already configured: `CLAUDECODE= claude mcp get knowz`
    - If already configured, ask if user wants to reconfigure
-   - If yes, run `claude mcp remove knowzcode` first
+   - If yes, run `CLAUDECODE= claude mcp remove knowz` first
 
 3. **Prompt for API key (if not provided)**
    - If no API key in arguments, prompt user interactively:
@@ -308,14 +308,14 @@ Configure the KnowzCode MCP server using Claude Code's built-in MCP management.
    ```bash
    claude mcp add --transport http \
      --scope <chosen-scope> \
-     knowzcode \
+     knowz \
      <endpoint-url> \
      --header "Authorization: Bearer <api-key>" \
      --header "X-Project-Path: $(pwd)"
    ```
 
 8. **Verify configuration**
-   - Run: `claude mcp get knowzcode`
+   - Run: `CLAUDECODE= claude mcp get knowz`
    - Confirm server appears in the list
    - Check for any error messages
 
@@ -461,7 +461,7 @@ If using --dev environment, verify the dev server is running.
 To change from local to project scope:
 ```bash
 # Remove existing (or the command will prompt to reconfigure)
-claude mcp remove knowzcode
+CLAUDECODE= claude mcp remove knowz
 
 # Re-add with new scope
 /kc:connect-mcp <api-key> --scope project

package/commands/learn.md

@@ -182,6 +182,9 @@ Capture the provided insight to the appropriate vault using the MCP `create_know
      ```
 
 7. **Build learning content**
+
+   > Vault entries are retrieved via semantic search — content must be detailed and self-contained. See `knowzcode/knowzcode_vaults.md` Content Detail Principle.
+
    ```markdown
    [CONTEXT]
    Project: {project-name}
@@ -189,9 +192,11 @@ Capture the provided insight to the appropriate vault using the MCP `create_know
    Vault: {selected_vault_name}
    Source: {--source value or "KnowzCode /kc:learn command"}
    Date: {ISO timestamp}
+   Situation: {Expand on what prompted this learning — the problem being solved, the component involved, relevant technology stack. Provide enough background that someone unfamiliar with the project can understand.}
 
    [INSIGHT]
    {User's insight text}
+   Detail: {Expand the user's insight with technical specifics — include file paths, library names, version numbers, code patterns, or error messages that make this actionable when retrieved via search.}
 
    [SOURCE]
    Captured via /kc:learn command
@@ -202,7 +207,7 @@ Capture the provided insight to the appropriate vault using the MCP `create_know
    ```json
    create_knowledge({
      "content": "{formatted content}",
-     "title": "{Category}: {Brief summary from insight}",
+     "title": "{Category}: {Descriptive summary — include key technology names for search discoverability}",
      "knowledgeType": "Note",
      "vaultId": "{selected_vault_id}",
      "tags": ["{category}", "{extracted-tags}", "{project-name}"],

package/commands/register.md

@@ -111,7 +111,7 @@ YOU                              USER
 
 1. Check if MCP server already configured:
    ```bash
-   claude mcp get knowzcode
+   CLAUDECODE= claude mcp get knowz
    ```
 
 2. If already configured, display:
@@ -127,7 +127,7 @@ YOU                              USER
    ```
 
    Use AskUserQuestion to get user choice. If they choose to keep existing, STOP.
-   If they choose to continue, run `claude mcp remove knowzcode` first.
+   If they choose to continue, run `CLAUDECODE= claude mcp remove knowz` first.
 
 3. If not configured: Continue to Step 2.
 
@@ -330,7 +330,7 @@ curl -X POST https://api.dev.knowz.io/api/v1/auth/register \
    # Production (default)
    claude mcp add --transport http \
      --scope <chosen-scope> \
-     knowzcode \
+     knowz \
      https://mcp.knowz.io/mcp \
      --header "Authorization: Bearer <api_key>" \
      --header "X-Project-Path: $(pwd)"
@@ -338,7 +338,7 @@ curl -X POST https://api.dev.knowz.io/api/v1/auth/register \
    # Development (with --dev flag)
    claude mcp add --transport http \
      --scope <chosen-scope> \
-     knowzcode \
+     knowz \
      https://mcp.dev.knowz.io/mcp \
      --header "Authorization: Bearer <api_key>" \
      --header "X-Project-Path: $(pwd)"
@@ -346,7 +346,7 @@ curl -X POST https://api.dev.knowz.io/api/v1/auth/register \
 
 5. **Verify MCP configuration**:
    ```bash
-   claude mcp get knowzcode
+   CLAUDECODE= claude mcp get knowz
    ```
 
 6. **Configure vault in mcp_config.md**:

package/commands/status.md

@@ -41,7 +41,7 @@ Check Agent Teams status, then check the KnowzCode MCP server status, and report
 
 2. **Check MCP server configuration**
    ```bash
-   claude mcp get knowzcode
+   CLAUDECODE= claude mcp get knowz
    ```
 
    - If configured: Extract scope, endpoint, headers

package/commands/work.md

@@ -313,7 +313,10 @@ When Parallel Teams mode is active, follow these 4 stages instead of spawning on
 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 → set `MCP_ACTIVE = false`, announce `**MCP Status: Not connected**`, skip to Step 4
+   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
@@ -536,11 +539,16 @@ When Parallel Teams mode is active, follow these 4 stages instead of spawning on
    - Write ARC-Completion log entry
    - Review architecture docs for discrepancies
    - Schedule REFACTOR tasks for tech debt
-   - Send learnings to knowz-scribe (if active): `"Capture Phase 3: {wgid}"`. Knowz-scout remains available for vault queries during finalization.
+   - 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. Shut down knowz-scout, knowz-scribe (after Phase 3 capture completes), closer, and all remaining agents
-6. Delete team
+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)
 
@@ -592,6 +600,10 @@ When creating tasks, model the dependency chain with `addBlockedBy` and pre-assi
 | 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 |
 
 ---
 
@@ -601,6 +613,20 @@ When creating tasks, model the dependency chain with `addBlockedBy` and pre-assi
 
 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
@@ -743,7 +769,7 @@ Two temporary agents that scan the codebase in parallel with the analyst, broadc
 **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 inline by the lead.
+- *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`).
 
 ---
 
@@ -855,7 +881,8 @@ If `AUTONOMOUS_MODE = false`: If rejected — re-run analyst with user feedback.
 ### MCP Learning Capture (Optional)
 
 If MCP is configured and knowz-scribe is active, after Change Set approval:
-- Send message to **knowz-scribe**: `"Capture Phase 1A: {wgid}"` — the scribe reads the WorkGroup file, extracts scope/risk/decision data, and writes to the appropriate vault
+- 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
 
@@ -988,7 +1015,8 @@ When complete, present implementation summary including files changed, tests wri
 ### MCP Learning Capture (Optional)
 
 If MCP is configured and knowz-scribe is active, after implementation completes:
-- Send message to **knowz-scribe**: `"Capture Phase 2A: {wgid}"` — the scribe reads implementation results from the WorkGroup file and captures patterns, workarounds, and performance optimizations to the `code` vault
+- 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
 
 ---
 
@@ -1069,7 +1097,8 @@ If `AUTONOMOUS_MODE = false`: User decides — proceed / fix gaps / modify specs
 ### MCP Learning Capture (Optional)
 
 If MCP is configured and knowz-scribe is active, after audit approval:
-- Send message to **knowz-scribe**: `"Capture Phase 2B: {wgid}"` — the scribe reads audit results from the WorkGroup file and writes findings to the appropriate vault
+- 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
 
 ---
 
@@ -1077,7 +1106,7 @@ If MCP is configured and knowz-scribe is active, after audit approval:
 
 **Agent**: `closer` | **Loop.md**: Section 3.5
 
-**Spawn prompt**:
+**Spawn prompt (Parallel Teams)**:
 > You are the **closer** for WorkGroup `{wgid}`.
 > Read `agents/closer.md` for your full role definition.
 >
@@ -1089,18 +1118,33 @@ If MCP is configured and knowz-scribe is active, after audit approval:
 >
 > **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**: If knowz-scribe is active, send it `"Capture Phase 3: {wgid}"` to delegate learning capture and audit trail writes. Do NOT call `create_knowledge` directly.
+> **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). 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.
-- *Subagent*: `Task(subagent_type="closer", description="Phase 3 finalization", prompt=<above>)`
+- *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 sends a message to **knowz-scribe**: `"Capture Phase 3: {wgid}"` — the scribe reads the WorkGroup file, extracts learnings, decisions, and outcomes, and writes to the appropriate vaults
+- 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: