@goondocks/myco 0.20.2 → 0.21.1

package/dist/src/agent/definitions/tasks/{full-intelligence.yaml → vault-evolve.yaml}

@@ -1,5 +1,5 @@
 # =============================================================================
-# Built-in Task: Full Intelligence (Phased)
+# Built-in Task: Vault Evolve (Phased)
 # =============================================================================
 # Default task for: myco-agent
 #
@@ -8,18 +8,18 @@
 # controls the loop — the LLM cannot skip phases.
 # =============================================================================
 
-name: full-intelligence
-displayName: Full Intelligence
+name: vault-evolve
+displayName: Vault Evolve
 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.
+  spores into wisdom, and regenerates digest extracts. Runs automatically
+  on a schedule once sessions have settled.
 agent: myco-agent
 isDefault: true
 maxTurns: 150
 timeoutSeconds: 1800
-model: claude-sonnet-4-6
+reasoningLevel: default
 
 schedule:
   enabled: true
@@ -31,7 +31,7 @@ schedule:
 
 orchestrator:
   enabled: true
-  model: claude-sonnet-4-6
+  reasoningLevel: default
   maxTurns: 3
 
 contextQueries:
@@ -61,7 +61,7 @@ prompt: >
 
 phases:
   - name: read-state
-    model: claude-haiku-4-5-20251001
+    reasoningLevel: low
     # Root phase — no dependsOn
     prompt: |
       Read the current vault state to determine what needs processing.
@@ -81,7 +81,7 @@ phases:
     readOnly: true
 
   - name: extract
-    model: claude-haiku-4-5-20251001
+    reasoningLevel: low
     dependsOn: [read-state]
     prompt: |
       Extract observations from unprocessed batches as spores.
@@ -134,7 +134,7 @@ phases:
     required: true
 
   - name: summarize
-    model: claude-haiku-4-5-20251001
+    reasoningLevel: low
     dependsOn: [read-state]
     prompt: |
       Update session titles and summaries for sessions touched during extraction.
@@ -189,7 +189,7 @@ phases:
     required: false
 
   - name: consolidate
-    model: claude-sonnet-4-6
+    reasoningLevel: default
     dependsOn: [extract]
     prompt: |
       Consolidate related spores into wisdom and clean up redundancy.
@@ -254,143 +254,89 @@ phases:
     maxTurns: 25
     required: false
 
-  - name: graph
-    model: claude-sonnet-4-6
-    dependsOn: [extract]
+  # ---- 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
+    reasoningLevel: default
+    dependsOn: [consolidate]
     prompt: |
-      Build the knowledge graph: create entities, then link spores to them.
+      Gather material for AT MOST ONE digest tier update per run. The
+      rotation decision is made by the `vault_read_digest` tool, not
+      by you — the tool returns which tier needs attention (or tells
+      you to skip). Over 3 runs every tier gets one deep pass.
 
-      New graph work may still be warranted even when extract skipped, because
-      spores and entities can be created by coding agents or manual curation.
-      Focus on recent or high-signal active spores and obvious entity gaps.
-      If a quick review shows no meaningful new graph work, report "skip".
+      Total budget: {{max_turns}} turns.
 
-      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: Get the rotation decision (1 turn)
 
-      ## Step 1: Review spores and existing entities (2 turns)
+      Call `vault_read_digest` with:
+        pick: "rotate_oldest"
+        min_staleness_seconds: 1800
 
-      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
+      The tool returns one of two shapes:
 
-      ## Step 2: Create entities (budget: 6 turns)
+      **Skip shape** — `{mode:"rotate_oldest", skip:true, reason, all_tiers}`.
+      Every tier was generated within the last 30 minutes. Call
+      `vault_report` with action "skip" passing the reason through.
+      STOP — do not run steps 2-3.
 
-      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
+      **Rotate shape** — `{mode:"rotate_oldest", selected_tier,
+      selected_generated_at, selected_content, rotation_reason, all_tiers}`.
+      Proceed to step 2, scoped to `selected_tier`.
 
-      ## Step 3: Link spores to entities (budget: 12 turns) — CRITICAL
+      ## Step 2: Gather material for `selected_tier` (budget: half
+      of remaining)
 
-      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
+      Scope the search to what belongs at the selected tier:
+      - **1500 (executive briefing):** only critical decisions,
+        reversals, state-of-system changes.
+      - **5000 (deep onboarding):** trade-offs, patterns, active
+        decisions, unresolved gotchas.
+      - **10000 (full archive):** any new content worth preserving.
 
