seven-dpt-mcp

seven-dpt-mcp

Claude に（どのプロジェクトでも）永続的な長期に取り組む問題のセットと、それを解き明かすループを与える、小さなローカル MCP サーバーです。これは Feynman の 十二のお気に入りの問題メソッドで、ひらめきの三要素モデルに基づいています。

• Feynman のメソッド（Gian-Carlo Rota 経由）：十数個ほどの問題を頭の片隅に置いておき、新しい手法に出会うたびに、そのすべてに当てはめてみます。
• ひらめき = 喚起 + 超越 + 接近動機（Thrash & Elliot）：刺激が可能性を喚起し、問題の現在の枠組みを超越し、それに取り組む意欲が湧きます。

サーバーは状態と足場を保持し、接続されたモデルが思考します。サーバー内で LLM は実行されず、API キーも不要です。

ツール

ツール	目的
add_problem	長期に取り組む問題をセットに追加します（およそ12件の上限を超えると、何かを終了または統合するまで拒否されます。あるいは overCap を渡してください）
update_problem	問題を編集、終了、解決、または再開します。終了時には resolution が必要です。理由と再開のきっかけを記述します。統合は、統合先を resolution に記した終了です
list_problems	未解決の問題を確認します
get_problem	1つの問題と、すべてのひらめき（アイデア、次のステップ、結果）を取得します。これが記憶です
evoke	ループです。 手法を渡すと、問題と、喚起 → 超越 → 接近へと進むための足場を返します
capture_spark	候補となるアイデアと、その問題に対する具体的な次のステップを保存します（任意の costToOpen — 取り組みを始めるために必要な労力の見積もり — prior — 後で較正するための、明示した p(works)。変更不可 — および主張の型付けに関する3項目：claimType universal/existential-bounded、forbids — そのひらめきが排除する1つの観測 — exhaustion — 再び保留するのではなく、いつ諦めるか。すべて一度だけ書き込み可能）
update_spark	ひらめきの結果を記録します。ステータス（tried/worked/failed）、cost（実際に費やした労力）、value（段階評価した見返り。うまくいかなかった場合は 0）。失敗も記録してください。価値ゼロの結果は、背景作業ポリシーの学習に使われるシグナルです。未設定の claimType/forbids/exhaustion を後から記録できます（一度だけ書き込み可能。変更はできません）
wake_status	保留中のすべての問題／ひらめきについて、wakeCondition を現時点で評価します。熟し具合、進捗、各要素の現在値／目標値を確認できます

保存先：~/.local/share/seven-dpt/store.json（SEVEN_DPT_DB で変更可能）。すべてのプロジェクトで共有する1つのストアが、1つの脳になります。

ウェイク条件（0.1.4）

問題を終了すると、再開のきっかけとともに保留されます。しかし、文章で書かれたきっかけは「誰かが覚えている」という人任せの待機状態です。wakeCondition を使えば、これを計算可能にできます。問題の終了／解決時（update_problem）、ひらめきの保留時（update_spark）、または最初から条件付きのひらめきの記録時（capture_spark）に設定する小さな述語です。sparkCount のような要素を対象とする all/any、date のゲート、パス上の fileMatches / fileLines / fileCount、または明示的な manual メモを使えます。セッション開始時にアンビエントダイジェストがすべての条件を評価し、熟したもの（実行／再保留へのポインター付き）、熟しつつあるもの（current/target の進捗付き）、そして情報源が読み取り不能になった条件を大きく通知します。ウェイク条件の情報源が消えたなら、いつまでも0%のままではなく、警告されるべきです。目標はすべて記録されます（prior-ledger.jsonl 12/20）。そのため、パスや単位の誤りは、数か月後ではなく、条件を設定した時点で見つけられます。自動再開はありません。熟したことが通知され、どうするかはあなたが決めます。CLI から --wake を実行すると、台帳全体が表示されます。

クレームの型付け（0.1.5）

