MinorBaek/wiki-synthesize

wiki-synthesize は何をしますか？

初回実行前に、キット内の docs/GOTCHAS.md（インジェスト、合成、リントに関する運用上の落とし穴）と docs/SEALS.md（シール形式）を読んでください。

Living-Synthesisレイヤーの「外科医」です。ノートの既に検証済みの知見ストア（概念ノートの## Key Findings、方法ノートの主張を含むセクション）を、エビデンスの流れ（解決済み、論争中、置き換え済み、新興）を捉えたState-of-Knowledgeブロックに再編成します。決して主張を捏造しません。すべてのエントリは既存の知見にトレース可能であり、新しいエントリや変更されたエントリはすべて、ユーザーが承認する前に各引用元のPDFと照合されます（エビデンスチェック、レイヤー2）。

モード

• デフォルト: /wiki-synthesize <NoteName> で1つの概念ノートまたは方法ノートを合成します。
• ワークリスト: /wiki-synthesize（引数なし）は wiki-lint のCheck 15を実行し、check15_missing を優先順位付け（synthesis.priority_fields のフィールドが最初、次にソースワークの数が多い順、降順）して表示し、さらに check15_stale（再合成候補）も表示し、どのノートを処理するか尋ねます。ワークリストはバックログであり、今すぐすべてを実行しなければならないものではありません。対象セットはCheck 15がライブで報告するものに基づきます。ドキュメントに書き込まれた凍結された数は古くなります。
• バッチ: /wiki-synthesize --batch [N] は例外ベースの管理キャンペーンモードです（デフォルトの波は8）。Check 15を実行し、優先順位の波を形成し、並列サブエージェントを起動します（各エージェントは SYNTHESIS-WORKFLOW.mdに従い、ブロックと自己レポートを返すのみで、書き込みは一切行いません）。すべての書き込みはエビデンスチェックと scripts/synth_validate.py によってゲートされ、クリーンなノートを書き込み、4つのトリガー（T1 検証不可能な主要数値、T2 情報損失、T3 構造的異常、T4 サブエージェントの低信頼度）およびチェックで見つかった欠陥があればエスカレーションします。references/BATCH-WORKFLOW.md を参照。波のサブエージェントを最初にユーザーに提案し（何をするか、何人か、どのモデルか）、ゴーサインを待ちます。

役割と境界

実行すること: ノートの知見ストアを読み、evidence_level とインライン測定値に基づいて評価し、ブロックをドラフトし、新しいエントリや変更されたエントリをそれぞれPDFと照合し、承認のために提示し、その後書き込み（ブロックを挿入し ## Controversies or Gaps を吸収）、ソースノートをシールし、ゲートを実行し、ログを取る。

実行しないこと: 数値や主張を捏造しない、debates/ ノートを作成しない（代わりにレポートで候補にフラグを立てる）、合成しきい値以下のノートに触れない、ユーザーが承認する前に何も書き込まない。

配置場所

パスは wiki.config.json から取得されます。ノート: <wiki_root>/concepts/、methods/、papers/、books/。開始する前に必ず WIKI_SCHEMA.md（Living-Synthesisレイヤー）を読んでください。

しきい値（合成前に満たす必要あり）

status: final かつ（synthesis.min_sources 以上の異なるソースワーク（デフォルト3）または少なくとも1つの引用ソースが synthesis.sr_levels（デフォルト SR-MA、SR）内の evidence_level を持つこと）。これはまさに wiki-lint のCheck 15の資格テストです。満たさない場合は：報告して停止。

ワークフロー

完全な手順は references/SYNTHESIS-WORKFLOW.md にあります。概要：契約を読み、ノートを特定し（test -f/内容検索で正確に行い、グロブだけで判断しない）、しきい値ゲート、全文事前ガード、知見をサブ質問にクラスタリングし、新しいエントリや変更されたエントリをPDFと照合、引用とページを含めてチャットでブロックを提案、承認、書き込み（scripts/synth_write.py：## Definition の後に挿入、Controversiesを吸収、スタンプ）、ソースノートをシール（<kit>/tools/seal.py）、ブロックが既に存在する場合は再合成差分を確認、その後ログを取り、ゲートを再実行し、Check 15を再実行。

安全ルール

• 決して捏造しない。 すべてのエントリは既存の知見にトレース可能。記憶やソースノートから新しい数値を生成しない。
• エビデンスチェック、レイヤー2：新しいエントリや変更されたエントリにはPDFチェックなしでは不可。 最大3つの異なるワークまではオーケストレーターがチェックし、それ以上は差分に限定されたブリーフを持つサブエージェントを提案し、ユーザーのOKを待ちます。すべての欠陥は変更前にPDFで再読され、ソースノートはノート名でシールされます。ソースノートの全文シールは、そのノートがそのワークについて何を述べているかを保護しません。このメソッドの過去の監査では、サンプリングされたノートとソースノートのペアの約4割に欠陥がありました。
• 人間がループ内にいる。 対話モード：提案、承認、書き込み（ユーザーのOKなしに書き込みは行わない）。バッチモード：synth_validate.py がすべての書き込みをゲートし、4つのトリガーがエスカレーションします。完全に自律的になることはありません。
• ゼロ情報損失。 ## Controversies or Gaps のすべての箇条書きは、そのセクションが吸収される前にブロックエントリにマッピングされなければなりません。
• 全文事前ガード。 引用された論文が全文事前コホートにある場合（synthesis.prefulltext_cutoff より前の日付の論文ノートで、全文シールされていない、またはアブストラクトレベルのみでシールされている）、影響を受けるエントリの信頼度が低下し、インラインで ⚠ フラグが付きます。エントリの停止は、そのエントリが依存する数値がそれ自体検証不可能な場合のみです。書籍の章は、自身の status: が draft または stub でない限り信頼できるアンカーと見なされます。これは、全文なしでインジェストされたことをノートが示している場合です（全文レベルの source_verification がステータスを上書きします）。synth_validate.py V4はこれを機械的に強制します。
• 主張には出典が必要。 各エントリは [[wikilinks]] を引用します。
• ファイルシステム優先。 ホストのファイルツールを使用し、ObsidianプラグインやMCPは不要です。

関連スキル

• wiki-lint：Check 15はこのスキルのワークリストを生成します。Check 32は（ノート、ワーク）ペアにシールがない場合にフラグを立てます。合成後にこれを実行して、ドリフトがないことを確認します（リンクチェックがクリーン、Check 15がノートを missing から削除）。
• wiki-ingest：上流。このスキルが再編成する知見はインジェストによって書き込まれました。

リファレンス

• references/SYNTHESIS-WORKFLOW.md：詳細な手順、ブロックテンプレート、ガードロジック、再合成処理。
• references/BATCH-WORKFLOW.md：バッチモード、オーケストレーターループ、サブエージェントブリーフ、V1-V5書き込みゲート、エスカレーショントリガー。
• scripts/synth_validate.py：書き込みゲートとWiki全体のスイープ。scripts/synth_write.py：ブロック挿入。<kit>/tools/seal.py：シール。