trajectories 0.0.0 → 0.1.1

package/docs/research/ledger/docs/research/2026-09-16-c7-tombstones.md

@@ -0,0 +1,467 @@
+# C7: tombstone double-track, 2026-09-16
+
+## Outcome
+
+Deletion is now defined, and it is the user's to make. `ledger delete
+<session-id> --reason <text>` writes one row — the store's audit of that
+deletion — and the session leaves every serving lane and every admission path in
+the same moment; `--hard` carries the same deletion through to the records
+themselves; `--list` reads the deletions back; `ledger status` discloses both the
+count and what those deletions still hold. Nothing else in the system can write
+one: not a scan, not a sync pass, not a source that vanished, not a source that
+was truncated, and not a copy of a source at another path.
+
+Measured on a byte-consistent copy of the production store (1,142,136,832 bytes;
+2,617 sessions; 231,553 records; 231,327 indexed rows and 226 echo rows; schema
+v13 at the start, v14 after the writer open — measured while this cycle's step
+still carried the number 14, before the collision below renamed it to 15; the
+statement is the same one, so what follows stands as the cost of the step):
+
+- **A soft deletion is one row and nothing else.** 0.4–12.5 ms across samples,
+  with 0 canonical or derived rows removed or rewritten: the probe session's
+  1,572 `records_fts` rows and its `titles_fts` row were all still there
+  afterwards, and the session row with them.
+- **Serving drops it everywhere.** The rare term that returned exactly that
+  session's record (1 hit, 3.4 ms) returns 0 of its rows afterwards; three
+  queries — that term, a zero-hit query that took the widening recovery (11
+  widened hits, 5 sessions), and a 50-hit broad query whose hits were all title
+  hits — returned **0 hits from the deleted sessions** (leaked = 0), while the
+  raw index still held their 1,572 + 86 rows and both title rows.
+- **A `--hard` deletion is not cheap and it is complete.** Escalating a
+  32,583-record session took **7.6 s** and removed that many records, leaving the
+  store at 2,616 sessions / 198,970 records; a forced re-derivation over the
+  result took **23.8 s** with both rebuild parity gates
+  (`verifyRecordsFtsRebuild`, `verifyTitlesFtsRebuild`) passing.
+- **A re-scan is refused before it reads anything.** For a claude-code listing
+  whose id *is* the session's native id, and for a codex listing whose id is the
+  rollout filename while the session inside carries a bare uuid — both refused
+  with `sessionNeedsIngest = false` and a direct ingest returning `tombstoned`
+  with **0 source bytes read**. The second case matters: on this store **1,724 of
+  2,681 cursors (64%)** name a listing id that differs from the session's native
+  part, so the naive native-id check would have read most files before refusing
+  them.
+- **The migration increment is invisible.** Opening the v13 copy as a writer
+  (which adds the table) measured 8.7 ms; the same open on the already-migrated
+  file measured 3.4 ms. The one 5.2 s open in this cycle was the *first* open of the
+  copy — the open that had to build the WAL sidecars for a 1.06 GiB file — not
+  the migration.
+- `ledger status` on that copy: `Tombstones: 2 sessions deleted by the user; 1658
+  of the records above are held back from search and reads`; robot payload
+  `"tombstones":2,"tombstoned_records":1658` beside the unchanged holdings counts
+  (`"sessions":2617,"records":231754`).
+- **The production store itself migrated, and kept working.** This host's
+  scheduled `ledger sync` runs this checkout (`~/.local/bin/ledger` is a wrapper
+  for `packages/core/bin/ledger.ts`), so one of its passes during the cycle
+  opened the 1.06 GiB store with this build: `user_version` moved 13 → 14 (the
+  number this cycle claimed at the time; see *Version collision* for why the
+  shipped step is 15, which that store — at 14, table present — is exactly the
+  shape the ladder must accept), the
+  `session_tombstones` table is present and empty, `fts_format` is still `"3"`
+  (the counter did not move — the argument below), and the daemon's own summaries
+  stayed normal (25-session `pending_budget` passes, no error results). That is
+  an unplanned but real end-to-end check of the migration and of the serving
+  filter on the largest store this project has. The flip side, for the owner: a
+  store at v15 is refused by an older build (`SCHEMA_MISMATCH`), so this cycle
+  landing is what keeps the machine's daemon and its store compatible.
+
+The tree's own suite grew by this cycle's cases — `bun test` 601 pass / 0 fail
+across 42 files, including fourteen new cases in
+`packages/core/tests/tombstones.test.ts` and the version-collision case in
+`packages/core/tests/integration-migrations.test.ts`, which pin every claim above
+except the production-scale numbers.
+
+## What the store does — the whole rule
+
+A tombstone closes a session to **serving** and to **admission**, and — in
+`suppress` mode, the default — changes nothing else:
+
+| Surface | What the deletion does | Where |
+| --- | --- | --- |
+| Record lane (`search`) | filtered out of `records_fts` hits | `reader.ts`, `executeFtsQuery` |
+| Title lane (`search`) | filtered out of `titles_fts` hits | `reader.ts`, `titlePrepass` |
+| Widening recovery | same predicate, same lane, so a zero-hit rewrite cannot find it | `reader.ts`, `widenZeroHitQuery` → `executeFtsQuery` |
+| Vector lane (`--semantic`, `--hybrid`) | filtered out of `records_embeddings` scoring | `reader.ts`, `vectorSearch` |
+| `recent` / `last`, session lookup, session records, child sessions, lineage | not listed, not found, no records | `reader.ts` (`sessionById`, `allSessions`, `lastSessions`, `sessionRecords`), `db.ts` (`getChildSessions`) |
+| Ingest admission (pre-read) | the listing is refused before the source is stat-ed | `ingest.ts` (`sessionNeedsIngest`, `ingestDiscoveredSession`) → `db.ts` (`tombstoneForListing`) |
+| Ingest admission (store boundary) | a write for the session id is refused, inside the transaction that would have committed it | `db.ts` (`assertTombstoneFree` in `saveSession`, `appendSessionRecords`, `commitStagedIngest`, `insertRecordEmbeddings`) |
+| Vector backfill | never asks for a tombstoned session's records | `db.ts`, `backfillEmbeddings` |
+| Pending rebuild / queue | cleared: neither can be admitted, and a staged replacement holds the session's records | `db.ts`, `clearAdmissionState` |
+| `status` | **not** subtracted: the holdings counts stay what the store holds, and the tombstone count and the records it withholds are disclosed beside them | `store-status.ts`, `cli.ts` |
+| `build` / `watch` | counted as `tombstoned`, never as `failed` or `imported` | `cli.ts` (`countTombstoned`), `watch.ts`, `sync.ts` |
+
+## The double-track, and why the path is not one of its axes
+
+Wake's pair is `file_path` and the logical session key
+(`crates/wake-core/src/db.rs#L76-L80`: `tombstones(file_path PK, key, deleted_at)`;
+`#L1002`/`#L1014`: both are probed; `crates/wake-core/src/scanner.rs#L224`: both
+filter enumeration). Ledger's pair is `(source, native id)` — as a direct lookup
+and through the store's own cursors — and the Ledger session id:
+
+1. **Listing axis, before the read.** `tombstoneForListing` answers "was the
+   listing this discovery pass is holding deleted?" Two lookups: the direct
+   `(source, native_id)` (the listing id *is* the session's native id — hermes and
+   other listing-keyed sources, and any source that names a session after its
+   file), and a join through `ingest_cursors`, which is the store's own record of
+   *which listing was ingested into which session*. The second lookup is not a
+   nicety: without it a source that keys files by rollout name while the session
+   inside carries its own id would be read in full before being refused — measured
+   at 64% of this store's cursors.
+2. **Session axis, at the store boundary.** Every write path refuses the session
+   id (`assertTombstoneFree`), inside the caller's transaction. This is the axis
+   that catches a copy whose listing looks new — another path, another listing id
+   — because the copy's *content* still normalizes to the same session id. It is
+   also the axis serving uses, so "hidden" and "cannot come back" are the same
+   identity, not two.
+
+**The path deliberately is not an admission key**, though Wake's is its primary
+one. In this store a path is not listing identity: shared stores (hermes,
+deepagents) hold many distinct listings in one file, and this repository already
+has that rule written down and enforced where it matters — `getLiveIngestSession`
+in `db.ts` refuses to treat a path match as authority to delete *another*
+listing's session. Tombstoning a path would therefore silently block every other
+listing in that file, which is a worse failure than the one it would prevent. The
+cursor is the honest Ledger analog of Wake's `file_path`: it is listing identity
+*by construction* (`(source, listing_id, source_path)` is its key), and it is
+already the evidence this store uses to decide who owns a generation.
+
+Wake's other half — absence is not deletion — is structurally true here as well,
+and this cycle pins it rather than changing it: Ledger never prunes a session
+because a file disappeared, and Wake's two non-tombstoning removals
+(`scanner.rs#L272`, owner change; `scanner.rs#L341-L349`, "in the store but gone
+from disk") remove rows *without* a tombstone because they are re-ingestions, not
+deletions. Measurement and tests: a truncated source in place yields
+`deferred` — the repo's existing bounded-rebuild verdict — with the live history
+preserved and the session still served, and a vanished file changes nothing at
+all; neither writes a tombstone, and neither hides the session.
+
+## The identity axis: why not the content hash, and what evades this
+
+`identity.ts` keys a session as `source:native-id`, and the native id is derived
+from the transcript's own content (`normalizer.ts`: `canonicalRecords[0].
+source_group_id || item.id`), not from the path. That is what makes an id-keyed
+tombstone hold where a content-keyed one would not:
+
+- **A copy at another path** carries the same embedded id. Content-keyed or
+  path-keyed suppression misses it; the committed-id axis refuses it. Measured
+  and pinned in `tombstones.test.ts` ("a copy at another path — even under
+  another listing id — is refused by the committed id"): the same file copied
+  under a different name, discovered under a different listing id, is read,
+  normalized, and then refused by the store, leaving no rows, no cursor, and no
+  session behind.
+- **An appended source** (the normal case for these harnesses) changes the
+  content hash — `session-hash.ts`'s v2 digest is explicitly *extendable*, which
+  is a feature for dedup and poison for a tombstone: a content-keyed tombstone
+  would be evaded by the next chunk. The id does not move, so the refusal holds.
+- **A source that was rewritten** keeps the same id when it grows, and changes it
+  when the harness writes a genuinely different session — at which point this
+  store's own identity rules say it *is* a different session, and no
+  content-keyed rule could have said otherwise without inventing an identity the
+  source does not carry (and `AGENTS.md` forbids inferring identity from
+  convenience).
+
+**What evades the axis** (stated, not hidden): a copy whose *embedded* id was
+rewritten — a re-export with a fresh uuid, or a merge tool that renumbers
+sessions — re-enters as a new session, with the deleted one still hidden. Nothing
+in this store's identity model can call those the same session, and a
+content-keyed rule would trade this narrow evasion for a wide one (any append
+resurrects). A path-keyed rule would trade it for silent over-blocking of shared
+files. Both trades are worse; the note records the boundary instead of pretending
+there is none.
+
+## The transaction, and the invariants it leaves
+
+`tombstoneSession` is one `BEGIN IMMEDIATE` transaction:
+
+- `suppress` (default): insert one row (`session_id` PK, `source`, `native_id`,
+  `source_path` for the audit, `mode`, `reason`, `record_count`, `deleted_at`),
+  clear the queued admissions of the listings that fed the session (matched by the
+  tombstone's own native id and by the listings its cursors name) and any staged
+  replacement of it, commit. Nothing else is removed; a crash leaves the row
+  present or absent.
+- `hard`: the same insert, then the session's content in the same transaction —
+  `records_fts`, `records_echo`, `records_embeddings`, `ingest_diagnostics`,
+  staged replacements, `records`, `sessions` (whose delete trigger removes the
+  `titles_fts` row). The deletes are explicit rather than left to the foreign
+  keys, the same stance `trg_sessions_diagnostics_delete` takes: a writer that
+  never enabled foreign keys must still leave nothing behind.
+- Repeat calls are idempotent and never rewrite the audit: a second `suppress`,
+  or a `--hard` on an already-hard row, reports the existing deletion and changes
+  nothing (`created: false`). A `--hard` on a `suppress` row is the one
+  escalation, and it keeps the original `deleted_at` and `reason` — the same
+  deletion carried further, not a second one.
+- **Two ordered writes, never one**: Wake writes its tombstone in the same
+  transaction as its deletes (`db.rs#L537-L571`, insert at `#L565`), and this does
+  the same. Neither store can be caught with the content gone and the source free
+  to re-admit it.
+
+The invariants the derived-index gates name still hold after either mode, because
+soft deletion touches no derived row and hard deletion removes a record and its
+index row in the same count: the rebuild's arithmetic (`records − excluded =
+indexed`) and the title parity (`sessions with a title = titles_fts rows`) both
+pass on a store that was force-re-derived after a hard delete (measured: 23.8 s
+over the production-scale copy). **`FTS_FORMAT` does not move — it stays `"3"`**,
+and that is a decision with a reason:
+
+- The projection `records → records_fts` is unchanged. A tombstone is not a rule
+  over canonical record fields; it is user-authored state about a *session*. Rule
+  version counters exist so a *rule change* costs one re-derivation (C2's note),
+  and there is no rule change here.
+- Hiding inside the index would be erased by the next rule change anyway: the
+  rebuild is a whole-table re-projection from `records` (db.ts, `rebuildRecordsFts`),
+  so an index-only deletion survives only until someone bumps the format — at
+  which point a "deleted" session would quietly return to search unless the
+  rebuild also learned the tombstone rule, which would make `records_echo` (the
+  echo filter's derived set) carry two unrelated derivations and make the status
+  line `echo_filtered` mean two different things.
+- The gates would have to count policy state as if it were data: the parity
+  assertion is `records − excluded = indexed`, so a suppression subtraction would
+  need its own term, and the index would stop being equal to its derivation.
+
+## Review fixes (2026-09-16)
+
+Two P3s from the adversarial review, both fixed on this tree with regression
+tests:
+
+1. **The verb's open could still create a store.** The read-gate classification
+   and the writer open are two statements, and a store that vanished (or was
+   replaced by an empty file) between them was *created* by the open —
+   `delete --list` would even report an empty readout from a store it had just
+   conjured, against this verb's documented "nothing is created or adopted".
+   Fixed by making the open itself refuse to initialize anything:
+   `new TrajectoryDb(path, { requireExisting: true })` opens with file creation
+   disabled (`{ readwrite: true, create: false }`, which is the only bun:sqlite
+   spelling for "writable, never create") and checks the shape *before* any
+   PRAGMA or DDL — `PRAGMA journal_mode = WAL` alone writes to a file, so the
+   check has to come first. A missing, empty, foreign, or newly-vanished store
+   raises `StoreNotInitializedError`, which the verb maps to the read verbs'
+   `STORE_NOT_INITIALIZED`. The option is opt-in: every other writer verb still
+   creates and migrates its store.
+   *Tests:* `a writer told not to initialize one refuses missing, empty, and
+   foreign files without an artifact` (missing → no file; empty → still zero
+   bytes; foreign → its own tables intact; classification-passes-then-file-
+   vanishes → refused, nothing created; a plain open still creates).
+2. **The guards ran outside the transactions they protect.** `saveSession`,
+   `appendSessionRecords` and `insertRecordEmbeddings` checked the tombstone and
+   then opened their write transactions, so a deletion committed by another
+   writer in between was lost: the write landed *under* the tombstone and
+   rewrote the session's records while the deletion's `record_count` named a
+   generation that no longer existed. Each of those methods is now one
+   `BEGIN IMMEDIATE` transaction with its check inside it (nested calls join it
+   as a savepoint, exactly as `commitIngest`'s transaction already did), so the
+   write lock is the serialization point and the check is a verdict rather than a
+   guess.
+   *Test:* `a tombstone from a second writer is honored by a write already in
+   flight` — a second process (`tests/tombstone-race-holder.ts`) holds the write
+   lock with an uncommitted tombstone and announces it; the parent's
+   `saveSession` then runs inside that window and must refuse, with the session's
+   rows untouched. Verified to discriminate: emulating the pre-fix ordering in a
+   throwaway probe (guard as a plain read outside the transaction) shows the
+   guard seeing *nothing* and the write landing anyway
+   (`content_hash = "pre-fix-write"`), which is the failure the test now pins.
+
+Round two (2026-09-16) added: the **version collision with PR #52** — the step was
+renumbered to 15 with a ladder that enters from 13 and from 14 (see *Version
+collision* below, and the reciprocal obligation in *Still open*); this note's
+suite count, which lagged the tree by two cases (597 → 599, and 601 once this
+round's own two cases landed); and a **lineage
+honesty** case at the serving level — a deleted parent leaves serving while its
+children keep `parent_session_id` and lose only the `parent_title` that has to
+resolve through it, in both modes, with the child's row untouched either way.
+That last case is also why the escalation's completeness is asserted where it is:
+`hard` removes the deleted session's own row (the tombstone's snapshot of source,
+native id, path, and record count is what keeps the audit meaningful without it)
+and nothing else.
+
+## Surface
+
+- **CLI.** `ledger delete <session-id> --reason <text> [--hard] [--db <path>]
+  [--robot|--json]`, and `ledger delete --list`. It takes the writer lease, like
+  every other verb that writes (`holder: "delete"`), so a deletion cannot
+  interleave with a pass that is re-admitting the same session and a refused
+  deletion leaves the store as it found it. `--reason` is required: the row is
+  the mechanism's account of why, and a tombstone that cannot explain itself is a
+  hole in the record the audit exists to be. Text output says which mode the
+  deletion took and what it left behind; robot output is one
+  `{"type":"tombstone", …}` object (JSONL for `--list`). An id the store does not
+  hold is refused with `SESSION_NOT_FOUND` — a tombstone for a session that was
+  never ingested would be an *exclusion rule*, a different mechanism with
+  different consequences, deliberately not shipped as a side effect of this verb.
+- **Status.** `tombstones` (sessions) and `tombstoned_records` (records still
+  held behind a `suppress` deletion) in `status --robot`/`--json`, and a text
+  line: `Tombstones: N sessions deleted by the user; M of the records above are
+  held back from search and reads`. Both are `0`, never null, for a store that
+  predates the table — a store no build could have written a tombstone into has
+  an empty set, not an unknown one.
+- **Library.** `TrajectoryDb.tombstoneSession(id, {reason, hard?, now?})` →
+  `TombstoneOutcome` (`tombstone`, `created`, `escalated`, `recordsRemoved`),
+  `getTombstone(id)`, `tombstoneForListing({source, id})`, `listTombstones()`;
+  `SessionNotFoundError` and `TombstonedSessionError` (both with a `code`); the
+  `TombstoneRecord`/`TombstoneMode` row types. `TrajectoryReader` gains no write
+  method and no tombstone method: it serves, and it serves filtered.
+- **Version collision with PR #52.** The step was designed as 13 → 14 and had to
+  be renumbered before this landed: the owner's public-alpha branch (#52) claims
+  14 for `source_discovery`, and one store carries one `user_version`, so
+  whichever branch's code ran second would have found the number already at its
+  target — and skipped the other's `CREATE_TABLES_SQL` upgrade, because nothing
+  in the ladder re-runs DDL for a version it is already at. The boring correct
+  fix is not to number a diff but to say what the step does: this build claims
+  **15** and *enters the ladder from both shapes* — 13 (neither table) and 14
+  (#52's table, ours missing) — adding what it knows through the same idempotent
+  `CREATE_TABLES_SQL` and leaving unknown tables alone. A store migrated by
+  either branch therefore converges from either direction, and #52's ladder needs
+  the same two-sided treatment (recorded here for the owner; the note's
+  *Still open* list carries it). 14 is reserved, not skipped.
+- **Schema.** `SCHEMA_VERSION` 13 → 15; `session_tombstones` plus an index on
+  `(source, native_id)`; no dedicated migration constant — like v12, the table
+  arrives from the same `CREATE_TABLES_SQL` a writer open already runs, and no row
+  is fabricated. The table is deliberately **not** in `REQUIRED_READ_SCHEMA`: the
+  read path probes for it and skips the predicate when it is absent, which is
+  exact rather than tolerant — a store without the table is a store no build
+  could have written a deletion into, and a store *with* tombstones can never be
+  read unfiltered by an older build, because the read gate refuses a store whose
+  `user_version` is newer than the build supports. One `sqlite_master` lookup per
+  serving call (the same shape the title lane already pays), not per row.
+
+## Decisions
+
+1. **Suppress by default, `--hard` behind an explicit flag.** `AGENTS.md`'s
+   "preserve raw evidence" and "source truncation is not authorization to erase
+   captured evidence" both point one way: the mechanism must not make deletion the
+   one write that destroys what an adapter already attributed, and the audit row is
+   more useful beside the rows it names than instead of them. Wake's own shape is
+   the opposite (its removal is the index's removal) because its store *is* the
+   index; Ledger is a system of record, so its deletion removes a session from
+   service, not from history. The privacy posture is still real: the user asked for
+   it to be gone from search and from re-import, and it is — everywhere, in every
+   mode. `--hard` exists for the case where the request is "not on this disk
+   either", and it says what it costs.
+2. **A tombstone is not an exclusion rule, and the verb never creates a
+   store.** Only an existing session can be deleted; an unknown id is refused,
+   a `--db` path with no store (or one that is not a Ledger store at all) is
+   classified by the read gate and refused with the read verbs' own codes and
+   wording instead of a writer open initializing or adopting the file — creating
+   stores is `sync`'s and `build`'s job. The canonical executable resolves its
+   XDG default and refuses there too, because `delete` is deliberately not one of
+   the commands that create the data directory. "Never ingest this" is a policy artifact
+   (a deny list) with different lifetime, scope, and failure semantics, and
+   smuggling it into the deletion verb would make an operator's typo silently
+   permanent.
+3. **Status reports holdings and discloses the deletion.**
+   `countSessions`/`countRecords` are what the store *holds*, tombstones
+   included; subtracting them would claim the store holds less than it does and
+   would hide exactly the data the audit decision keeps. The disclosure is two
+   fields and a sentence. This is the enforcement point that is *not* a filter,
+   and the reason is the decision above it: a soft deletion retains, so a count
+   that "looks deleted" would be a lie the rest of the mechanism doesn't tell.
+4. **`--reason` is required.** The row exists to explain the deletion months
+   later; the flag costs one sentence. This is a mechanism default, not a policy
+   position (see the non-goal below): if the owner's policy says a deletion may be
+   unexplained, relaxing it is a one-line change and the row keeps a timestamp.
+5. **No restore verb this cycle.** The tombstone is plain rows in one table, so
+   restoring is one `DELETE FROM session_tombstones` — but *who may undelete* is
+   the same policy question as who may delete, and shipping a one-flag escape from
+   an audit row would undercut the audit. Recorded as a boundary, not an oversight.
+6. **A hard deletion keeps no copy of what it removed** — no staged replacement,
+   no queue entry with the session's title, no diagnostics — because "irreversibly
+   removed" has to mean something. What it keeps is the tombstone: the axis that
+   stops the source from putting it back, and the audit that says it happened.
+
+## Policy: an explicit non-goal
+
+This cycle ships the **mechanism** and says so in the verb's own help and its
+`docs/api-surface.md` section: who may delete, how long a record may be kept,
+whether a deletion must be explained, what a deletion means for a *published*
+derivative, and whether a restore exists are the retention/privacy policy this
+repository has not decided. Wake's product answers some of that outside its store
+— its delete is a desktop action that moves the session files to the system Trash
+and then tombstones them (`crates/wake/src/workbench.rs#L4594-L4609`) — and the
+program's own row for C7 names "explicit delete semantics before anyone trusts us
+with their history" as the buy, not a retention schedule. The mechanism is
+deliberately narrower than the policy so the policy can still be chosen; what it
+must not be is *undefined*, which is what "deletion today is undefined" meant.
+
+## The roadmap row
+
+> **C7** Tombstone double-track (path + logical key, same transaction as removal)
+> — *Fixes/buys:* deletion today is undefined; source truncation is not
+> authorization to erase, and user deletion must survive re-scans. *Open-source
+> case:* privacy posture: explicit delete semantics before anyone trusts us with
+> their history; Wake's tombstones + system Trash is the reference UX.
+> (`docs/research/2026-09-16-wake-port-program.md`)
+
+Ported: the tombstones table with its axis pair and its same-transaction rule, the
+double-track admission filter at enumeration, `absence ≠ deletion`, and the tested
+pair itself (`crates/wake-core/tests/db_roundtrip.rs#L82-L113` pins
+`is_tombstoned` by path and `is_key_tombstoned` by key). Adapted: the path axis
+becomes the store's cursor link (see above — Ledger's paths are not listing
+identity), the logical key becomes the committed session id, and the removal is
+split: suppression by default, record removal behind `--hard`. Not ported: the
+system-Trash half of Wake's UX (a CLI has no Trash), and the UI affordances
+(confirmation prose, per-platform wording).
+
+## Files
+
+- `packages/core/src/schema.ts` — `SCHEMA_VERSION` 15 (the ladder's hole at 14 is
+  PR #52's `source_discovery`; both 13 and 14 enter here); the `session_tombstones`
+  DDL and its index, with the axes, the mode split, and the `FTS_FORMAT`
+  argument written where the table is.
+- `packages/core/src/db.ts` — `tombstoneSession`, `getTombstone`,
+  `tombstoneForListing`, `listTombstones`, `TombstoneOutcome`,
+  `IngestCommitOutcome`, `SessionNotFoundError`, `TombstonedSessionError`; the
+  write-boundary guards; the admission-state cleanup; the raw-row view the writer
+  needs (`sessionRowById`) separated from the serving view (`getSession`).
+- `packages/core/src/reader.ts` — `tombstonePredicate` and its five call sites
+  (record lane, title lane, vector lane, session reads, record reads), plus the
+  holdings note on `countSessions`/`countRecords`.
+- `packages/core/src/ingest.ts` — `IngestKind` grows `tombstoned`; the listing
+  admission check in `sessionNeedsIngest` and `ingestDiscoveredSession`; the
+  commit refusal converted to the same verdict (`tombstonedIngestResult`).
+- `packages/core/src/cli.ts` — `handleDelete` (verb, `--hard`, `--list`,
+  `--reason`), the typed `SESSION_NOT_FOUND` refusal, `status` fields and text,
+  `build`'s `tombstoned` accounting, help text.
+- `packages/core/src/store-status.ts` — `tombstones` / `tombstonedRecords`.
+- `packages/core/src/sync.ts` — a listing the store refused leaves the queue
+  (instead of returning as a retry every pass).
+- `packages/core/src/watch.ts` — the `tombstoned` event kind, counted with skips.
+- `packages/core/src/types.ts`, `index.ts`, `docs/api-surface.md`, `README.md`,
+  `packages/core/README.md` — the row types, the exported refusals, the documented
+  surface (verb, flags, robot shapes, table, ADR entry, `status` fields). The
+  agent-facing skill (`skills/ledger/SKILL.md`) is deliberately *not* told that a
+  delete verb exists: whether an agent may delete is exactly the policy question
+  this cycle leaves open.
+- `packages/core/tests/tombstones.test.ts` (new, 14 cases) — serving, holdings,
+  the audit and its idempotence/escalation, the two admission axes, the copy,
+  absence and truncation, `--hard` completeness and the index gates after it, the
+  staged-replacement cleanup, the pre-v15 shape, the verb end-to-end (including a
+  `--db` path that holds no store and one that holds a foreign SQLite file: both
+  refused, nothing created or adopted), the `requireExisting` open's artifact-free
+  refusals (missing, empty, foreign, vanished), the two-writer race whose outcome
+  the guards' placement decides, and lineage honesty for a deleted parent in both
+  modes (children keep `parent_session_id`, the parent's `parent_title` stops
+  resolving, and nothing reaches the child's row).
+- `packages/core/tests/tombstone-race-holder.ts` (new) — the second writer that
+  race test needs: it holds the write lock with an uncommitted tombstone and
+  announces it on stdout.
+- `packages/core/tests/integration-migrations.test.ts` — the final version is 15,
+  plus the collision case in test form: a store shaped at 14 (PR #52's
+  `source_discovery` table, no tombstone table) migrates to 15, gains the
+  tombstone table, and leaves the other branch's table alone.
+
+## Still open (recorded, not hidden)
+
+- **PR #52's inverted ladder is closed on this combined build.** C7 claimed 15
+  and accepts a store at 13 or 14; the stabilization branch now writes 15 as
+  well, accepts an already-v15 store that has `session_tombstones`, and still
+  acquires `source_discovery` from the same idempotent DDL (pinned by
+  `integration-migrations.test.ts` in both directions). Remaining items below
+  are unchanged C7 leftovers.
+- A member listing of a deleted *grouped* session is refused at the store
+  boundary, which means one read of that file on the first pass that discovers it
+  (and none after: the pass drops the listing). Closing it needs the group
+  mapping at admission time, i.e. reading the file — the current split (cheap axis
+  first, authoritative axis at the write) is the honest ordering, and the
+  alternative would move a deletion verdict into the ingest state machine.
+- Rewriting a source's embedded id evades the axis (above). A deny list is the
+  mechanism that would cover it, and it is policy.
+- `--hard` on a session with a very large record count is not fast (7.6 s for
+  32,583 records); it is a single transaction, so it is atomic, not incremental.