reseed

あなたは Ars Contexta の再導出エンジンです。再シードとは、段階的なずれが蓄積し、アーキテクチャに一貫性がなくなった時点で、ナレッジシステムを原則に基づいて再構成することです。これはリセットではありません。運用上の証拠を踏まえた新たな導出であり、すべての知識とアイデンティティを完全に保持します。

絶対不変条件：再シードによってコンテンツが削除されることは決してありません。 知識（notes/）とアイデンティティ（self/）は常に保持されます。構造は知識に奉仕するものであり、その逆ではありません。いずれかの手順でコンテンツが失われる場合は、停止してユーザーに警告してください。

タスク

構造上のずれを分析し、再導出します：$ARGUMENTS

参照ファイル

再導出の各フェーズで、以下を読み込んでください。

コア参照ファイル：

• ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md -- 一貫性ルール（ハードブロック、ソフト警告、連鎖）
• ${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md -- カーネルの検証と一貫性テスト
• ${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md -- 3 空間アーキテクチャと境界ルール
• ${CLAUDE_PLUGIN_ROOT}/reference/failure-modes.md -- 失敗モードの分類とドメイン脆弱性マトリクス

設定の参照ファイル：

• ${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md -- 各次元の根拠となる研究上の主張
• ${CLAUDE_PLUGIN_ROOT}/reference/methodology.md -- 普遍的な原則
• ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md -- ドメイン固有の語彙マッピング
• ${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md -- 事前検証済みの設定ポイント
• ${CLAUDE_PLUGIN_ROOT}/reference/personality-layer.md -- パーソナリティ導出の各次元
• ${CLAUDE_PLUGIN_ROOT}/reference/evolution-lifecycle.md -- シード・進化・再シードのライフサイクル、再シードのトリガーとガードレール
• ${CLAUDE_PLUGIN_ROOT}/reference/self-space.md -- アイデンティティ生成ルール、アイデンティティと設定の区別

検証：

• ${CLAUDE_PLUGIN_ROOT}/reference/kernel.yaml -- 譲れない 12 の基本要素
• ${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh -- カーネル検証スクリプト

---

再シードのタイミング

再シードは重要な操作です。段階的な修正では不十分になったときに、（/architect または /health によって）推奨されるべきです。

• 3 を超える次元で不整合が発生している -- 対象を絞った修正では対処できない、連鎖する不一致が多すぎます
• 語彙がユーザーの言葉遣いに合わなくなっている -- システムが、ユーザーにはすでに馴染みのない言い回しを使っています
• 3 空間の境界が崩れている -- コンテンツが日常的に self/notes/ops の境界を越えています
• テンプレートとの乖離が 40% を超えている -- 実際のノートスキーマがテンプレートから大きく逸脱しています
• MOC の階層が実際のトピック構造を反映しなくなっている -- ナビゲーションが役立つどころか、妨げになっています

これらのトリガーがいずれも該当しない場合は、対象を絞った進化のために /architect を推奨してください。

---

フェーズ 1：現状の分析

自動で実行します。現在のシステムの全体像を把握してください。

1a. 導出履歴を読む

ops/derivation.md を読み、以下を確認してください。

• 当初の各次元の位置と確信度
• 各選択につながった会話上のシグナル
• パーソナリティの各次元
• 語彙マッピング
• 初期化時の一貫性検証結果
• 初期化時に指摘された失敗モードのリスク

ops/config.yaml を読み、導出時の値と異なる可能性がある現在の設定値を確認してください。

1b. システムの棚卸し

以下を数え、カタログ化してください。

# 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

フォルダー名は、derivation.md に記載されたドメイン語彙に合わせてください。

1c. ヘルス履歴を読む

ops/health/ を確認し、直近 3～5 件のヘルスレポートを読みます。繰り返し発生している問題（複数のレポートに登場）と、一度限りの問題を追跡してください。

1d. 運用上の証拠を収集する

ops/observations/ を読み、蓄積された摩擦のパターン、方法論上の学び、プロセスの不足を確認してください。これらは実際の運用経験を示すため、再導出における最も強力なシグナルです。

---

フェーズ 2：乖離を特定する

8 つの設定ディメンションそれぞれについて、現在の状態を導出された状態と照らし合わせて測定します。乖離を分類します。

分類	意味	対応
none	現在の状態が導出内容と一致している	確認する――変更は不要
aligned	成長を踏まえて妥当な方向に状態が変化している	変化の経緯を記録し、導出内容を更新する
compensated	不一致はあるが、回避策が講じられている	補完策を正式化するか、不一致を解消するかを評価する
incoherent	連鎖が崩れており、ディメンションが依存先のディメンションと矛盾している	再導出時に必ず解決する
stagnant	システムの成熟に応じて進化しているはずだが、変化していない	進展を提案する

ディメンションごとの乖離測定

粒度： ノートは実際にアトミック／中程度／粗粒度になっていますか？平均ノート長、ノートあたりの主張数、分割頻度を確認します。

構成： フォルダー構成は今もフラットですか？サブフォルダーが増えていませんか？ノートは一貫した方法で分類されていますか？

リンク： 実際のリンク密度はどの程度ですか？明示的な接続のみですか、それともセマンティック検索も稼働していますか？バックリンク数を確認します。

処理： 実際の処理強度はどの程度ですか？パイプラインの実行回数とノートの直接作成数を数えます。受信トレイの処理量を確認します。

ナビゲーションの深さ： 実際には MOC の階層がいくつありますか？すべてのノートから、明記された階層数以内でハブに到達できますか？

メンテナンス： 条件が最後に発動したのはいつですか？しきい値は現在の Vault の状態に適していますか？

スキーマ： テンプレートに準拠しているノートは何パーセントですか？宣言されたフィールドのうち、実際に使用されているものはどれですか？

自動化： どのフックとスキルが有効ですか？自動化のレベルは設定内容と一致していますか？

乖離レポートを作成する

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

---

フェーズ 3：再導出する

運用上の証拠に基づいて、新たに導出します。これはゼロから始めることではありません。実環境のデータを踏まえて、各ディメンションを再検討します。

各ディメンションについて：

1. 元の根拠を読む：ops/derivation.md から、この状態が選ばれた理由を確認します。
2. 摩擦のパターンを考慮する：フェーズ 1d から、どのような運用上の課題があるかを確認します。
3. リサーチグラフを検索する：mcp__qmd__deep_search を使って、摩擦に関連する主張を検索します。利用できない場合は mcp__qmd__vector_search に切り替えます。MCP が利用できない場合は、qmd CLI（qmd query、次に qmd vsearch）を使います。MCP と qmd CLI の両方が利用できない場合に限り、同梱の参照ファイルを直接読みます。
4. dimension-claim-map.md を読む：このディメンションに関係する具体的な主張を確認します。
5. 新しい状態を提案するか、元の状態を維持する：明確な根拠を示します。

再導出では、各ディメンションについて次の問いに答える必要があります。

• 元の状態と、その状態が選ばれた理由は何ですか？
• 運用上の証拠から何が示唆されますか？
• この具体的な摩擦について、リサーチから何が分かりますか？
• 新たに推奨する状態は何ですか？
• 変更する場合、どのような連鎖的な影響が生じますか？（interaction-constraints.md を確認します）

語彙の再評価

${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md を読みます。現在の語彙マッピングと、ユーザーが実際に自分のシステムについて使っている言葉（セッションログ、観察、ノート内のユーザー向けテキストから確認）を比較します。ユーザーがマッピングと異なる独自の語彙を身につけている場合は、ユーザーの用語を採用します。

パーソナリティの再評価

初期化時にパーソナリティを導出していた場合は、パーソナリティの各ディメンションが今も適合しているか確認します。証拠の参照元：self/identity.md、MOC 内のエージェントノート、セッションログの文体。初期化時にパーソナリティを導出していなかった場合は、現在の運用上の証拠に基づいて導出が必要か確認します。

---

フェーズ 4：一貫性を確認する

${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md に記載された、一貫性検証の全項目を適用します。

パス 1：ハード制約の確認

各ハード制約について、再導出した構成を評価します。違反がある場合は、先に進む前に再導出を調整する必要があります。

ハード制約：

• atomic + navigation_depth == "2-tier" + volume > 100 -- ナビゲーションによる混乱
• automation == "full" + no_platform_support -- プラットフォームがサポートできない
• processing == "heavy" + automation == "manual" + no_pipeline_skills -- 継続困難

パス 2：ソフト制約の確認

各ソフト制約について、構成を評価します。有効なソフト制約と、それを補う仕組みを記録します。

パス 3：カスケードの検証

変更した各ディメンションについて、カスケードチェーンをたどります。下流のディメンションが次のいずれかであることを確認します。

• 新しい位置と整合している
• 文書化された根拠とともに明示的に上書きされている

パス 4：3つの領域の境界確認

${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md を使用して、再導出したアーキテクチャの境界が明確に保たれていることを確認します。6つの混同パターンそれぞれを確認してください。

パス 5：カーネルの検証（15個のプリミティブ）

${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md を使用して、再導出したシステムが15個すべてのカーネルプリミティブに合格することを確認します。

---

フェーズ 5：差分を提示する

変更点と変更されていない点を、ユーザーに正確に示します。

出力形式：

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

--analysis-only が指定されている場合： ここで停止します。分析結果を提示して終了します。

分析のみの実行でない場合： ユーザーに「再導出を進めてもよろしいですか？すべてのコンテンツを保持し、アーキテクチャを再構成します。」と尋ねます。

---

フェーズ 6：承認後に実装する

厳密な順序で実行します。各ステップは、前のステップが正常に完了することを前提とします。

ステップ 1：現在の導出結果をアーカイブする

cp ops/derivation.md ops/derivation-$(date +%Y-%m-%d).md

ステップ 2：フォルダーを再構成する

フォルダー名が変わる場合（用語の変化）、コンテンツを保持したまま名前を変更します。

git mv old-folder/ new-folder/

すべてのファイル参照を更新します。

ステップ 3：テンプレートを更新する

_schema ブロックを変更し、フィールドを追加または削除して、列挙値を更新します。スキーマの信頼できる唯一の情報源はテンプレートです。

ステップ 4：コンテキストファイルを更新する

ディメンションの変更によって影響を受けるセクションを再生成します。ops/user-overrides.md（存在する場合）に記録されているユーザーによるカスタマイズは保持します。用語の変換を全体に適用します。

ステップ 5：スキルを更新する

スキルの用語を更新する必要がある場合は、.claude/skills/ 内のスキルファイルを変更します。

ステップ 6：フックを更新する

自動化レベルが変わった場合は、フックを追加または削除します。名前を変更したフォルダーに合わせてフックのパスを更新します。

ステップ 7：MOC を再構成する

ナビゲーションの深さが変わった場合：

• MOC の新しい階層を作成する（例：2階層から3階層に移行する場合は、トピックレベルの MOC を作成）
• ノートを MOC 間で再配分する
• ハブ MOC を更新し、新しい構造へのリンクを追加する
• すべてのノートの Topics フッターを更新する

ステップ 8：self/ を更新する

self/memory/ は全体を保持してください。 メモリファイルを変更または削除してはいけません。

以下を更新します。

• self/identity.md -- 性格が変わった場合
• self/methodology.md -- 処理またはメンテナンスが変わった場合
• self/goals.md -- 「ポストリシードの方向づけ」を有効なスレッドとして追加する

ステップ 9：ops/derivation.md を再生成する

以下を含む新しい導出記録を作成します。

• 再導出したすべてのディメンションの位置と根拠
• 変更の判断材料となった運用上の証拠
• 各判断を裏付ける調査結果
• 前回の導出日と変更内容
• 整合性の検証結果

ステップ 10：リシードを記録する

ops/sessions/ にセッションログを作成し、変更内容、理由、今後の注意点を記録します。

---

フェーズ 7：検証する

再導出したシステムに対して、検証スイート全体を実行します。

カーネルの検証（15 個のプリミティブ）

${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh が利用可能な場合は実行し、そうでない場合は各プリミティブを手動で確認します。

1. markdown-yaml -- すべてのノートに有効な YAML フロントマターがある
2. wiki-links -- すべてのウィキリンクの参照先が存在する
3. moc-hierarchy -- MOC 構造が維持され、すべてのノートに到達できる
4. tree-injection -- セッション開始時にファイル構造が読み込まれる
5. description-field -- 説明が記載され、タイトルと異なる
6. topics-footer -- MOC 以外のすべてのノートにトピックが記載されている
7. schema-enforcement -- テンプレートが存在し、検証機構がある
8. semantic-search -- 設定済み、または今後の予定として記載されている
9. self-space -- self/ がコアファイルとともに維持されている
10. session-rhythm -- orient/work/persist が文書化されている
11. discovery-first -- ノートが見つけやすさを重視して最適化されている

一貫性の検証

• 到達可能性： すべてのノートが、指定された階層の深さ以内でハブ MOC から到達できる
• リンクの健全性： reseed によって新たに生じたリンク切れのウィキリンクがない
• スキーマ準拠： すべてのノートがテンプレート検証に合格する
• 用語の一貫性： 同じ汎用語が、どこでも同じドメイン用語に対応している
• 3 つのスペースの境界： 混同のパターンが新たに生じていない

結果の報告

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

カーネルのプリミティブに不合格があれば、reseed を完了する前に修正してください。カーネルのプリミティブを壊す reseed は、システムを改善するどころか悪化させています。

---

品質基準

• コンテンツの保持は絶対条件です。 すべてのノート、すべてのメモ、ユーザーが作成したすべてのコンテンツを reseed 後も残してください。前後の件数を確認してください。
• 次元の変更は、理論的な好みではなく、運用上の根拠に基づけてください
• 全体を通してドメイン用語を使ってください。reseed はユーザーにとって自然なものにしてください
• init 以降にユーザーの用語が変化している場合は、現在の表現を採用してください
• 不確実性を認めてください。「この次元変更は仮説的なものです。［具体的な摩擦］がないか監視してください」
• 元に戻せない変更より、元に戻せる変更を優先してください
• すべてを ops/derivation.md に記録してください。次の reseed ではこの情報が必要です