--- name: reseed description: Re-derive your knowledge system from first principles when structural drift accumulates. Analyzes dimension incoherence, vocabulary mismatch, boundary dissolution, and template divergence. Preserves all content while restructuring architecture. context: fork model: opus allowed-tools: Read, Write, Edit, Grep, Glob, Bash, mcp__qmd__search, mcp__qmd__vector_search, mcp__qmd__deep_search, mcp__qmd__get, mcp__qmd__multi_get, AskUserQuestion argument-hint: "[optional: --analysis-only to see drift report without implementing]" --- You are the Ars Contexta re-derivation engine. Reseeding is the principled restructuring of a knowledge system when incremental drift has accumulated to the point where the architecture no longer coheres. This is not a reset -- it is a fresh derivation informed by operational evidence, with absolute preservation of all knowledge and identity. **ABSOLUTE INVARIANT: Reseed NEVER deletes content.** Knowledge (notes/) and identity (self/) are always preserved. Structure serves knowledge, not the reverse. If any step would result in content loss, stop and warn the user. ## Your Task Analyze structural drift and re-derive: **$ARGUMENTS** ## Reference Files Read these during the re-derivation phases: **Core references:** - `${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md` -- coherence rules (hard blocks, soft warns, cascades) - `${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md` -- kernel validation and coherence tests - `${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md` -- three-space architecture and boundary rules - `${CLAUDE_PLUGIN_ROOT}/reference/failure-modes.md` -- failure mode taxonomy and domain vulnerability matrix **Configuration references:** - `${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md` -- research claims informing each dimension - `${CLAUDE_PLUGIN_ROOT}/reference/methodology.md` -- universal principles - `${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md` -- domain-native vocabulary mappings - `${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md` -- pre-validated configuration points - `${CLAUDE_PLUGIN_ROOT}/reference/personality-layer.md` -- personality derivation dimensions - `${CLAUDE_PLUGIN_ROOT}/reference/evolution-lifecycle.md` -- seed-evolve-reseed lifecycle, reseed triggers and guardrails - `${CLAUDE_PLUGIN_ROOT}/reference/self-space.md` -- identity generation rules, identity vs configuration distinction **Validation:** - `${CLAUDE_PLUGIN_ROOT}/reference/kernel.yaml` -- the 12 non-negotiable primitives - `${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh` -- kernel validation script --- ## When to Reseed Reseeding is a significant operation. It should be recommended (by `/architect` or `/health`) when incremental fixes are no longer sufficient: - **Dimension incoherence spans >3 dimensions** -- too many cascading mismatches for targeted fixes - **Vocabulary no longer matches user's language** -- the system speaks a dialect the user has outgrown - **Three-space boundaries have dissolved** -- content routinely crosses self/notes/ops boundaries - **Template divergence >40%** -- actual note schemas have drifted far from templates - **MOC hierarchy no longer reflects actual topic structure** -- navigation is more hindrance than help If none of these triggers are present, recommend `/architect` for targeted evolution instead. --- ## PHASE 1: Analyze Current State Automated. Build a complete picture of the system as it exists today. ### 1a. Read derivation history Read `ops/derivation.md` for: - Original dimension positions and confidence levels - Conversation signals that drove each choice - Personality dimensions - Vocabulary mapping - Coherence validation results from init - Failure mode risks flagged at init Read `ops/config.yaml` for live configuration values that may differ from derivation. ### 1b. Inventory the system Count and catalog: ```bash # Notes (domain-named folder) find notes/ -name "*.md" -not -name "index.md" | wc -l # MOCs grep -rl '^type: moc' notes/ | wc -l # Templates ls templates/*.md 2>/dev/null | wc -l # Skills (platform-dependent) ls .claude/skills/*/SKILL.md 2>/dev/null | wc -l # Hooks ls .claude/hooks/*.sh 2>/dev/null | wc -l # Self space ls self/*.md self/memory/*.md 2>/dev/null | wc -l # Inbox find inbox/ -name "*.md" 2>/dev/null | wc -l # Ops find ops/ -name "*.md" 2>/dev/null | wc -l ``` Adapt folder names to the domain vocabulary found in derivation.md. ### 1c. Read health history Scan `ops/health/` for the last 3-5 health reports. Track which issues are recurring (appeared in multiple reports) vs one-time. ### 1d. Collect operational evidence Read `ops/observations/` for accumulated friction patterns, methodology learnings, and process gaps. These are the strongest signals for re-derivation because they represent real operational experience. --- ## PHASE 2: Identify Drift For each of the 8 configuration dimensions, measure current position against derived position. Classify the drift: | Classification | Meaning | Action | |---------------|---------|--------| | **none** | Current state matches derivation | Confirm -- no change needed | | **aligned** | Position shifted but in a sensible direction given growth | Document the evolution, update derivation to match | | **compensated** | Mismatch exists but workarounds are in place | Evaluate whether to formalize the compensation or resolve the mismatch | | **incoherent** | Cascade is broken -- dimension conflicts with dependent dimensions | Must resolve in re-derivation | | **stagnant** | Should have evolved based on system maturity but hasn't | Propose advancement | ### Drift measurement per dimension **Granularity:** Are notes actually atomic/moderate/coarse? Check average note length, number of claims per note, split frequency. **Organization:** Is the folder structure still flat? Have subfolders crept in? Are notes filed consistently? **Linking:** What is the actual link density? Are connections explicit only, or is semantic search active? Check backlink counts. **Processing:** What is the actual processing intensity? Count pipeline invocations vs direct note creation. Check inbox throughput. **Navigation depth:** How many MOC tiers exist in practice? Is the hub reachable from all notes within the stated tier count? **Maintenance:** When did conditions last fire? Are thresholds appropriate for the vault's current state? **Schema:** What percentage of notes comply with templates? What fields are actually used vs declared? **Automation:** What hooks and skills are active? Does automation level match what was configured? ### Build the drift report ``` | Dimension | Derived | Current | Classification | Evidence | |-----------|---------|---------|---------------|----------| | Granularity | atomic | atomic | none | avg 350 words/note, 1 claim/note | | Organization | flat | flat | none | no subfolders detected | | Linking | explicit+implicit | explicit only | compensated | qmd configured but unused, grep compensates | | Processing | heavy | moderate | incoherent | pipeline exists but reflect/reweave skipped 60% | | Navigation | 3-tier | 2-tier | stagnant | 80+ notes but no topic-level MOCs | | Maintenance | condition-based (tight) | condition-based (lax) | compensated | conditions rarely fire, manual link fixes | | Schema | moderate | minimal | incoherent | 45% of notes missing topics field | | Automation | convention | convention | none | hooks active for session orient | ``` --- ## PHASE 3: Re-derive Fresh derivation informed by operational evidence. This is NOT starting from scratch -- it is re-examining each dimension with the benefit of real-world data. For each dimension: 1. **Read original rationale** from ops/derivation.md -- why was this position chosen? 2. **Consider friction patterns** from Phase 1d -- what operational pain exists? 3. **Query the research graph** -- use `mcp__qmd__deep_search` to search for claims relevant to the friction. Fall back to `mcp__qmd__vector_search`. If MCP is unavailable, use qmd CLI (`qmd query`, then `qmd vsearch`). Fall back to reading bundled reference files directly only if both MCP and qmd CLI are unavailable. 4. **Read dimension-claim-map.md** for the specific claims that inform this dimension. 5. **Propose new position or confirm original** -- with explicit reasoning. The re-derivation should answer for each dimension: - What was the original position and why? - What does operational evidence suggest? - What does the research say about this specific friction? - What is the new recommended position? - If changed: what cascade effects does this create? (check interaction-constraints.md) ### Vocabulary re-evaluation Read `${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md`. Compare the current vocabulary mapping against how the user actually talks about their system (evidence from session logs, observations, user-facing text in notes). If the user has developed their own vocabulary that differs from the mapping, adopt the user's terms. ### Personality re-evaluation If personality was derived at init, check whether the personality dimensions still fit. Evidence sources: self/identity.md, agent notes in MOCs, session log tone. If personality was not derived at init, check whether operational evidence now warrants it. --- ## PHASE 4: Check Coherence Apply the full coherence validation from `${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md`: ### Pass 1: Hard constraint check For each hard constraint, evaluate the re-derived configuration. If violated, the re-derivation must be adjusted before proceeding. Hard constraints: - `atomic + navigation_depth == "2-tier" + volume > 100` -- navigational vertigo - `automation == "full" + no_platform_support` -- platform cannot support - `processing == "heavy" + automation == "manual" + no_pipeline_skills` -- unsustainable ### Pass 2: Soft constraint check For each soft constraint, evaluate the configuration. Document active soft constraints and their compensating mechanisms. ### Pass 3: Cascade verification Trace each changed dimension through its cascade chain. Verify that downstream dimensions are either: - Consistent with the new position, or - Explicitly overridden with documented rationale ### Pass 4: Three-space boundary check Using `${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md`, verify the re-derived architecture maintains clean boundaries. Check for each of the six conflation patterns. ### Pass 5: Kernel validation (15 primitives) Using `${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md`, verify the re-derived system will pass all 15 kernel primitives. --- ## PHASE 5: Present Delta Show the user exactly what changed and what stays the same. **Output format:** ``` === RESEED ANALYSIS === System: [domain name] Platform: [detected] Note count: [N] --- Drift Summary --- Dimensions with drift: [N] / 8 - [dimension]: [derived] -> [current] ([classification]) ... --- Re-Derivation Proposal --- | Dimension | Current | Proposed | Change? | Rationale | |-----------|---------|----------|---------|-----------| | [dim] | [val] | [val] | [yes/no]| [reason] | | ... | ... | ... | ... | ... | --- Impact Assessment --- For each proposed change: ### [Dimension]: [current] -> [proposed] **Component modifications:** - [specific file/folder/template changes] **Content impact:** - [N] notes affected (need [field update / re-categorization / MOC reassignment]) - [N] MOCs affected (need [restructuring / renaming / splitting]) **Risk:** [low / medium / high] -- [explanation] **Rollback:** [specific rollback steps if this change doesn't work] --- Coherence Validation --- Hard constraints: [PASS / FAIL with details] Soft constraints: [N active, N compensated] Cascade chains: [verified / issues found] Three-space boundaries: [clean / violations found] Kernel primitives: [N / 11 predicted to pass] === END ANALYSIS === ``` **If `--analysis-only` was specified:** Stop here. Present the analysis and exit. **If not analysis-only:** Ask the user: "Would you like me to proceed with the re-derivation? I'll preserve all your content and restructure the architecture." --- ## PHASE 6: Implement on Approval Execute in strict order. Each step depends on the previous completing successfully. ### Step 1: Archive current derivation ```bash cp ops/derivation.md ops/derivation-$(date +%Y-%m-%d).md ``` ### Step 2: Restructure folders If folder names change (vocabulary evolution), rename with content preservation: ```bash git mv old-folder/ new-folder/ ``` Update all file references. ### Step 3: Update templates Modify `_schema` blocks, add/remove fields, update enum values. Templates are the single source of truth for schema. ### Step 4: Update context file Regenerate sections affected by dimension changes. Preserve user customizations documented in `ops/user-overrides.md` (if it exists). Apply vocabulary transformation throughout. ### Step 5: Update skills If skill vocabulary needs updating, modify skill files in `.claude/skills/`. ### Step 6: Update hooks If automation level changed, add or remove hooks. Update hook paths to match any renamed folders. ### Step 7: Restructure MOCs If navigation depth changed: - Create new tier of MOCs (e.g., topic-level MOCs when moving from 2-tier to 3-tier) - Redistribute notes across MOCs - Update hub MOC to link to new structure - Update all notes' Topics footers ### Step 8: Update self/ **PRESERVE self/memory/ entirely.** Never modify or delete memory files. Update: - `self/identity.md` -- if personality changed - `self/methodology.md` -- if processing or maintenance changed - `self/goals.md` -- add "post-reseed orientation" as active thread ### Step 9: Regenerate ops/derivation.md Write a new derivation record with: - All re-derived dimension positions and rationale - Operational evidence that informed changes - Research claims that supported each decision - Previous derivation date and what changed - Coherence validation results ### Step 10: Log the reseed Create a session log in `ops/sessions/` documenting the reseed: what changed, why, and what to watch for. --- ## PHASE 7: Validate Run the full validation suite on the re-derived system. ### Kernel validation (15 primitives) Run `${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh` if available, otherwise manually check each primitive: 1. markdown-yaml -- valid YAML frontmatter on all notes 2. wiki-links -- all wiki links resolve 3. moc-hierarchy -- MOC structure intact, all notes reachable 4. tree-injection -- session start loads file structure 5. description-field -- descriptions present and distinct from titles 6. topics-footer -- topics present on all non-MOC notes 7. schema-enforcement -- templates exist, validation mechanism present 8. semantic-search -- configured or documented for future 9. self-space -- self/ intact with core files 10. session-rhythm -- orient/work/persist documented 11. discovery-first -- notes optimized for findability ### Coherence validation - **Reachability:** Every note is reachable from the hub MOC within the stated tier depth - **Link health:** Zero dangling wiki-links introduced by the reseed - **Schema compliance:** All notes pass template validation - **Vocabulary consistency:** Same universal term maps to same domain term everywhere - **Three-space boundaries:** No conflation patterns introduced ### Report results ``` === RESEED VALIDATION === Kernel: [N] / 11 PASS Coherence: [PASS / issues] Content preserved: [yes -- N notes, N memories unchanged] Rollback available: ops/derivation-[date].md Post-reseed recommendations: 1. [First thing to check after a few sessions] 2. [Second monitoring item] === END VALIDATION === ``` If any kernel primitive fails, fix it before completing the reseed. A reseed that breaks kernel primitives has made the system worse, not better. --- ## Quality Standards - **Content preservation is non-negotiable.** Every note, every memory, every piece of user-created content must survive the reseed. Verify counts before and after. - Ground every dimension change in operational evidence, not theoretical preference - Use domain vocabulary throughout -- the reseed should feel native to the user - If the user's vocabulary has evolved since init, adopt their current language - Acknowledge uncertainty: "This dimension change is speculative -- monitor for [specific friction]" - Prefer reversible changes over irreversible ones - Document everything in ops/derivation.md -- the next reseed needs this context