@goondocks/myco 0.6.4 → 0.9.0

package/dist/src/agent/definitions/tasks/full-intelligence.yaml

@@ -0,0 +1,472 @@
+# =============================================================================
+# Built-in Task: Full Intelligence (Phased)
+# =============================================================================
+# Default task for: myco-agent
+#
+# Complete intelligence pipeline using phased execution. Each phase is a
+# separate query() call with scoped tools and turn limits. The executor
+# controls the loop — the LLM cannot skip phases.
+# =============================================================================
+
+name: full-intelligence
+displayName: Full Intelligence
+description: >
+  Complete intelligence pass over all unprocessed session data. Extracts
+  observations as spores, updates session summaries, consolidates related
+  spores into wisdom, builds knowledge graph entities and edges, and
+  regenerates digest extracts.
+agent: myco-agent
+isDefault: true
+maxTurns: 130
+timeoutSeconds: 1800
+model: claude-sonnet-4-6
+
+orchestrator:
+  enabled: true
+  model: claude-sonnet-4-6
+  maxTurns: 3
+
+contextQueries:
+  pre-planning:
+    - tool: vault_unprocessed
+      queryTemplate: ""
+      limit: 5
+      purpose: "Check if there are unprocessed batches"
+      required: false
+    - tool: vault_state
+      queryTemplate: ""
+      limit: 10
+      purpose: "Get agent cursor state"
+      required: false
+    - tool: vault_spores
+      queryTemplate: ""
+      limit: 20
+      purpose: "Review recent spores for consolidation candidates"
+      required: false
+
+prompt: >
+  You are executing one phase of a multi-phase intelligence pipeline.
+  Each phase has its own scoped tools — only use the tools available to you.
+  Do NOT report on tools or work outside your current phase.
+  Focus on quality over quantity — one precise observation is worth more
+  than ten vague ones.
+
+phases:
+  - name: read-state
+    # Root phase — no dependsOn
+    prompt: |
+      Read the current vault state to determine what needs processing.
+
+      1. Call `vault_state` to get your cursor (`last_processed_batch_id`)
+      2. Call `vault_unprocessed` with `after_id` set to your cursor
+
+      If no unprocessed batches exist, report via `vault_report` with
+      action "skip" and reason "no unprocessed batches".
+    tools:
+      - vault_state
+      - vault_unprocessed
+      - vault_spores
+      - vault_report
+    maxTurns: 6
+    required: true
+
+  - name: extract
+    dependsOn: [read-state]
+    prompt: |
+      Extract observations from unprocessed batches as spores.
+      CRITICAL: the vault must stay sharp, not bloated. Supersede, don't duplicate.
+
+      If the prior phase reported no unprocessed batches, call `vault_report`
+      with action "skip" and reason "no unprocessed batches" and finish.
+
+      ## Step 1: Read batches and identify observations (budget: ~10 turns)
+
+      PASS 1: Read all batches via `vault_unprocessed`. For each, note candidate
+      insights as a mental list. Focus on genuine insights, not activity logs.
+
+      PASS 2: Group similar insights into topics. Batches often repeat the same
+      theme — group before searching to minimize tool calls.
+
+      ## Step 2: Search and create/supersede (budget: ~20 turns)
+
+      For each TOPIC you identified (not each batch — group first):
+      1. Call `vault_search_semantic` with the topic to check existing coverage
+      2. If a similar spore exists:
+         - If your observation adds meaningful new detail: create the new
+           spore, then supersede the old via `vault_resolve_spore`
+           action "supersede" with new_spore_id
+         - If your observation adds nothing new: skip it entirely
+      3. If no similar spore exists: create it as new
+      4. Mark the source batches as processed via `vault_mark_processed`
+
+      ## Step 3: Update cursor (budget: 1 turn)
+
+      Call `vault_set_state` to update `last_processed_batch_id`.
+
+      ## Quality rules
+      - One observation per spore — specific, not vague
+      - Include session_id, prompt_batch_id, importance 1-10, tags
+      - Supersede rather than duplicate — the vault gets sharper, not bigger
+      - Group batches by topic to minimize search calls
+      - If approaching the turn budget, stop and move on
+    tools:
+      - vault_unprocessed
+      - vault_spores
+      - vault_search_fts
+      - vault_search_semantic
+      - vault_create_spore
+      - vault_resolve_spore
+      - vault_mark_processed
+      - vault_set_state
+      - vault_report
+    maxTurns: 35
+    required: true
+
+  - name: summarize
+    dependsOn: [read-state]
+    prompt: |
+      Update session titles and summaries for sessions touched during extraction.
+
+      ## Step 1: Find sessions with new activity (budget: 2 turns)
+
+      1. Call `vault_unprocessed` — group batches by session_id. Each session
+         with unprocessed batches needs its summary updated.
+      2. Call `vault_sessions` to get existing titles/summaries for those sessions.
+
+      If no sessions have new activity, report "skip" and finish.
+
+      ## Step 2: Update each session (budget: 5 turns)
+
+      For each session with new batches:
+      1. Read the EXISTING title and summary — context from prior runs.
+      2. Read the NEW prompt batches (from Step 1) — user_prompt + response_summary.
+         This is your PRIMARY source. Understand the full arc of new work.
+      3. Generate an UPDATED title and summary incorporating both existing
+         context and new activity.
+
+      ## Step 3: Write updates (budget: 2 turns)
+
+      Call `vault_update_session` with BOTH title and summary.
+
+      ### Title Rules (CRITICAL)
+
+      The title describes WHAT WAS ACCOMPLISHED, not what was asked.
+      - Under 80 chars, sentence case
+      - Synthesize from the full arc of prompt batches, not just the first one
+      - NEVER use file paths, directory names, or working directory
+      - NEVER copy the user's first message as the title
+      - Good: "Wave-based parallel executor and per-task provider config"
+      - Bad: "/git-worktree" (directory path, not a title)
+
+      ### Summary Rules
+
+      2-4 sentences. Rich in detail — session summaries are embedded and used
+      for semantic search. Include: what was built/fixed, key files touched,
+      tools used, outcomes. Focus on what was accomplished across the FULL
+      session, not just the first or last prompt.
+
+      Report via `vault_report` with action "summary" for each update.
+      If no updates needed, report action "skip" with reason.
+    tools:
+      - vault_sessions
+      - vault_unprocessed
+      - vault_spores
+      - vault_update_session
+      - vault_report
+    maxTurns: 10
+    required: false
+
+  - name: consolidate
+    dependsOn: [extract]
+    prompt: |
+      Consolidate related spores into wisdom and clean up redundancy.
+      The vault must get SHARPER over time, not just bigger.
+
+      ## Step 1: Find clusters (budget: 5 turns)
+
+      1. Call `vault_spores` with each `observation_type` filter (gotcha, decision,
+         discovery, trade_off, bug_fix) to list spores by type
+      2. Call `vault_spores` with status "active" to see the full set
+      3. Look for 2+ spores covering the same topic or component
+      4. For candidate clusters, call `vault_search_semantic` to confirm
+         semantic similarity
+
+      ## Decision tree
+
+      - **3+ related active spores on same topic** → create wisdom, consolidate all
+      - **Exactly 2 related spores** → keep the better one, supersede the weaker
+      - **1 spore (no duplicates)** → no action
+
+      ## Step 2: Create wisdom (budget: 8 turns)
+
+      When you find 3+ related active spores on the same topic:
+      1. Create a wisdom spore via `vault_create_spore`:
+         - observation_type: "wisdom"
+         - properties: '{"consolidated_from": ["id-1", "id-2", "id-3"]}'
+         - Content MUST preserve ALL specific details from sources —
+           file paths, error messages, concrete values. Wisdom is a
+           comprehensive reference, not a vague summary.
+      2. Resolve EACH source via `vault_resolve_spore` action "consolidate"
+         — this removes them from search results and context injection
+
+      ## Step 3: Supersede stale spores (budget: 5 turns)
+
+      Also look for spores that are outdated or contradicted by newer ones:
+      - If two spores describe the same thing but one is more recent/detailed,
+        supersede the older one via `vault_resolve_spore` action "supersede"
+      - Superseded spores stay in the DB but are removed from search and
+        context injection — this keeps the vault relevant
+
+      Skip spores with status "consolidated" or "superseded" to prevent cycles.
+
+      If `vault_search_semantic` returns no results (embedding unavailable), report
+      action "skip" and move on.
+    tools:
+      - vault_spores
+      - vault_search_semantic
+      - vault_create_spore
+      - vault_resolve_spore
+      - vault_report
+    maxTurns: 22
+    required: false
+
+  - name: graph
+    dependsOn: [extract]
+    prompt: |
+      Build the knowledge graph: create entities, then link spores to them.
+
+      The graph has two layers:
+      - Lineage (automatic): spore→session, spore→batch — already done
+      - Semantic (your job): spore→entity, entity→entity — you create these
+
+      ## Step 1: Review spores and existing entities (2 turns)
+
+      1. Call `vault_spores` with status "active" to see current spores
+      2. Call `vault_entities` to see existing graph entities
+      3. Call `vault_edges` to see existing relationships
+
+      ## Step 2: Create entities (budget: 6 turns)
+
+      For components/concepts/people that appear across multiple spores:
+      - Call `vault_create_entity` with type: component | concept | person
+      - Focus on entities that help understand the system architecture
+      - Prefer fewer well-defined entities over many vague ones
+
+      ## Step 3: Link spores to entities (budget: 12 turns) — CRITICAL
+
+      For EACH entity (newly created AND existing unlinked ones):
+      1. Call `vault_search_semantic` with the entity name to find related spores
+      2. Before creating an edge, call `vault_edges` with `source_id` and
+         `target_id` to verify it does not already exist
+      3. For each relevant search result, call `vault_create_edge`:
+         - type: REFERENCES
+         - source_id: the spore ID, source_type: spore
+         - target_id: the entity ID, target_type: entity
+      4. Entities without edges are invisible — always link after creating
+
+      ## Step 4: Structural edges between entities (remaining turns)
+
+      For architectural dependencies between entities:
+      - DEPENDS_ON (entity→entity): "daemon" depends on "SQLite"
+      - AFFECTS (spore→entity): a gotcha that impacts a component
+
+      Do NOT create lineage edges (FROM_SESSION, EXTRACTED_FROM, etc.)
+
+      Call `vault_report` with action "graph" reporting:
+      - Entities created: N
+      - Spore→entity REFERENCES edges: N
+      - Entity→entity structural edges: N
+    tools:
+      - vault_spores
+      - vault_sessions
+      - vault_search_semantic
+      - vault_entities
+      - vault_edges
+      - vault_create_entity
+      - vault_create_edge
+      - vault_report
+    maxTurns: 25
+    required: false
+
+  # ---- Digest: assess + 3 parallel tier writes ----
+  # The assess phase gathers context, then each tier runs independently
+  # in the same wave via Promise.allSettled().
+
+  - name: digest-assess
+    dependsOn: [consolidate]
+    prompt: |
+      Assess current digest state and gather material for tier updates.
+      The 3 digest tier phases run in parallel after you — your summary
+      is their primary input. Be thorough.
+
+      ## Step 1: Check current state (budget: 2 turns)
+
+      Call `vault_read_digest` (no tier param) to see current digest state.
+      Note each tier's `generated_at` timestamp — this tells you how fresh
+      each tier is. Review the prior phase results (in your context):
+      - How many spores were created/superseded?
+      - How many entities/edges were added?
+
+      If changes are minor (< 3 new spores, 0 entity changes), call
+      `vault_report` with action "skip" and reason explaining why the
+      current digest is still sufficient. STOP.
+
+      ## Step 2: Gather new material (budget: 5 turns)
+
+      Search for material relevant to what changed:
+      1. Call `vault_search_semantic` with themes from newly created/superseded
+         spores and new entity names
+      2. Call `vault_spores` to see recently created observations
+      3. Call `vault_sessions` for recent session context
+
+      ## Step 3: Produce detailed findings
+
+      Your final response is critical — the per-tier phases see it as their
+      primary context (they cannot call vault_spores or vault_sessions).
+      Structure your summary as:
+
+      **New material to integrate:**
+      - List each new insight, decision, pattern, gotcha with enough detail
+        that a tier writer can incorporate it without re-searching
+      - Include specific spore content, not just "3 new spores were created"
+
+      **Themes and connections:**
+      - What overarching themes connect the new material?
+      - What existing digest sections are affected?
+
+      **Per-tier freshness and guidance:**
+      For each tier, state whether it should UPDATE or SKIP based on both
+      the volume of new material AND the tier's `generated_at` freshness:
+      - A tier written < 30 minutes ago with only minor changes → SKIP
+      - A tier written hours ago or with significant changes → UPDATE
+      - Larger tiers (10000) tolerate more frequent updates since
+        they have room for incremental additions
+      - Smaller tiers (1500) should only update for material that
+        genuinely changes the executive picture
+
+      Per-tier directives:
+      - 10000: UPDATE/SKIP + what to add (any new content)
+      - 5000: UPDATE/SKIP + what to add (trade-offs and patterns)
+      - 1500: UPDATE/SKIP + what to add (only critical changes)
+    tools:
+      - vault_spores
+      - vault_sessions
+      - vault_search_semantic
+      - vault_read_digest
+      - vault_report
+    maxTurns: 8
+    required: true
+
+  - name: digest-10000
+    dependsOn: [digest-assess]
+    prompt: |
+      Update digest tier 10000 — Full institutional knowledge.
+      Budget: 7 turns (1 read + 1-2 search + 1 write + buffer).
+
+      This is the largest tier (~10,000 tokens). Update if any new content
+      was found. The digest-assess phase summary in your context contains
+      the material to integrate and per-tier guidance.
+
+      1. Call `vault_read_digest` with tier 10000 to get current content
+      2. Call `vault_search_semantic` for themes identified in the assess
+         findings — gather specific details to weave in
+      3. Integrate new material into the existing digest
+      4. Call `vault_write_digest` with the updated content
+
+      The existing digest is your baseline — integrate new material, don't
+      rewrite from scratch. Preserve well-crafted existing content.
+
+      Prioritize: recent insights > active decisions > unresolved gotchas >
+      architectural patterns > historical context.
+
+      If this tier genuinely has no new material to integrate, call
+      `vault_report` with action "skip" for this tier.
+    tools:
+      - vault_search_semantic
+      - vault_read_digest
+      - vault_write_digest
+      - vault_report
+    maxTurns: 7
+    required: false
+
+  - name: digest-5000
+    dependsOn: [digest-assess]
+    prompt: |
+      Update digest tier 5000 — Deep onboarding.
+      Budget: 5 turns (1 read + 1 search + 1 write + buffer).
+
+      This tier (~5,000 tokens) focuses on trade-offs and patterns. The
+      digest-assess phase summary in your context contains the material
+      to integrate and per-tier guidance.
+
+      1. Call `vault_read_digest` with tier 5000 to get current content
+      2. Optionally call `vault_search_semantic` for additional context
+      3. Integrate new material from the assess findings
+      4. Call `vault_write_digest` with the updated content
+
+      The existing digest is your baseline — integrate new material, don't
+      rewrite from scratch. Preserve well-crafted existing content.
+
+      Prioritize: recent insights > active decisions > unresolved gotchas >
+      architectural patterns > historical context.
+
+      If this tier genuinely has no new material to integrate, call
+      `vault_report` with action "skip" for this tier.
+    tools:
+      - vault_search_semantic
+      - vault_read_digest
+      - vault_write_digest
+      - vault_report
+    maxTurns: 5
+    required: false
+
+  - name: digest-1500
+    dependsOn: [digest-assess]
+    prompt: |
+      Update digest tier 1500 — Executive briefing.
+      Budget: 3 turns (1 read + 1 write + buffer).
+
+      This is the most compressed tier (~1,500 tokens). Only update if
+      important new decisions, gotchas, or critical changes were found.
+      The digest-assess phase summary in your context contains the material
+      to integrate and per-tier guidance.
+
+      1. Call `vault_read_digest` with tier 1500 to get current content
+      2. Integrate new material from the assess findings — be very selective,
+         only critical changes belong at this tier
+      3. Call `vault_write_digest` with the updated content
+
+      The existing digest is your baseline — integrate new material, don't
+      rewrite from scratch. Preserve well-crafted existing content.
+
+      Prioritize: recent insights > active decisions > unresolved gotchas >
+      architectural patterns > historical context.
+
+      If this tier genuinely has no new material to integrate, call
+      `vault_report` with action "skip" for this tier.
+    tools:
+      - vault_read_digest
+      - vault_write_digest
+      - vault_report
+    maxTurns: 3
+    required: false
+
+  - name: report
+    dependsOn: [extract, summarize, consolidate, graph, digest-assess, digest-10000, digest-5000, digest-1500]
+    skipPriorContext: true
+    prompt: |
+      Summarize what was done across all phases.
+
+      Call `vault_report` with action "complete" and these details:
+      - Batches processed: N
+      - Spores created: N (by type)
+      - Sessions updated: N
+      - Wisdom created: N
+      - Entities created: N, edges created: N
+      - Digest tiers written: N
+
+      This report MUST be the last tool call of the run.
+    tools:
+      - vault_report
+    maxTurns: 3
+    required: true