覚醒条件のある保留中のスパークは再活性化できますが、いつ消滅するのかは定められていないため、反証不能な希望がダイジェストに永遠に残る可能性があります。0.1.5 では、すべてのスパークに任意のクレーム型付けの3項目を追加します。いずれも prior と同じ後知恵を防ぐモデルに基づき、一度だけ書き込み可能です。

• claimType — universal（「これは常に成り立つ」）と existential-bounded（「これは、明示された枠内のどこかで成り立つ」）のいずれかです。枠内でのヌル結果はクレームの失敗ではありません。クレームに型を付けることで、枠の終了をレバーの終了と誤解されないようにします。
• forbids — スパークが否定する具体的な観察事項です。何も否定しないなら、何によっても反証できず、そのスパークはクレームではなく気分にすぎません。
• exhaustion — 退役条件です。wakeCondition の双対であり、スパークを再び保留するのではなく、放棄する条件です。

記録時に設定するか、後から未設定の間に (update_spark) 補完できます。事後の変更は、通知を表示して拒否されます。結果を見てからクレームが否定するものを書き換えるのは、これらのフィールドが阻止するためにある慣習主義的な策略です。ledger_invariants.py は ORPHANED-EXISTENTIAL スパーク（保留中で、覚醒条件はあるものの消耗条件がないため、再活性化はできても消滅することはないスパーク）にフラグを立て、calibration.py はスコアリング対象の各コホートの claimType の内訳を記録します。

ブートストラップの仕組み

初回実行時（まだストアファイルがない場合）、ストアには seven-dpt 自身が抱える3つの未解決のプロダクト課題が自動登録されます。繰り返し発生する問題の自動検出、バックグラウンド支出のポリシー、そしてプロアクティブな提示です。これは意図的な設計上の判断です。登録される課題はツールに汎用的（すべてのインストールで同一で、あなたではなくツールに関するもの）なので、サーバーは初日から自らの手法を実践でき、あなたが独自の課題を追加する前から、常時表示されるダイジェストに内容が表示されます。これらはあなたのストアにある通常の行なので、自由に編集、置換、消去できます。既存のストアには一切手を加えません。つまり、実行した瞬間からすでに「自身の課題に対処」しています。ほかの作業をしている間も、これらの課題はコンテキストに残り、無関係な発見をきっかけに再び浮上することがあります。バックグラウンドの課題をどのように、いつ、どの程度追求するかというポリシーは、意図的にコード化されていません。蓄積された spark → outcome の履歴から後で学習することを想定しているため、update_spark が存在します。

この履歴が報酬チャネルです。各スパークには、記録時にあなたが示した「成功する確率」である prior（その後は変更不可のため、十分な数のスパークが解決すれば、示した確信度を実際の結果と照らし合わせて較正できます）、前向きの労力見積もりである costToOpen（記録時に設定され、保持されます）、結論に至るまで追求した場合の実際の労力である cost、そして段階評価された成果である value（失敗の場合は 0）が含まれます。analysis/reservation_value.py はこれをパンドラの箱／ギッティンズ指数による留保価値の順位に変換します。ただし、データが十分かどうかを判定し、十分な数の解決済みスパーク（コストと価値が記録され、失敗も含まれるもの）が蓄積されるまでは数値を出力しません。そのため、ポリシーが不確かな精度に基づいて適合されることはありません。ベイズ版の analysis/reservation_value_bayes.py は2026-10-10 に廃止されました（Git の履歴に残っています）。一度も呼び出されておらず、スパークの事前確率に適用していたバイアス補正マップは別のプログラムの台帳で適合されたもので、このストア独自のスパークでは符号が逆になるためです。analysis/calibration.py は prior ループの監査部分です。事前登録された事前確率と解決結果を記録した2行の JSONL 台帳から、示された事前確率を実際の結果と照合して評価します（信頼度表、ブライアスコア／スキル、ドリフトチェック）。また、--json はその台帳のバイアス補正マップとバケットを analysis/self_check.py 用に保存します。スパークの事前確率にはマップを適用しません。ストア独自の集計として、事前確率が記録された解決済みスパークについて、示された事前確率の平均と成功した割合をウィルソン信頼区間とともに、該当するスパークが10件解決した時点でセッションダイジェストに1行表示します。--priors を指定すると、各スパークの事前確率と結果が並べて表示されます。--split YYYY-MM-DD は変化点で曲線を分割します（モデルを更新すると見積もりの価格付けが変わるため、未検証の境界をまたいでデータをまとめないでください）。また、スコープスタンプは評価対象ペアの claimType の内訳を報告します。フレームの範囲内では否定されていない結果を主張の失敗として評価することは、数値だけから監査では検出できない唯一のバイアスだからです。analysis/ledger_invariants.py は、個別のプローブではなく、同じ台帳に記録されるプログラムを監査します。各結果が局所的には妥当でもプロジェクト全体としては誤っているという失敗クラスに対し、決定的な不変条件を検査します。具体的には、停滞連続回数のチェック（主要指標でゼロをまたぐ判定が K 回連続した場合、疑うべきはアイデアではなく測定手段です）、事前登録時点での検出力（蓄積済み MDE を下回るゲートは、実行前から解決不能です）、チャネルの稼働状況スタンプ、そして ORPHANED-EXISTENTIAL（起動条件はあるものの exhaustion のない保留中のスパークは、再開できても終了できず、実践上反証不能な支出になります）です。独自の注記分類カバレッジを報告し、アラート発生時は終了コード 1 で終了します。--asof による遡及推定をサポートし、--json は、フックや wakeCondition（出力に対する fileMatches）で条件判定できる ALERT マーカーを出力します。

