reseed

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:

# 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 abo