package/dist/src/agent/definitions/tasks/graph-maintenance.yaml

@@ -0,0 +1,92 @@
+# =============================================================================
+# Built-in Task: Graph Maintenance
+# =============================================================================
+# Scan existing spores to build/update entities and semantic edges.
+# Does not extract new spores or regenerate digest.
+# =============================================================================
+
+name: graph-maintenance
+displayName: Graph Maintenance
+description: >
+  Scan existing spores and sessions to update the knowledge graph. Adds
+  missing entities and semantic edges, merges duplicates. Does not extract
+  new spores or regenerate digest.
+agent: myco-agent
+isDefault: false
+maxTurns: 40
+timeoutSeconds: 480
+
+prompt: |
+  Maintain the knowledge graph from existing spores. Budget: ~35 turns.
+
+  ## Phase 1 — Inventory (budget: 3 turns)
+
+  1. Call `vault_state` for context
+  2. Call `vault_spores` with status "active" to see current observations
+  3. Call `vault_entities` to see existing entities
+  4. Call `vault_edges` to check existing relationships
+
+  ## Phase 2 — Entity Discovery (budget: 15 turns)
+
+  Call `vault_entities` to see existing entities before creating new ones.
+
+  Scan active spores for entity candidates:
+  1. For each candidate: count distinct `session_id` values across spores
+     mentioning it. Only create if referenced in 2+ sessions AND 3+ spores.
+  2. Check `vault_entities` results — if the entity already exists, skip it
+  3. Call `vault_create_entity` for each valid NEW candidate:
+     - type: component | concept | person
+     - name: specific, named thing (not abstract categories)
+  4. Good: "DaemonClient", "cursor-based pagination", "Chris"
+  5. Bad: "testing phase", "technical debt", "code quality"
+
+  ## Phase 3 — Semantic Edges (budget: 10 turns)
+
+  Link spores and entities with semantic edges. For each entity:
+  1. Call `vault_search_semantic` with the entity name to find spores that discuss it
+  2. For each relevant spore found, call `vault_create_edge`:
+     - type: REFERENCES
+     - source_id: the spore ID, source_type: spore
+     - target_id: the entity ID, target_type: entity
+  3. Before creating any edge, call `vault_edges` with source_id and target_id
+     to verify it does not already exist — avoid creating duplicate edges
+     for the same (source, type, target) triple
+
+  Also create structural edges between entities:
+  - DEPENDS_ON (entity→entity): architectural dependencies
+  - AFFECTS (spore→entity): when an observation directly impacts a component
+  - RELATES_TO: general semantic connections
+
+  Always include source_type and target_type on every edge.
+  Do NOT create lineage edges (FROM_SESSION, EXTRACTED_FROM, etc.).
+  Entities without any edges are invisible in the graph — always link after
+  creating.
+
+  ## Phase 4 — Deduplication (budget: 5 turns)
+
+  Call `vault_entities` to list all entities. Look for entities of the same
+  type with similar names (e.g., "DaemonClient" and "daemon-client", or
+  "SQLite" and "sqlite-vec"):
+  1. Compare entity names within each type for near-duplicates
+  2. Use `vault_search_semantic` to confirm semantic similarity if unsure
+  3. If duplicates found, keep the better-named one and note the issue
+     via `vault_report`
+
+  ## Phase 5 — Report (budget: 2 turns)
+
+  Call `vault_report` with action "graph":
+  - Entities created: N (by type)
+  - Edges created: N (by type)
+  - Duplicates found: N
+
+toolOverrides:
+  - vault_spores
+  - vault_sessions
+  - vault_search_semantic
+  - vault_state
+  - vault_entities
+  - vault_edges
+  - vault_create_entity
+  - vault_create_edge
+  - vault_set_state
+  - vault_report

