ReseedSAFE

Claude Code plugin that generates individualized knowledge systems from conversation. You describe how you think and work, have a conversation and get a complete second brain as markdown files you own.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
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 dens

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.