@dug-21/unimatrix 0.5.5

package/skills/uni-retro/SKILL.md

@@ -0,0 +1,296 @@
+---
+name: "uni-retro"
+description: "Post-merge retrospective — extracts patterns, procedures, and lessons from shipped features into Unimatrix. Use after a feature PR is merged."
+---
+
+# Retro — Post-Merge Knowledge Extraction
+
+## What This Skill Does
+
+Analyzes a shipped feature and extracts reusable knowledge — patterns, procedures, and lessons — into Unimatrix. This is how the project learns.
+
+---
+
+## Inputs
+
+From the invoker:
+- Feature ID (e.g., `col-011`)
+- PR number (merged)
+- GH Issue number
+
+---
+
+## Phase 1: Data Gathering & Retrospective Analysis
+
+Gather all evidence about the shipped feature:
+
+1. **Run retrospective analysis** (if observation data exists):
+   ```
+   mcp__unimatrix__context_retrospective(feature_cycle: "{feature-id}")
+   ```
+   This returns structured data: metrics, hotspots, baseline comparisons, narratives, and recommendations.
+
+2. **Analyze the retrospective data** — extract actionable findings:
+
+   a. **Hotspots by severity** — Classify each hotspot:
+      - `Warning` hotspots → potential lessons or procedure gaps
+      - `Info` hotspots → note trends, may not need action
+      - Key hotspot types to watch:
+        - `permission_retries` → settings.json allowlist may need updating
+        - `sleep_workarounds` → agents using sleep instead of run_in_background
+        - `cold_restart` → context loss after gaps, agents re-reading files
+        - `coordinator_respawns` → SM lifetime/handoff issues
+        - `post_completion_work` → significant work after task marked done (scope issue?)
+        - `lifespan` → agent running too long (context overflow risk)
+        - `mutation_spread` → touching too many files (coupling/scope creep?)
+        - `file_breadth` / `reread_rate` → agents inefficiently navigating codebase
+
+   b. **Baseline outliers** — Any metric with `status: "Outlier"` deserves attention:
+      - Is it a positive shift (e.g., higher `parallel_call_rate`)? Note as trend.
+      - Is it a problem (e.g., high `post_completion_work`)? Extract lesson.
+      - Is it a `NewSignal`? First time this metric has a non-zero value — note for future tracking.
+
+   c. **Recommendations** — The retrospective returns specific actionable recommendations.
+      Each one maps to either a procedure update or a lesson learned.
+
+   d. **Narratives** — Temporal clustering of events. Look for:
+      - Burst patterns (many events in short window → agent struggling)
+      - Sequence patterns (repeated cycles → inefficient workflow)
+      - Top files (which files caused the most friction)
+
+3. **Read feature artifacts**:
+   - `product/features/{id}/architecture/ARCHITECTURE.md`
+   - `product/features/{id}/pseudocode/OVERVIEW.md`
+   - `product/features/{id}/testing/RISK-COVERAGE-REPORT.md`
+   - `product/features/{id}/reports/gate-3a-report.md`
+   - `product/features/{id}/reports/gate-3b-report.md`
+   - `product/features/{id}/reports/gate-3c-report.md`
+
+4. **Check for rework signals**: Did any gate fail before passing? Read the gate report for what went wrong.
+
+5. **Review the git log** for this feature's branch:
+   ```bash
+   git log main..HEAD --oneline
+   ```
+   Look for rework commits (`fix(gate):`) — these indicate where the process struggled.
+
+---
+
+## Phase 1b: Stewardship Quality Review
+
+Before extracting new patterns, review the quality of entries agents stored during this feature cycle.
+
+1. **Query entries stored during the feature**:
+   ```
+   mcp__unimatrix__context_search(
+     query: "{feature-id}",
+     k: 20
+   )
+   ```
+   Also search by feature_cycle tag if available. Use content/title matching as fallback — not all agents tag consistently.
+
+2. **Assess each entry against its category template**:
+   - **Patterns**: Has what/why/scope structure? Is "why" substantive (not "it works")?
+   - **Lessons**: Has what-happened/root-cause/takeaway? Is takeaway actionable?
+   - **Procedures**: Has numbered steps? Are steps specific (not generic)?
+
+3. **Curate**:
+   - **Low-quality entries** (missing structure, no substantive "why", API docs disguised as patterns): deprecate via `context_deprecate` with reason.
+   - **High-quality entries** confirmed by successful delivery: note for the architect to validate during pattern extraction.
+   - **Miscategorized entries** (lesson stored as pattern, or vice versa): note for correction.
+
+4. **Report** the stewardship review results before proceeding to Phase 2:
+   ```
+   Stewardship Quality Review:
+   - Entries found: {N}
+   - Quality: {N} good, {N} deprecated (low quality), {N} flagged for recategorization
+   - Details: {list each entry with assessment}
+   ```
+
+---
+
+## Phase 2: Pattern & Procedure Extraction (MUST be a subagent)
+
+**Before spawning the architect**, prepare a structured retrospective briefing from Phase 1. This replaces the vague "paste summary" — give the architect concrete data to work with.
+
+Build the briefing:
+
+```
+RETROSPECTIVE BRIEFING for {feature-id}
+========================================
+
+Session stats: {session_count} sessions, {total_records} records, {total_tool_calls} tool calls, {total_duration_secs}s
+
+HOTSPOTS ({count} detected):
+{For each hotspot: "- [{severity}] {rule_name}: {claim} (measured: {measured}, threshold: {threshold})"}
+
+BASELINE OUTLIERS:
+{For each baseline entry with status "Outlier" or "NewSignal":
+  "- {metric_name}: {current_value} vs mean {mean} (stddev {stddev}) — {status}"}
+
+RECOMMENDATIONS FROM RETROSPECTIVE:
+{For each recommendation: "- [{hotspot_type}] {action} — {rationale}"}
+
+REWORK SIGNALS:
+{gate failures, rework commits from Phase 1 step 4-5}
+```
+
+Spawn `uni-architect` to review what was built and extract reusable knowledge:
+
+```
+Agent(uni-architect, "
+  Your agent ID: {feature-id}-retro-architect
+  Your Unimatrix agent_id: uni-architect
+  MODE: retrospective (not design)
+  Feature: {feature-id}
+
+  You are reviewing a SHIPPED feature to extract reusable knowledge.
+  You are NOT designing anything new.
+
+  Read these artifacts:
+  - product/features/{id}/architecture/ARCHITECTURE.md
+  - product/features/{id}/pseudocode/OVERVIEW.md (component structure)
+  - product/features/{id}/reports/gate-3a-report.md (design review)
+  - product/features/{id}/reports/gate-3b-report.md (code review)
+  - product/features/{id}/reports/gate-3c-report.md (risk validation)
+  - product/features/{id}/testing/RISK-COVERAGE-REPORT.md
+
+  {paste the RETROSPECTIVE BRIEFING from above}
+
+  YOUR TASKS:
+
+  1. PATTERN EXTRACTION — For each component implemented:
+     a. Use /uni-query-patterns to find existing patterns for the affected crate(s)
+     b. If the component followed an existing pattern: verify it's still accurate.
+        If the pattern drifted, use /uni-store-procedure or context_correct to update it.
+     c. If the component established a NEW reusable structure (used in 2+ features
+        or clearly generic): store it via context_store(category: 'pattern').
+     d. If the component was one-off: skip — don't store patterns for unique work.
+
+  2. PROCEDURE REVIEW — Check if any HOW-TO changed:
+     a. Did the build/test/integration process change?
+     b. Did schema migration steps change?
+     c. Was there a new technique that future developers need?
+     If yes: use /uni-store-procedure (new) or context_correct (update existing).
+
+  3. ADR VALIDATION — For each ADR created during this feature:
+     a. Was the decision validated by successful implementation?
+     b. Did implementation reveal that an ADR was wrong or incomplete?
+        If so: flag for supersession (do NOT supersede without human approval).
+
+  4. LESSON EXTRACTION — Two sources:
+
+     A. From gate failures and rework:
+        a. What went wrong? (root cause, not symptoms)
+        b. Is the lesson generalizable beyond this feature?
+        c. If yes: use /uni-store-lesson.
+
+     B. From retrospective hotspots and recommendations:
+        For each Warning-severity hotspot, ask:
+        - Is this a recurring problem (check baseline — is it consistently above threshold)?
+        - Can it be prevented by a procedure change or config update?
+        - If yes: store as lesson (/uni-store-lesson) or procedure (/uni-store-procedure).
+
+        For each recommendation from the retrospective:
+        - Check if a matching procedure already exists (/uni-query-patterns).
+        - If not, and the recommendation is actionable: store as procedure.
+        - If it updates existing guidance: use context_correct.
+
+     C. From baseline outliers:
+        - Positive outliers (improvements): note what changed and why — may be a new pattern.
+        - Negative outliers (regressions): root-cause and store as lesson if generalizable.
+
+  Return:
+  1. Patterns: [new entries with IDs, updated entries with IDs, skipped with reason]
+  2. Procedures: [new/updated with IDs]
+  3. ADR status: [validated ADRs, flagged-for-supersession ADRs with reason]
+  4. Lessons: [new entries with IDs]
+  5. Retrospective findings: [hotspot-derived lessons, recommendation actions taken, outlier notes]")
+```
+
+---
+
+## Phase 3: ADR Supersession (if flagged)
+
+If the architect flagged any ADRs for supersession:
+
+1. Present each flagged ADR to the human:
+   ```
+   ADR #{entry-id}: "{title}"
+   Architect's finding: {why it should be superseded}
+   Proposed replacement: {what the new decision should be}
+
+   Approve supersession?
+   ```
+
+2. If human approves: spawn architect to perform the supersession via `/uni-store-adr`.
+3. If human disagrees: note as "ADR validated with caveat".
+
+---
+
+## Phase 4: Worktree Cleanup
+
+Worker agents spawned with `isolation: "worktree"` create directories under `.claude/worktrees/`. Each contains a full `target/` build directory (~1-2GB). Clean up after merge.
+
+```bash
+# List worktrees to find stale agent-created ones
+git worktree list
+
+# Remove each stale worktree (safe — feature is merged)
+git worktree remove .claude/worktrees/{agent-id}/ 2>/dev/null
+
+# Prune stale entries
+git worktree prune
+```
+
+If a worktree has uncommitted changes, warn the human — do NOT force-remove.
+
+---
+
+## Phase 5: Summary & Outcome
+
+Collect all knowledge base changes from Phases 2-3.
+
+Use `/uni-record-outcome` with:
+- Feature: `{feature-id}`
+- Type: `retro`
+- Phase: `retro`
+- Result: `pass`
+- Content: `Retrospective complete. {N} patterns, {N} procedures, {N} lessons extracted. {N} ADRs validated. Hotspots: {count} ({warning_count} warnings). Outliers: {list outlier metric names}.`
+
+**Return format:**
+```
+RETROSPECTIVE COMPLETE — Knowledge base updated.
+
+Feature: {feature-id}
+PR: #{pr-number} (merged)
+
+Retrospective summary:
+- Sessions: {session_count}, Tool calls: {total_tool_calls}, Duration: {duration}
+- Hotspots: {count} ({warning_count} warnings, {info_count} info)
+- Baseline outliers: {list metric names and status}
+
+Knowledge extracted:
+- Patterns: {count} new, {count} updated
+- Procedures: {count} new, {count} updated
+- Lessons learned: {count} new ({count} from hotspots, {count} from gate failures)
+- ADRs validated: {count}
+- ADRs superseded: {count}
+
+Details:
+{list each entry with Unimatrix ID, title, and whether new or updated}
+```
+
+---
+
+## When to Go Lightweight
+
+Not every feature needs a full retro:
+
+| Situation | Action |
+|---|---|
+| Zero gate failures, no rework, zero hotspots | Skip lesson extraction. Focus on patterns/procedures only. |
+| Minor enhancement (1-2 components) | Check for pattern drift only, skip procedure review. |
+| New infrastructure introduced | Full retro — high likelihood of new patterns and procedures. |
+| Multiple SCOPE FAILs or heavy rework | Full retro — prioritize lesson extraction. |
+| Many Warning hotspots or baseline outliers | Full retro — prioritize hotspot-driven lessons and procedure updates. |

