titen-memory 0.7.2

Complete changelog

Stable release · npm latest

npm install -g titen-memory@0.7.2

Install guide · Release page · npm package

An urgent fix: 0.7.1 cannot serve a large single-subject store. Upgrade from 0.7.1 without delay; 0.7.0 is unaffected.

Fixed

• titen-memory@0.7.1 cannot serve a large single-subject store: one context compile takes a median 74.5 seconds where 0.7.0 takes under half a second. The 0.7.1 fix for #291 wrote the disputed predicate as a join inside EXISTS while its own comment claimed the nested form, and a join inside EXISTS is still a join the planner may reorder. SQLite 3.53.0 — the version Bun 1.3.14 links — reorders it to SEARCH o USING INDEX observations_workspace_scope (org_id=?), scanning every observation in the organization once per candidate row: the exact shape src/core/authorization.ts documents as the historical 79-second failure, shipped in the release that believed it had prevented it.

  Who is affected: anyone whose store holds many claims under one subject and who compiles with a large max_candidates. The cost is the product of candidates and organization-wide observations, so small and per-subject stores are unaffected — which is why no test and no published benchmark caught it. Every published pooled quality figure was measured on 0.7.0; every published pooled or scoped-anchor latency figure was measured on 0.7.0 or on this release, never on 0.7.1.

  Measured, 342,129-claim / 19,829-observation store, one subject, real statement, EXPLAIN captured from bun:sqlite rather than a pasted copy:

  	candidate query	served compile
  0.7.1 as published	73,439 ms	74,474 ms
  this release	232 ms	417 ms p50 / 864 ms p95

  This restores 0.7.0’s behaviour; it does not make compile fast. 864 ms p95 still fails the pre-registered 250 ms gate, so the 2026-08-07 latency falsifier stands — the pre-registration predicted exactly that outcome in writing before the run.

  The ranked output is byte-identical to the published 0.7.0 pooled run — equal sha256 over all 500 instances — so this restores the shipped answer rather than changing it. Full method and both plans in the report, protocol pre-registered before the A/B.

Added

• Plan-shape guards for the retrieval queries (tests/integration/query-plan.test.ts). The regression above was invisible to every existing test because contract stores hold tens of rows and still return the right answer quickly. The load-bearing discovery is that the bad plan reproduces on an empty store — SQLite picks the join order from the schema, not from row counts — so a cheap deterministic test could have caught this and the 2026-08-07 occurrence before either shipped. The guards assert the plan of the candidate query, the by-id hydration, and authorized-source loading; reverting the fix fails two of the three. They assert the plan, never a duration: a timing assertion on this hardware would be flaky, and the plan is what regressed.