diff --git a/outputs/VYNDR-COMPLETION-MATRIX.md b/outputs/VYNDR-COMPLETION-MATRIX.md
index fb9504d..ee4ec0b 100644
--- a/outputs/VYNDR-COMPLETION-MATRIX.md
+++ b/outputs/VYNDR-COMPLETION-MATRIX.md
@@ -183,3 +183,5 @@ Gates the champion's over-CLV signal (partial r=0.375, p≈0.003, n=62 takeable
 - This is one significant result among many computed this session — do not overstate.
 
 **What would strengthen it:** retain multi-book at lock (enables the sharp/consensus lock-staleness check), and accrue more settled takeable MLB-over rows. Held: no promotion, no served p_win/ev, no capture fix — diagnosis only.
+
+**UPDATE 2026-07-29 (commit c7067c8): the lock-multi-book gap is now CLOSED.** New `lock_lines` table (migration 033, applied+tracked) persists each graded prop's per-book lines at the lock moment (`lockLineCapture` in `snapshotService`, fenced RLS-service-role-only, grade byte-identical proven). This unblocks the staleness audit for FUTURE rows — it does NOT retroactively fix the existing 62. Confirmation still needs weeks of accrued lock+close+outcome. Populates from the next snapshot tick.
diff --git a/specs/STATE.md b/specs/STATE.md
index 853f93b..2cb50be 100644
--- a/specs/STATE.md
+++ b/specs/STATE.md
@@ -61,6 +61,19 @@
 > thin n; Phase-2 lock-staleness check BLOCKED (no multi-book retained AT LOCK — `bookprices`
 > is Redis current-only); pinnacle sharp ref only n=8 (+3.17pt, hint). Fix that would
 > strengthen it (NOT built): retain multi-book at lock + accrue sample. Promotion HELD.
+
+> ## 🔓 LOCK-LINE PERSISTENCE shipped 2026-07-29 (commit c7067c8): unblocks the staleness audit
+> The audit's BLOCKED check (was our locked line stale-high vs consensus AT LOCK?) is now
+> being unblocked. New `lock_lines` table (migration 033, applied+tracked) — the lock-time
+> analog of `closing_captures`. `lockLineCapture.buildLockRows` persists each graded prop's
+> per-book lines (both odds + a lock timestamp) from the in-memory `props` at the lock
+> moment (`ts`, no Redis re-read → no TTL race), in `snapshotService` right after
+> `enriched`. FENCED: RLS-no-policies (service-role only) + a grep test — read by nothing on
+> the grade path; grade byte-identical proven (runSnapshot grades identical with persist
+> on/off). **Accrues FUTURE rows only — does NOT retroactively fix the existing 62; the
+> confirming audit still needs weeks of settled lock+close+outcome rows.** Volume ~1.5-3k
+> rows/day. Populates on the next snapshot tick (14:00 UTC); no promotion, no served edge,
+> no capture-of-close change. Next: let it accrue, then re-run the staleness audit.
 - **Redirect EXISTS + WIRED:** `closingCapture.buildCaptureRows`→`closing_captures` (append-only,
   provenance: captured_at/book/line_type/both-prices/missed_reason) via `intradayRefreshService:221`
   + internal endpoint; `ledgerService.attachClosingProb`→`closing_prob` (de-vigs both raw sides,