package/skills/uni-review-pr/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: "uni-review-pr"
+description: "PR security review and merge readiness check. Use after delivery or bugfix opens a PR, or standalone when human wants to review a PR."
+---
+
+# Review PR — Security Review + Merge Readiness
+
+## What This Skill Does
+
+Verifies gate results, spawns a fresh-context security reviewer, and assesses merge readiness. Works as:
+- **Auto-invoked** by `uni-scrum-master` at the end of delivery/bugfix protocols
+- **Standalone** when human invokes `/uni-review-pr {pr-number}` directly
+
+---
+
+## Inputs
+
+From the invoker (SM or human):
+- PR number or URL
+- Feature ID (if available)
+- GH Issue number (if available)
+
+If invoked standalone with just a PR number, extract feature ID and GH Issue from the PR body.
+
+---
+
+## Step 1: Verify Gate Results
+
+Read the feature directory for gate reports:
+
+- `product/features/{id}/reports/gate-3a-report.md` — exists and shows PASS
+- `product/features/{id}/reports/gate-3b-report.md` — exists and shows PASS
+- `product/features/{id}/reports/gate-3c-report.md` — exists and shows PASS
+- `product/features/{id}/testing/RISK-COVERAGE-REPORT.md` — exists
+
+For bugfix PRs, check for the single gate report instead.
+
+If any gate report is missing or shows FAIL, **stop and report** — delivery is incomplete.
+
+---
+
+## Step 2: Security Review (Fresh Context — MUST be a subagent)
+
+Spawn `uni-security-reviewer` as a subagent for fresh-context review:
+
+```
+Agent(uni-security-reviewer, "
+  Your agent ID: {feature-id}-security-reviewer
+  Your Unimatrix agent_id: uni-security-reviewer
+  SECURITY REVIEW — Fresh context. Read the PR diff cold.
+
+  PR: #{pr-number} on branch {branch-name}
+  Feature: {feature-id}
+  GH Issue: #{issue-number}
+
+  Read these with fresh eyes:
+  - git diff main...HEAD (the full change set)
+  - product/features/{id}/architecture/ARCHITECTURE.md (if exists)
+  - product/features/{id}/RISK-TEST-STRATEGY.md (if exists)
+
+  Assess:
+  - OWASP concerns: injection, access control, deserialization, input validation
+  - Blast radius: worst case if code has a subtle bug
+  - Regression risk: could this break existing functionality
+  - Dependency safety: new dependencies, known vulnerabilities
+  - Secrets: no hardcoded credentials, tokens, or keys
+
+  Comment findings on the PR via gh CLI.
+  If any finding is blocking: use gh pr review --request-changes.
+
+  Return: risk level (low/medium/high/critical), findings summary,
+  blocking findings (yes/no + details).")
+```
+
+---
+
+## Step 3: Merge Readiness Assessment
+
+After security review returns, check all criteria:
+
+- [ ] All delivery gates passed (from gate reports)
+- [ ] Security review completed — no blocking findings
+- [ ] PR description references GH Issue
+- [ ] No merge conflicts with main
+
+If all pass → `Merge readiness: READY`
+If any blocking item → `Merge readiness: BLOCKED` with specific items listed
+
+---
+
+## Step 4: Report
+
+Post security review result to GH Issue:
+```
+## Security Review — {PASS|BLOCKED}
+- Summary: {risk level} — {findings summary}
+- Merge readiness: {READY|BLOCKED}
+- Issues: [blocking items if any]
+```
+
+**Return format** (to SM or human):
+```
+PR REVIEW COMPLETE
+
+PR: {URL}
+Feature: {feature-id}
+
+Security Review: {risk level} — {summary}
+Blocking findings: {yes/no + details}
+Merge readiness: {READY | BLOCKED}
+
+If BLOCKED:
+- Blocking items: [list]
+- Recommended action: [fix items or discuss]
+
+Human action required: Approve and merge, or address blocking items.
+```
+
+---
+
+## Step 5: Record Outcome
+
+Use `/uni-record-outcome` with:
+- Feature: `{feature-id}`
+- Type: `feature` (or `bugfix`)
+- Phase: `review`
+- Result: `pass` (or `blocked`)
+- Content: `PR review complete. Security: {risk level}. Merge readiness: {READY|BLOCKED}.`

