seven-dpt-mcp

A tiny, local MCP server that gives Claude (in any project) a persistent set of long-running problems and a loop for cracking them — Feynman's twelve favorite problems method, driven by the tripartite model of inspiration.

• Feynman's method (via Gian-Carlo Rota): keep ~a dozen problems dormant in mind; every time you meet a new trick, test it against all of them.

• Inspiration = evocation + transcendence + approach motivation (Thrash & Elliot): a stimulus evokes a possibility, you transcend the problem's current framing, then you're motivated to act on it.

The server holds state and scaffolding; the connected model does the thinking — no LLM runs inside the server, no API key.

Tools

Storage: ~/.local/share/seven-dpt/store.json (override with SEVEN_DPT_DB). One store, shared by every project = one brain.

Related MCP server: hive-exp

Wake conditions (0.1.4)

Retiring a problem parks it with a re-open trigger — but a trigger written in prose is a wait owned by "someone will remember." A wakeCondition makes it computable: a small predicate (all/any over atoms like sparkCount, a date gate, fileMatches / fileLines / fileCount on a path, or an explicit manual note) attached when you retire/solve a problem (update_problem), park a spark (update_spark), or capture one born gated (capture_spark). The ambient digest evaluates every condition at session start and surfaces what's ripe (with an act/re-park pointer), what's ripening (with current/target progress), and — loudly — any condition whose source became unreadable: a wake source that vanished must scream, not sit at 0% forever. Everything echoes its aim (prior-ledger.jsonl 12/20), so a wrong path or unit is visible when you arm it, not months later. No auto-reopen: ripeness is surfaced, you decide. --wake prints the full ledger from the CLI.

Claim typing (0.1.5)

A parked spark with a wake condition can revive — but nothing says when it may die, so an unfalsifiable hope can ride the digest forever. 0.1.5 gives every spark an optional claim-typing trio, all write-once on the same anti-hindsight model as prior:

• claimType — universal ("this always holds") vs existential-bounded ("this holds somewhere, within a stated frame"). A frame-bounded null is not a claim-failure; typing the claim keeps a frame-kill from being read as a lever-kill.

• forbids — one concrete observation the spark rules out. If nothing is forbidden, nothing can refute it, and the spark is a mood, not a claim.

• exhaustion — the retirement predicate, the dual of wakeCondition: the condition under which the spark is abandoned rather than re-parked.

Set them at capture, or backfill later while unset (update_spark); revision after the fact is refused with a visible notice — rewriting what a claim forbids after seeing results is the conventionalist stratagem the fields exist to block. ledger_invariants.py flags ORPHANED-EXISTENTIAL sparks (parked with a wake, no exhaustion — can revive but never die), and calibration.py stamps the claimType mix of every scored cohort.

How it bootstraps

On first run (no store file yet), the store seeds itself with seven-dpt's own three open product problems — auto-detection of recurring issues, the background-spend policy, and proactive surfacing. Design decision, made deliberately: the seeds are tool-generic (identical for every install, about the tool rather than about you), so the server dogfoods its own method from minute one and the ambient digest has something to show before you add your own problems. They are ordinary rows in your store — edit, replace, or clear them freely; an existing store is never touched. So the moment it runs it is already "taking care of its own problems": while you work on anything else, those sit in context and can be sparked by unrelated discoveries. The policy for how/when/how-much to chase background problems is deliberately not coded — it's meant to be learned later from the accumulated spark → outcome history, which is why update_spark exists.

That history is the reward channel: each spark carries a prior (your stated probability-it-works at capture — immutable afterwards, so stated credences can be calibrated against realized outcomes once enough sparks resolve), a costToOpen (the forward effort estimate, set at capture and preserved), a cost (the actual effort, once chased to a verdict), and a value (graded payoff, 0 for a miss). analysis/reservation_value.py turns it into a Pandora's-Box / Gittins reservation-value ranking — but it gates on data sufficiency and refuses to emit numbers until enough resolved sparks (with cost + value, including failures) accrue, so the policy is never fit on false precision. A Bayesian companion, analysis/reservation_value_bayes.py, was retired on 2026-10-10 (it is in git history): nothing ever invoked it, and the de-bias map it applied to spark priors was fitted on another program's ledger, where it has the opposite sign to this store's own sparks. analysis/calibration.py is the audit half of the prior loop: it scores stated priors against realized outcomes (reliability table, Brier/skill, drift check) from any two-line JSONL ledger of pre-registered priors + resolutions, and --json persists that ledger's de-bias map and buckets for analysis/self_check.py. No map is applied to spark priors. The store's own reading — resolved sparks' mean stated prior against the share that worked, with a Wilson interval — is one line of the session digest once ten sparks with a prior have resolved, and --priors lists each spark's prior beside its outcome. --split YYYY-MM-DD partitions the curve at a changepoint (a model upgrade re-prices estimates — don't pool across one untested), and a scope stamp reports the claimType mix of scored pairs, since a frame-bounded null scored as a claim-failure is the one bias the audit can't see from numbers alone. analysis/ledger_invariants.py audits the program the same ledger records, not any single probe: deterministic invariants for the failure class where every result is locally sound and the project is still wrong — a park-streak check (K straddles-zero verdicts in a row on the primary metric means the instrument, not the ideas, is the suspect), power-at-preregistration (a gate below the banked MDE is unresolvable before it runs), channel-liveness stamps, and ORPHANED-EXISTENTIAL (a parked spark with a wake but no exhaustion can revive but never die — unfalsifiable-in-practice spend). It reports its own note-classification coverage, exits 1 on alerts, supports --asof retrodiction, and --json emits ALERT markers a hook or wakeCondition (fileMatches on the output) can gate on.

Install (turn on for all projects)

Via npm (recommended)

Published on npm — no build step. Register it for every project (user scope):

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

From source (alternative)

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"

Then make the problems ambient — merge into ~/.claude/settings.json so every session opens with your dormant problems in context:

{
  "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 }] }
    ]
  }
}

(Installed from source instead? Replace each command with an absolute node path + /absolute/path/to/seven-dpt-mcp/dist/index.js --digest — hooks don't source your shell profile, so nvm-style setups need the absolute path.)

(--digest prints nothing when no problems are open; a fresh install prints the three seeded ones — that's the bootstrap working, not noise.)

Validate the idea

1. Add a few of your own long-running problems — add_problem.

2. When you hit an interesting technique in any repo, evoke it; watch Claude test it against every problem and reframe the ones that light up.

3. Let it capture_spark the hits, then update_spark once you've tried them.

4. Days later, get_problem — if that accumulated trail feels useful, the idea's proven.

Known MVP limits (intentional)

• JSON file, last-write-wins (fine for one user).

• evoke matching is done by the connected model, not pre-ranked by embeddings.

License

Apache-2.0 — see LICENSE.