graduate(dn-vector-membership-store): mint bp-151..153 + the §6 amendment — merging this is the blessing

[ascalva]

⚑ Merging this PR is the blessing of dn-vector-membership-store

This is the signal issue #27 asks for. The note (one vector row per idea-atom + a membership
relation owning occupancy/currency — the store model finding-0168's five owner rulings mandated)
landed on main by direct commit 2026-07-23, one day before the merge-gated regime, so it never
had a blessing event: status: draft, and the old hand-flip ceremony no longer exists. Per the
owner's ruling (2026-08-01) the two gates collapse into one — this merge ratifies the note and
readies the plans in a single act. No status field is edited by this PR; they are provenance
description, not gates.

closes #27

---

What changed

Two commits, one logical unit (graduation + the amendment the note's §6 requires):

1. graduate(dn-vector-membership-store) — mints bp-151, bp-152, bp-153 (+ journals),
   all status: proposed.
2. amend(dn-temporal-code-corpus) — the two §6 mechanism re-homes, banner-ed inline at the
   passages they correct. Frontmatter untouched.

plan	scope	items	estimate
bp-151	canonical atom identity (D0)	4	250k opus
bp-152	membership store, lander, read path (D1/D2/D3/D8)	8	650k opus
bp-153	rebuild, gauges, probe re-home, compaction (D6/D7/§3/§6)	7	500k opus

⚑ The one judgment call for your eye: three plans, not two

Issue #27 and the note both say two ("store+land+read; rebuild+gauges+probe+compaction"). §8
delegates the final split to graduation — "split at /graduate against the then-current tree" —
and against HEAD, D0 separates on all four of the graduate skill's sizing tests:

1. One-sentence objective. "store + land + read" needs two ands; "identity hashes the canonical
   body" does not.
2. Write scope a reviewer can hold. bp-151 is one production file — there is no external
   production caller of derive_code_chunks/code_rows (code_corpus.py:272,277). bp-152 is a new
   store + a schema evolution + a lander.
3. Different blast radius. bp-151 writes no stored data at all; bp-152 changes a live schema.
   Blast-radius ordering is a within-plan rule — honoring it across plans is strictly better.
4. Independently falsifiable, with numbers already measured. §8(h)/§8(i) discharge here and
   nowhere else, against a three-rung counterfactual ladder (38 → 7 → 0 atoms on a rename) that
   localizes a failure to the exact half of D0 that broke.

D0 is also the precondition for the rest — finding-0168 addendum 4 raised edit-stable chunk
identity to load-bearing, and D1/D2's dedup claims are only true once identity survives a rename.
Landing it first means bp-152 builds on an identity already proven stable rather than proving both
at once. Full reasoning: bp-151 §12. If you'd rather have the note's two, say so and I'll
re-graduate — this is the deviation to rule on.

Why — the warrant

• finding-0168 (frozen) — the five owner rulings: vectors are the versioned entities; succession
  belongs to the (path, slot) occupancy chain; the plane is append-only; n(v) is first-class;
  a rename mints no vector, only a membership edge (addendum 4).
• The 2026-07-27 identity ruling (docs/brainstorms/strip-headers-from-the-atom-hash.md) — D0's
  warrant: a filename is mutable, so headers inside the hash sever every occupancy chain on git mv.
• Owner confirmations, 2026-08-01 (issue Bless dn-vector-membership-store: panel-hardened, measured, graduation-shaped — one owner signal unblocks four tracks #27's two sub-confirmations): S4/F4 re-measurements
  stand; embed-reuse is pinned to the embedder identity (EmbeddingConfig.model + dim,
  config/loader.py:138-141) — carried in bp-152 §6 with its own test case, because a suite that
  exercises only one embedder cannot see that bug. It also governs bp-153's 13,311-atom carry-forward
  seed, where it is the difference between a free migration and a corrupted plane.

Unblocks four tracks: erratum-relation (bp-129 PD-A, bp-131 PD-H both park on this note verbatim),
ops (structurally retires the re-land idiom), code-ingest (2.34× measured embed waste),
deployed-instances (atoms+memberships are the structure seed's natural substrate, PR #26).

How it was verified

Docs-only diff — zero Python touched, so per the pr skill this is a read-through plus structural
validation, not a code gate. Stated plainly: I did not run the pytest gate (and per #22 the local
gate is unrunnable on a main checkout — the on-the-real-stores clock-law tests scale with the corpus
and never return). CI runs the four verdicts on this surface.

What I did run:

• Grounded pass, not a decomposition. Every path:line the note cites re-opened at HEAD
  174d06c; git log --since=2026-07-27 shows zero drift in all nine files.
• Acceptance-reachability check (the skill's flagged recurring failure — findings 0177/0191/0204):
  walked every §7 criterion, enumerated the files it must modify, confirmed each appears in §5.
  It caught a real one — see gap 2 below.
• Structural validation: all three plans carry template sections 0–12 with none missing;
  write_scope entries are bare globs (no bp-066 inline-comment footgun).
• Enrollment checks: mypy is directory-scoped (files = ["core", ..., "ops", ...]) so new modules
  need no pyproject.toml entry; the inner-ring fixed point stays green because core.stores is a
  docstring-only marker whose sqlite submodules compute outer (rings.py:49,102) — placement
  alone satisfies the C5/D3 ring pin, no kernel edit needed.

Two citations confirm the note's disputed positions on the code itself:

• code_corpus.py:80-81 — content_hash really is sha256(self.text) over header-bearing text.
  D0's defect, at its source.
• code_lineage.py:151-156 — appends only when chain[-1] != new_blob, i.e. adjacent repeats
  only. [A,B,A] survives, so F4's file-grain half is disputed correctly. The docstring's
  "ordered distinct sequence" (:139) is loose language, not the behavior — corrected in bp-153 Item 5.

Three gaps the note does not carry

1. D1's "no shed row enters group_sources" is over-broad. The default read path is safe —
grouped_semantic_search passes MIRROR_READABLE = {AUTHORED_SOLO, AUTHORED_DIALOGUE}
(index.py:131-133, provenance.py:96-97). But source_sets(store) explicitly defaults to all
strata (sourceset.py:148-156) and group_sources keys on r["digest"] (:131), so shed code
atoms carrying digest='' collapse into one bogus SourceSet keyed '' — and
MixedProvenanceError never fires, because it needs mixed provenance and these rows are uniformly
CODE. It fails silently. bp-152 Item 3 builds a structural guard (a test asserting "no exception"
would itself be vacuous, and the plan says so).

2. bp-153 Item 6 was unbuildable as first drafted — caught by the reachability check. The typed
shim declares VectorTable with add/count_rows/delete/update/to_arrow/search/scan and no
compaction member (typedshims/lancedb.py:82-97), and the shim wasn't in write_scope. Widened, and
the note's "if the shim lacks the API, that is a finding" split into its two real cases: widening
our own Protocol is ordinary in-scope work; the pinned lancedb lacking the capability underneath
is the finding.

3. The rebuild baseline has moved. The note measured 22,621 rows on 2026-07-27; palace status
reports 33,861 today. The portable claim is therefore the ratio (~2.34×), not the absolute
22,502 — bp-153 Item 1 re-derives both read-only before anything is spent. Related: #28 (the
reference_edges docstrings are 8.4× stale) is the same defect class, and bp-153's journal carries
the rule explicitly — a count is a query, not a comment.

Minor: the note's §6 cites the two re-home passages at :141-143 and :125-126; both are ~9 lines
stale (:141-143 is now D6, the embedder axis). The passages say exactly what the note claims and are
banner-ed at their true lines, :150-153 and :134-135.

What still does not wait on you

Nothing in this PR. bp-151 has zero operational preconditions. bp-153 Item 3 alone is gated on an
owner op you already hold — clearing the wedge and draining the backlog (D7/S6) — and the plan's
instruction is to park that item and continue, never to block the session.

🤖 Generated with Claude Code

https://claude.ai/code/session_011LZZQPyGsoeGL73cbbEp3U