インストール（すべてのプロジェクトで有効化）

npm 経由（推奨）

npm で公開済みのため、ビルド手順は不要です。すべてのプロジェクトに登録します（ユーザースコープ）。

claude mcp add --scope user seven-dpt -- npx -y seven-dpt-mcp

ソースから（代替手順）

npm install && npm run build
# Register for every project (user scope). Use an ABSOLUTE node path — hooks and MCP
# servers don't source your shell profile, so nvm-style setups need one:
claude mcp add --scope user seven-dpt -- "$(command -v node)" "$(pwd)/dist/index.js"

次に、問題を常に参照できる状態にします。~/.claude/settings.json にマージすると、すべてのセッションで休止中の問題がコンテキストに含まれます。

{
  "hooks": {
    "SessionStart": [
      { "matcher": "startup", "hooks": [{ "type": "command", "command": "npx -y seven-dpt-mcp --digest", "timeout": 10 }] },
      { "matcher": "resume",  "hooks": [{ "type": "command", "command": "npx -y seven-dpt-mcp --digest", "timeout": 10 }] },
      { "matcher": "clear",   "hooks": [{ "type": "command", "command": "npx -y seven-dpt-mcp --digest", "timeout": 10 }] }
    ]
  }
}

（ソースからインストールした場合は、各コマンドを絶対パスの node と /absolute/path/to/seven-dpt-mcp/dist/index.js --digest に置き換えてください。フックはシェルのプロファイルを読み込まないため、nvm 形式のセットアップでは絶対パスが必要です。）

（開いている問題がない場合、--digest は何も出力しません。新規インストール時にはシード済みの 3 件が表示されます。これはブートストラップが機能しているということであり、ノイズではありません。）

アイデアを検証する

1. 長期的に取り組んでいる問題をいくつか追加します — add_problem。
2. どのリポジトリでも興味深いテクニックに出会ったら、evoke で呼び出します。Claude がすべての問題に対してそのテクニックを試し、反応があった問題を捉え直す様子を確認します。
3. 該当したものを capture_spark で記録し、試した後に update_spark で更新します。
4. 数日後に get_problem を実行します。蓄積された記録が役立つと感じられたら、このアイデアは実証されたことになります。

MVP の既知の制限（意図的）

• JSON ファイルを使用し、最後に書き込まれた内容が優先されます（ユーザー 1 人での利用には問題ありません）。
• evoke によるマッチングは、埋め込みによる事前順位付けではなく、接続されたモデルが行います。

ライセンス

Apache-2.0 — LICENSE を参照してください。