seven-dpt-mcp

# 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

| Tool | Purpose |
|------|---------|
| `add_problem` | Add a long-running problem to your set (refused past the ~12 cap until you retire/merge something — or pass `overCap`) |
| `update_problem` | Edit, **retire**, **solve**, or reopen a problem. Closing takes a `resolution` — why, plus the re-open trigger; a merge is a retirement whose resolution names the absorber |
| `list_problems` | See your open problems |
| `get_problem` | One problem + every spark (idea, next step, outcome) — the memory |
| `evoke` | **The loop.** Feed it a trick; returns your problems + a scaffold walking evocation → transcendence → approach |
| `capture_spark` | Persist a candidate idea + concrete next step against a problem (+ optional `costToOpen` — the forward effort estimate — and `prior` — your stated p(works), immutable, for later calibration) |
| `update_spark` | Record a spark's outcome — status (tried/worked/failed), `cost` (actual effort spent), `value` (graded payoff, `0` for a miss). **Log failures too**; the zero-value outcomes are the signal a background-effort policy is learned from |
| `wake_status` | Evaluate every parked problem/spark's `wakeCondition` right now — ripeness, progress, per-atom current/target echoes |

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

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

## How it bootstraps

On first run (no store file yet), the store **seeds itself with seven-dpt's own five open
product problems** — auto-detection of recurring issues, the background-spend policy,
proactive surfacing, keeping the set near twelve, and storage scaling. 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 companion, `analysis/reservation_value_bayes.py`, adds a posterior-predictive prior (so it
can rank under sparse data) and models the one-time `costToOpen` against a compounding-but-saturating
benefit stream — ranking by profitability index, which is invariant to the value↔cost exchange rate.

## Install (turn on for all projects)

### Via npm (recommended)

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

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

### From source (alternative)

```bash
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:

```jsonc
{
  "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 five
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](LICENSE).