package/dist/src/agent/definitions/tasks/review-session.yaml

@@ -0,0 +1,132 @@
+# =============================================================================
+# Built-in Task: Review Session
+# =============================================================================
+# Targeted end-to-end pass over a single session: extract spores, build
+# graph entities and edges, run supersession checks, update title/summary.
+# =============================================================================
+
+name: review-session
+displayName: Review Session
+description: >
+  Process a single session end-to-end. Extracts spores from all prompt
+  batches in the session, builds graph entities and edges, runs supersession
+  checks, and generates the session title and summary.
+agent: myco-agent
+isDefault: false
+maxTurns: 40
+timeoutSeconds: 480
+
+prompt: |
+  Review the specified session end-to-end. Budget: ~35 turns.
+
+  Target session: {{session_id}}
+
+  ## Phase 1 — Read State (budget: 3 turns)
+
+  1. Call `vault_state` to get current cursor and context
+  2. Call `vault_sessions` to find the target session and its current
+     title/summary/processed status
+  3. Call `vault_unprocessed` to get all unprocessed batches — note which
+     ones belong to the target session (by matching session_id in the batch data)
+
+  If no unprocessed batches belong to this session, call `vault_report` with
+  action "skip" and reason "no unprocessed batches for session", then stop.
+  Only process batches from the target session — ignore batches from other sessions.
+
+  ## Phase 2 — Extract Spores (budget: 15 turns)
+
+  Extract observations from all unprocessed batches in this session.
+  CRITICAL: the vault must stay sharp, not bloated — supersede, don't duplicate.
+
+  1. Read all batch content first — understand the full scope of the session
+  2. Group candidate observations by TOPIC across all batches
+  3. Call `vault_spores` to see existing spores for context
+
+  For each TOPIC group:
+  1. Call `vault_search_semantic` with the topic to find existing spores that
+     already cover this topic
+  2. If a similar spore exists:
+     - If your observation adds meaningful new detail: call `vault_create_spore`
+       then supersede the old via `vault_resolve_spore` action "supersede"
+       with new_spore_id
+     - If your observation adds nothing new: skip it entirely
+  3. If no similar spore exists: call `vault_create_spore` with session_id,
+     prompt_batch_id, importance 1-10, and relevant tags
+
+  After processing all batches: call `vault_mark_processed` for each batch,
+  then call `vault_set_state` to update the cursor.
+
+  ## Phase 3 — Graph (budget: 10 turns)
+
+  Build entities and semantic edges for knowledge discovered in this session.
+
+  1. Call `vault_spores` to review the spores just created plus existing ones
+  2. Call `vault_entities` and `vault_edges` to see what already exists
+  3. Check `vault_spores` for cross-session references before creating entities.
+     Only create entities referenced in 2+ sessions. For a single-session review,
+     this means the entity must also appear in spores from OTHER sessions.
+  4. For valid entity candidates:
+     - Call `vault_create_entity` with type: component | concept | person
+     - Good: "DaemonClient", "cursor-based pagination" — specific named things
+     - Bad: "testing phase", "code quality" — abstract categories
+  5. For each entity (new and existing relevant ones):
+     - Call `vault_search_semantic` with the entity name to find related spores
+     - Before creating, call `vault_edges` with source_id and target_id to
+       check if the edge already exists
+     - Call `vault_create_edge` with type REFERENCES, source_type spore,
+       target_type entity for each relevant spore
+  6. Create structural edges: DEPENDS_ON (entity→entity), AFFECTS (spore→entity)
+
+  Always include source_type and target_type on every edge.
+  Do NOT create lineage edges (FROM_SESSION, EXTRACTED_FROM, etc.).
+
+  ## Phase 4 — Supersession Check (budget: 3 turns)
+
+  Scan active spores for newly introduced redundancy:
+  1. Call `vault_spores` with status "active" to see the current set
+  2. For any spores that are now outdated or contradicted by the newly created
+     ones, call `vault_resolve_spore` with action "supersede" or "archive"
+  3. Only supersede when the new information genuinely replaces the old;
+     when in doubt, keep both
+
+  ## Phase 5 — Title & Summary (budget: 3 turns)
+
+  1. Call `vault_sessions` to check the current title and summary
+  2. Review the prompt batches you processed in Phase 2 — use user_prompt
+     and response_summary as your PRIMARY source for the title and summary.
+     Call `vault_spores` with `session_id` as supplemental context.
+  3. Call `vault_update_session` with BOTH title and summary
+
+  Title: describes WHAT WAS ACCOMPLISHED (under 80 chars, sentence case).
+  NEVER use file paths, directory names, or the user's first message as title.
+  Good: "SQLite migration with FTS5 and vector embeddings"
+  Bad: "/git-worktree", "Help me fix the bug in..."
+  Summary: 2-4 sentences on key work done + outcomes.
+
+  ## Phase 6 — Report (budget: 1 turn)
+
+  Call `vault_report` with action "complete":
+  - Session reviewed: {{session_id}}
+  - Batches processed: N
+  - Spores created: N (by type)
+  - Spores superseded: N
+  - Entities created: N, edges created: N
+  - Title/summary updated: yes/no
+
+toolOverrides:
+  - vault_unprocessed
+  - vault_spores
+  - vault_sessions
+  - vault_search_fts
+  - vault_search_semantic
+  - vault_entities
+  - vault_edges
+  - vault_create_spore
+  - vault_resolve_spore
+  - vault_create_entity
+  - vault_create_edge
+  - vault_update_session
+  - vault_mark_processed
+  - vault_set_state
+  - vault_state
+  - vault_report