package/skills/uni-seed/SKILL.md

@@ -0,0 +1,271 @@
+---
+name: "uni-seed"
+description: "Populate Unimatrix with foundational repository knowledge through human-directed, gated exploration."
+---
+
+# /uni-seed — Knowledge Base Seeding
+
+## Prerequisites
+
+Before running this skill:
+
+1. **MCP server running**: The Unimatrix MCP server (`unimatrix-server`) must be running and wired in your Claude Code `settings.json`. This skill calls `context_status`, `context_search`, and `context_store` — all require an operational MCP server.
+2. **Recommended**: Run `/uni-init` first to set up the CLAUDE.md knowledge block. Seeding works without it, but the CLAUDE.md block provides ongoing awareness.
+
+If `context_status` fails at startup, the MCP server is not available. Consult the installation documentation for wiring setup.
+
+---
+
+## What This Skill Does
+
+Guides you through populating Unimatrix with foundational knowledge about your repository. The skill explores your repo structure in bounded levels, proposes knowledge entries, and stores only what you approve.
+
+**Depth limit**: Level 0 (automatic) + up to 2 opt-in levels. No deeper. You control how far to go.
+
+**Categories used**: Only `convention`, `pattern`, and `procedure`. Categories like `decision`, `outcome`, and `lesson-learned` are excluded from seeding — they emerge from real feature work, not initial exploration.
+
+---
+
+## Entry Quality Rules
+
+Every proposed entry must pass this quality gate before being shown to you. Entries that fail are silently discarded — you only see quality entries.
+
+| Field | Rule |
+|-------|------|
+| **What** | One sentence, max 200 characters. Describes the knowledge. |
+| **Why** | Min 10 characters. Explains the consequence or motivation — what goes wrong without this knowledge. Must not be tautological (restating "what" without adding value). |
+| **Scope** | Where this applies — component, module, or workflow context. Must be present. |
+
+---
+
+## Execution Steps
+
+Follow these steps in strict order. At every gate marked with **STOP**, halt and wait for the human to respond before proceeding. Do not auto-advance.
+
+### Step 1: Pre-flight — MCP Availability Check
+
+**This must be the very first action. Do not read any files before this step.**
+
+Call `context_status()`.
+
+- **If the call fails or returns an error**: Print the following and halt immediately. Do not proceed to any further steps.
+  ```
+  Unimatrix MCP is not available.
+  Ensure unimatrix-server is running and wired in your Claude settings.json.
+  See installation documentation for setup instructions.
+  ```
+
+- **If the response is healthy** (no error indicators, returns system status): Continue to Step 2.
+
+---
+
+### Step 2: Existing-Entries Check
+
+Check whether seed entries already exist to avoid near-duplicates.
+
+Call `context_search` for each seeding category:
+- `context_search(query: "repository", category: "convention", k: 5)`
+- `context_search(query: "repository", category: "pattern", k: 5)`
+- `context_search(query: "repository", category: "procedure", k: 5)`
+
+Count the total results across all three searches.
+
+**If 3 or more entries found**:
+
+Print:
+```
+Found {count} existing entries in seeding categories (convention/pattern/procedure).
+Re-seeding may create near-duplicates. You can save tokens by skipping if the knowledge base already has a good foundation.
+
+Options:
+  supplement — continue and add new knowledge alongside existing entries
+  skip — exit without changes
+```
+
+**STOP. Wait for human response before proceeding.**
+
+- If the human says **skip**: Print "No changes made." and halt.
+- If the human says **supplement**: Continue to Step 3.
+
+**If fewer than 3 entries found**: Continue to Step 3 (clean first run).
+
+---
+
+### Step 3: Level 0 — Automatic Foundational Exploration
+
+Read the following files without requiring human confirmation. Skip any that do not exist:
+
+- `README.md`
+- `CLAUDE.md`
+- `Cargo.toml` (Rust)
+- `package.json` (Node.js)
+- `pyproject.toml` (Python)
+- `go.mod` (Go)
+- List the `.claude/` directory structure (if present) — directory listing only, not deep file reads
+
+From what you read, generate 2 to 4 high-level foundational entries. Typical entries cover:
+
+- **Repository purpose**: What this project does and why it exists
+- **Technology stack**: Primary language, framework, key dependencies
+- **Project structure**: How the codebase is organized (monorepo, workspace, key directories)
+- **Key conventions**: Any obvious conventions visible in top-level config (naming, formatting, etc.)
+
+Apply the quality gate (What/Why/Scope) to each candidate. Silently discard any that fail. If fewer than 2 entries pass the gate, include only what passes — do not pad with low-quality entries.
+
+If 0 entries pass the quality gate:
+```
+Could not generate quality entries from available files. Consider adding a README.md with project context, then re-run /uni-seed.
+```
+Skip to the Done summary.
+
+---
+
+### Step 4: Gate 0 — Batch Approval
+
+Present all Level 0 entries as a batch:
+
+```
+Level 0 — Foundational Knowledge
+=================================
+Proposed entries (approve or reject as a batch):
+
+  1. [convention] {what}
+     Why: {why}
+     Scope: {scope}
+
+  2. [pattern] {what}
+     Why: {why}
+     Scope: {scope}
+
+  ...
+
+Approve all entries? (approve / reject)
+```
+
+**STOP. Wait for human response before proceeding.**
+
+- **If approved**: Store each entry via `context_store`:
+  ```
+  context_store(
+    title: "{what}",
+    content: "What: {what}\nWhy: {why}\nScope: {scope}",
+    topic: "{repo name or top-level context}",
+    category: "{convention|pattern|procedure}",
+    tags: ["seed", "level-0"],
+    agent_id: "uni-seed"
+  )
+  ```
+  Report success or failure for each entry individually. If a `context_store` call fails, report which entry failed and continue storing the remaining entries.
+
+  Print: "Stored {count} entries."
+
+- **If rejected**: Print "0 entries stored. Re-invoke /uni-seed with more specific guidance if needed." and skip to the Done summary.
+
+After storing (or rejecting), present the Level 1 exploration menu:
+
+```
+Would you like to explore deeper? Options:
+  a) Module structure — explore source directories and key modules
+  b) Conventions — look for coding standards, linting, formatting config
+  c) Build & test — explore build system, test framework, CI config
+  d) Done — stop here
+```
+
+**STOP. Wait for human response before proceeding.**
+
+- If the human selects one or more options (a, b, c, or combinations): Continue to Step 5 with those selections.
+- If the human selects **d (Done)**: Skip to the Done summary.
+
+---
+
+### Step 5: Level 1 — Category Exploration (Opt-in)
+
+For each category the human selected, explore relevant files:
+
+- **Module structure**: Read `src/` or `lib/` directory listings, key module entry points, workspace member crates
+- **Conventions**: Read `.editorconfig`, `.eslintrc`, `rustfmt.toml`, `.clippy.toml`, `.prettierrc`, similar config files
+- **Build & test**: Read CI config (`.github/workflows/`, `Makefile`, `justfile`), test directory structure, build scripts
+
+For each entry generated from exploration, apply the quality gate. For entries that pass, present them **individually** (not as a batch):
+
+```
+Proposed entry:
+  [{category}] {what}
+  Why: {why}
+  Scope: {scope}
+
+Store this entry? (yes / no)
+```
+
+**STOP. Wait for human response before proceeding.**
+
+- **yes**: Store via `context_store` with tags `["seed", "level-1"]`. Report success or failure.
+- **no**: Skip this entry.
+
+Continue until all Level 1 entries have been presented.
+
+---
+
+### Step 6: Gate 1 — Level 2 Decision
+
+```
+Level 1 complete. Stored {count} new entries.
+
+Level 2 is the final exploration level. Would you like to go deeper into any area?
+  a) {list deeper explorations based on Level 1 selections — e.g., "specific module internals", "test patterns", "CI pipeline details"}
+  b) Done — stop here
+```
+
+**STOP. Wait for human response before proceeding.**
+
+- If the human selects a deeper exploration: Continue to Step 7.
+- If the human selects **Done**: Skip to the Done summary.
+
+---
+
+### Step 7: Level 2 — Deep Exploration (Final Level)
+
+Explore the selected areas in greater depth. Read specific files within the directories explored at Level 1.
+
+For each entry generated, apply the quality gate and present individually (same as Level 1):
+
+```
+Proposed entry:
+  [{category}] {what}
+  Why: {why}
+  Scope: {scope}
+
+Store this entry? (yes / no)
+```
+
+**STOP. Wait for human response before proceeding.**
+
+Store approved entries with tags `["seed", "level-2"]`.
+
+---
+
+### Step 8: Gate 2 — Terminal
+
+After Level 2 entries are processed:
+
+```
+Level 2 complete. This is the final exploration level. No further levels are available.
+```
+
+Proceed directly to the Done summary. **Do not offer a Level 3 option. Level 2 is the terminal level.**
+
+---
+
+### Done Summary
+
+```
+Seed Summary
+============
+Total entries stored: {total}
+  Level 0: {l0_count}
+  Level 1: {l1_count}
+  Level 2: {l2_count}
+
+Knowledge base is ready. Future context_briefing calls will return these entries
+to agents working in this repository.
+```