-      ## Step 4: Structural edges between entities (remaining turns)
+      Use `vault_search_semantic` for themes from new/superseded spores,
+      `vault_spores` for specific content, `vault_sessions` for recent
+      session context. Make each call count — do not repeatedly search
+      for variations of the same theme. Accept "good enough" findings
+      and move on.
 
-      For architectural dependencies between entities:
-      - DEPENDS_ON (entity→entity): "daemon" depends on "SQLite"
-      - AFFECTS (spore→entity): a gotcha that impacts a component
+      ## Step 3: Produce findings
 
-      Do NOT create lineage edges (FROM_SESSION, EXTRACTED_FROM, etc.)
+      Your final response is the per-tier phases' primary context
+      (they cannot call vault_spores or vault_sessions). Structure it:
 
-      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: 35
-    required: false
+      **Chosen tier for this run: <selected_tier>**
+      Include the rotation_reason verbatim from the tool so readers
+      can audit the decision.
 
-  # ---- Digest: assess + 3 parallel tier writes ----
-  # The assess phase gathers context, then each tier runs independently
-  # in the same wave via Promise.allSettled().
+      **New material to integrate (scoped to the chosen tier):**
+      - List each insight with enough detail that the tier writer can
+        incorporate it without re-searching
+      - Include specific spore content, not just spore counts
 
-  - name: digest-assess
-    model: claude-sonnet-4-6
-    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?
-      - Did consolidate or graph act on externally-created spores or entities?
-
-      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)
+      **Themes and connections** relevant to the chosen tier.
+
+      **Per-tier directives** — mark exactly the `selected_tier` as
+      UPDATE, the other two as SKIP, and include the tool's
+      rotation_reason in the UPDATE line:
+      - 10000: UPDATE or SKIP + one-line reason
+      - 5000: UPDATE or SKIP + one-line reason
+      - 1500: UPDATE or SKIP + one-line reason
+
+      Tools available: {{phase_tools}}.
     tools:
       - vault_spores
       - vault_sessions
       - vault_search_semantic
       - vault_read_digest
       - vault_report
-    maxTurns: 10
+    maxTurns: 12
     required: true
 
   - name: digest-10000
-    model: claude-haiku-4-5-20251001
+    reasoningLevel: low
     dependsOn: [digest-assess]
     prompt: |
       Update digest tier 10000 — Full institutional knowledge.
@@ -427,7 +373,7 @@ phases:
     required: false
 
   - name: digest-5000
-    model: claude-haiku-4-5-20251001
+    reasoningLevel: low
     dependsOn: [digest-assess]
     prompt: |
       Update digest tier 5000 — Deep onboarding.
@@ -463,7 +409,7 @@ phases:
     required: false
 
   - name: digest-1500
-    model: claude-haiku-4-5-20251001
+    reasoningLevel: low
     dependsOn: [digest-assess]
     prompt: |
       Update digest tier 1500 — Executive briefing.
@@ -499,8 +445,8 @@ phases:
     required: false
 
   - name: report
-    model: claude-haiku-4-5-20251001
-    dependsOn: [extract, summarize, consolidate, graph, digest-assess, digest-10000, digest-5000, digest-1500]
+    reasoningLevel: low
+    dependsOn: [extract, summarize, consolidate, digest-assess, digest-10000, digest-5000, digest-1500]
     prompt: |
       Summarize what was done across all phases.
 
@@ -509,7 +455,6 @@ phases:
       - 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.

package/dist/src/agent/definitions/tasks/vault-seed.yaml

