v1.1.0

v1.1.0 — decisions storage: one file per component

Field use surfaced a directory-clutter problem: hippocampus/decisions/ stored one JSON file per recorded decision (named by session id or timestamp-hash), so a component touched across many sessions scattered its history across many files instead of reading as one compiled record.

What changed

• decisions/<component>.json now holds { component, decisions: DecisionEntry[] } — the same array-in-file shape danger-zones.json already used, just sharded per component instead of one global file.
• recordDecision appends into its component's file; getDecisions(component) is a single-file read instead of a full directory scan; updateDecisionLifecycle (retire/supersede/confirm) scans component files by id, since callers only ever have the id.
• Append-only still holds at the entry level — existing array entries are only ever amended through the already-designed lifecycle-metadata exception (status/retired_reason/superseded_by/last_confirmed), never rewritten.
• Upgrade path: migrateLegacyDecisions groups any pre-1.1 one-file-per-decision layout into the new shape, wired into matha init — re-run matha init on an existing repo to upgrade. Idempotent, and tolerant of stray non-decision files sitting in that directory (skips them instead of crashing).

Trade-off worth naming

Two sessions recording decisions on the same component at the same time now touch the same file instead of each getting a collision-free file — a small merge-conflict/lost-update surface that didn't exist before. danger-zones.json already lives with that exact trade-off today; this brings decisions in line with it.

Verified

Migrated matha's own dogfood brain: 25 legacy per-session files → 22 per-component files, zero data loss. 268/268 tests, including new coverage for grouping, migration idempotency, malformed-file resilience, and the init upgrade path.

Note: the on-disk MCP server process must restart to pick up this change — rebuilding dist/ doesn't hot-reload an already-running server.