@@ -0,0 +1,370 @@
+# =============================================================================
+# Built-in Task: Vault Seed (Phased)
+# =============================================================================
+# Manual-only task for: myco-agent
+#
+# One-shot seeding pass for brownfield codebases. Unlike vault-evolve,
+# which processes session transcripts, vault-seed infers knowledge
+# directly from source files using filesystem + grep tools. Intended to
+# be run when adopting Myco on an existing repo — fills the vault with
+# an initial spore set and digest so the assistant has useful context
+# from day one.
+# =============================================================================
+
+name: vault-seed
+displayName: Vault Seed
+description: >
+  One-shot seeding pass for a brownfield codebase. Explores the project
+  with filesystem and grep tools, identifies architectural patterns,
+  conventions, and gotchas, then populates the vault with an initial
+  spore set and a starter digest. Manual trigger only — no session data
+  required.
+agent: myco-agent
+isDefault: false
+maxTurns: 300
+timeoutSeconds: 3600
+reasoningLevel: default
+
+# No schedule — always manual. Running automatically would re-seed an
+# already-populated vault.
+
+prompt: >
+  You are running a one-shot seeding pass over a brownfield codebase.
+  There are no session transcripts to process — infer knowledge directly
+  from source. Focus on architectural patterns, conventions, trade-offs,
+  and gotchas that a new developer or agent onboarding to this code
+  would benefit from. Quality over quantity — one precise observation is
+  worth more than ten vague ones.
+
+  IMPORTANT: the pipeline is phased, and each phase has a different
+  tool surface. Early phases explore source with filesystem tools;
+  later phases write observations to the vault using vault_* tools.
+  Each phase's prompt lists the tools it has. Trust that list and call
+  those tools directly. Do not rationalize that a declared tool is
+  "unavailable" based on what earlier phases used.
+
+phases:
+  - name: orient
+    reasoningLevel: default
+    readOnly: true
+    prompt: |
+      **Your ONLY job this phase: produce a 3-8 item theme list from
+      surface signals.** You are NOT verifying themes, NOT reading
+      implementation, and NOT building a comprehensive understanding.
+      That work belongs to the next phase (explore-themes), which has
+      a much larger budget and is designed for it.
+
+      **Hard turn budget: {{max_turns}}.** Each tool call costs one
+      turn. If you exhaust the budget before calling `vault_report`
+      with the theme list, this phase fails and blocks the rest of
+      the pipeline. Treat the budget as a constraint, not a suggestion
+      — finish well under it.
+
+      **Scope guard:** if you find yourself opening a file under
+      `packages/*/src/**`, `src/**`, `lib/**`, or any implementation
+      directory, STOP. That is explore-themes's job. Orient reads
+      top-level metadata and docs only.
+
+      ## Exact tool plan (budget: ~8 tool calls total)
+
+      Call ONLY these tools, in this order. Do NOT add calls.
+
+      1. `fs_tree` at `.` with depth=1 — 1 call, 1 turn.
+      2. `fs_read` the README (no line window) — 1 call, 1 turn.
+      3. `fs_read` the primary manifest (package.json / pyproject.toml /
+         Cargo.toml / go.mod / Gemfile / pom.xml — pick the one that
+         exists, skip if unclear) — 0 or 1 call.
+      4. `fs_list` at `.` — 1 call, 1 turn. After this call you have
+         seen every top-level tooling signal. DO NOT list additional
+         directories in this phase; recursive layout exploration is
+         explore-themes's job.
+      5. (Optional) `fs_list` on `docs/` — 0 or 1 call. If you do, then
+         `fs_read` AT MOST 2 files that clearly look like architecture
+         or overview docs — max 2 more calls.
+      6. `vault_report` with action "orient" and the theme list — 1
+         call. This is your last tool call. The phase ends here.
+
+      Skipping steps is fine. Adding steps is not. If you are tempted
+      to list a subdirectory to "see what's inside it," resist —
+      explore-themes will do that with more budget.
+
+      **Frugality:** every tool response comes back as tokens on your
+      next turn's input. Narrow calls keep the budget healthy.
+
+      ## Output: theme outline
+
+      From those surface signals alone, name 3-8 themes worth deeper
+      exploration in the next phase. Name them confidently even if you
+      don't have full evidence yet — the next phase will verify them.
+      Good themes:
+      - major architectural layers ("agent harness", "daemon", "UI")
+      - cross-cutting domain concepts ("team sync", "session lifecycle")
+      - notable integration points ("MCP server", "SQLite vault")
+      - conventions worth surfacing (testing style, error handling)
+
+      Avoid generic themes like "TypeScript code" or "tests exist".
+
+      Call `vault_report` with action "orient" and the structured theme
+      list. This is your final tool call for this phase.
+    tools:
+      - fs_tree
+      - fs_list
+      - fs_read
+      - vault_report
+    maxTurns: 25
+    required: true
+
+  - name: explore-themes
+    reasoningLevel: default
+    readOnly: true
+    dependsOn: [orient]
+    prompt: |
+      For each theme identified in the orient phase, drill down with
+      `code_grep` and targeted `fs_read` calls. Collect specific,
+      concrete observations that would survive the code evolving.
+
+      ## Strategy (budget: 4-6 turns per theme)
+
+      For each theme:
+      1. `code_grep` for signature patterns — class/interface names,
+         distinctive function names, keywords. Use a `glob` filter when
+         the language is known (e.g., `*.ts`, `*.py`).
+      2. `fs_read` the 2-4 most informative files you find. Prefer
+         cross-cutting modules over leaf files.
+      3. Note 3-6 concrete observations for the theme. Anchor each to
+         file paths or function names.
+
+      ## What makes a good observation
+
+      - Anchored to specific file paths, function names, or patterns
+      - Captures trade-offs, gotchas, or non-obvious invariants
+      - Explains WHY when the reasoning is evident from the code
+      - Would be useful to an agent or developer onboarding
+
+      ## What to skip
+
+      - Boilerplate (standard manifest fields, generated code)
+      - Implementation details that change frequently
+      - Things obvious from the README
+      - Generic advice ("use TypeScript") — only observations specific to
+        THIS codebase belong in the vault
+
+      ## Output
+
+      Produce a structured summary grouped by theme, focused on
+      OBSERVATIONS (the conclusions) rather than a log of what you did.
+      Write the summary as if a separate agent will read it cold and
+      turn each observation into a durable note. Avoid phrases like
+      "I ran fs_tree on…" or "I read the README" — name the observation
+      and anchor it to specific paths. The seed-spores phase runs with
+      a different tool surface and should not be primed to expect
+      filesystem access.
+
+      Call `vault_report` with action "explore" and the structured result.
+    tools:
+      - fs_tree
+      - fs_list
+      - fs_read
+      - code_grep
+      - vault_report
+    maxTurns: 120
+    required: true
+
+  - name: seed-spores
+    reasoningLevel: default
+    dependsOn: [explore-themes]
+    prompt: |
+      Create spores for the observations from the explore phase.
+
+      **Hard turn budget: {{max_turns}}.** Each tool call costs one
+      turn. Every observation needs one `vault_create_spore` call;
+      budget your work accordingly.
+
+      ## Your tools this phase
+
+      You have these tools and ONLY these tools: {{phase_tools}}.
+      They are registered and available. Call them directly. Do NOT
+      verify or second-guess. Filesystem tools from earlier phases
+      are not needed here — the explore-themes summary in your
+      context contains everything you need to create spores.
+
+      ## Step 1: Re-seed check (1 tool call)
+
+      This phase runs on cold vaults AND on vaults that have been
+      seeded before. Call `vault_search_semantic` ONCE with a broad
+      query derived from the strongest theme (e.g. the name of the
+      highest-signal architectural layer from the explore summary).
+
+      - If the search returns several high-similarity results (many
+        scores > 0.85), the vault is already populated. Call
+        `vault_report` with action "skip" and reason "vault already
+        populated" and STOP. Do not create duplicate spores.
+      - If the search returns nothing or only low-similarity results
+        (typical for a cold vault with no embeddings, or a vault with
+        unrelated prior content), proceed to Step 2.
+
+      Do NOT run per-observation similarity searches — dedup across
+      existing spores is the job of the separate consolidation task,
+      not seed-spores. One broad re-seed check is enough.
+
+      ## Step 2: Create spores (the bulk of your budget)
+
+      For each observation in the explore summary, call
+      `vault_create_spore` with:
+      - observation_type: "decision", "pattern", "wisdom", "gotcha",
+        or "architecture" based on what the observation captures
+      - content: the full observation — concrete and specific
+      - importance: 1-10 (10 = load-bearing architectural invariant,
+        3 = minor stylistic preference)
+      - tags: 2-4 tags covering theme and domain
+      - file_path: the primary source file when the observation
+        anchors to one specific location
+      - session_id: null (no session provenance — this is seed data)
+      - prompt_batch_id: null
+      - context: "Seeded from vault-seed exploration pass"
+
+      ## Quality rules
+
+      - One observation per spore — specific, not vague
+      - Prefer fewer, higher-signal spores over many low-signal ones
+      - Target: 10-40 spores per seed run. If the exploration produced
+        far more candidates, prioritize by importance and drop the rest
+        rather than creating everything
+      - Observations anchored to specific file paths are stronger than
+        abstract statements
+    tools:
+      - vault_search_semantic
+      - vault_create_spore
+      - vault_report
+    maxTurns: 80
+    required: true
+
+  # ---- Digest tiers (parallel after seed-spores) ----
+  # Mirrors the vault-evolve pattern: three tiers writing in the same
+  # wave after seeding completes.
+
+  - name: digest-10000
+    reasoningLevel: default
+    dependsOn: [seed-spores]
+    prompt: |
+      Write digest tier 10000 — Full institutional knowledge (~10k tokens).
+
+      ## Your tools this phase
+
+      You have these tools and ONLY these tools:
+      `vault_spores`, `vault_search_semantic`, `vault_read_digest`,
+      `vault_write_digest`, `vault_report`. They are registered and
+      available. Call them directly. Filesystem tools from earlier
+      phases are NOT in scope here — the spores created in seed-spores
+      contain everything you need.
+
+      If the seed-spores phase short-circuited with "vault already populated",
+      call `vault_report` with action "skip" for tier 10000 and finish.
+
+      1. Call `vault_read_digest` with tier 10000 to see any existing content.
+         If this is a first seed run, it will be empty.
+      2. Call `vault_spores` with status "active" to read the freshly seeded
+         observations.
+      3. Organize the digest around the themes from the explore phase.
+         Include concrete file paths and function names. A reader should
+         come away with a thorough picture of the architecture, key
+         decisions, and gotchas.
+      4. Call `vault_write_digest` with tier 10000.
+
+      If the existing digest already contains comparable content (re-seed
+      case), integrate rather than overwrite — preserve well-crafted text.
+    tools:
+      - vault_spores
+      - vault_search_semantic
+      - vault_read_digest
+      - vault_write_digest
+      - vault_report
+    maxTurns: 15
+    required: false
+
+  - name: digest-5000
+    reasoningLevel: default
+    dependsOn: [seed-spores]
+    prompt: |
+      Write digest tier 5000 — Deep onboarding (~5k tokens).
+
+      ## Your tools this phase
+
+      You have these tools and ONLY these tools:
+      `vault_spores`, `vault_read_digest`, `vault_write_digest`,
+      `vault_report`. They are registered and available. Call them
+      directly. Filesystem tools from earlier phases are NOT in scope.
+
+      If the seed-spores phase short-circuited, call `vault_report` with
+      action "skip" for tier 5000 and finish.
+
+      This tier focuses on trade-offs and patterns — what a developer
+      needs after the README but before diving into code.
+
+      1. Call `vault_read_digest` with tier 5000 for the baseline.
+      2. Call `vault_spores` as the primary source (digest-10000 may still
+         be in-flight — don't depend on it).
+      3. Call `vault_write_digest` with tier 5000. Trim and synthesize;
+         this tier is a compression of tier 10000's material.
+    tools:
+      - vault_spores
+      - vault_read_digest
+      - vault_write_digest
+      - vault_report
+    maxTurns: 12
+    required: false
+
+  - name: digest-1500
+    reasoningLevel: default
+    dependsOn: [seed-spores]
+    prompt: |
+      Write digest tier 1500 — Executive briefing (~1.5k tokens).
+
+      ## Your tools this phase
+
+      You have these tools and ONLY these tools:
+      `vault_spores`, `vault_read_digest`, `vault_write_digest`,
+      `vault_report`. They are registered and available. Call them
+      directly. Filesystem tools from earlier phases are NOT in scope.
+
+      If the seed-spores phase short-circuited, call `vault_report` with
+      action "skip" for tier 1500 and finish.
+
+      The tightest tier: what someone needs to know in 2 minutes.
+      Architectural overview in 1-2 sentences, 2-3 load-bearing decisions,
+      the critical gotchas. Ruthlessly selective.
+
+      1. Call `vault_spores` filtered to importance >= 8 to find the
+         top-signal observations.
+      2. Call `vault_write_digest` with tier 1500.
+    tools:
+      - vault_spores
+      - vault_read_digest
+      - vault_write_digest
+      - vault_report
+    maxTurns: 8
+    required: false
+
+  - name: report
+    reasoningLevel: low
+    dependsOn: [seed-spores, digest-10000, digest-5000, digest-1500]
+    prompt: |
+      Summarize the seeding pass.
+
+      Your only tool this phase is `vault_report`. Call it — it is
+      registered and available.
+
+      Call `vault_report` with action "complete" and these details:
+      - Themes explored: N
+      - Spores created: N (by type)
+      - Spores superseded: N
+      - Digest tiers written: [list]
+      - Thin coverage: any themes where the exploration surfaced fewer than
+        3 observations — surface these so the user can follow up with a
+        targeted review-session or additional manual curation
+
+      This report MUST be the last tool call of the run.
+    tools:
+      - vault_report
+    maxTurns: 5
+    required: true