memory: snapshot — U5 released at v0.3.0, and the index goes two-tier
The two dated log sections had never been split, so every one of their 29 entries sat inline and the startup index had grown to 372 lines — which is the cost the two-tier scheme exists to remove, paid on every session that reads the file. 27 entries were over threshold. All 29 now have a detail file under persistent-memory.d/ and a one-line index entry that routes rather than restates. Index: 372 -> 93 lines. No archival. The soft cap fired, but every entry in this repo is dated 2026-09-21 or later, so the under-14-days guard held all of them back — and the split alone took the index well under the target without moving anything out of the active file. The in-flight section is rewritten for the post-release state: nothing is in flight, no gate is outstanding, and the next unit is explicitly recorded as the operator's undecided call rather than as a plan. The session's recommendation (U4, on three grounds) is written down so it does not have to be re-derived, alongside the two alternatives and why they are alternatives. Two dated predictions are carried forward with their dates and their instruments: the U5 adoption re-measure on 2026-09-29, which already reads 3 of 24 announced and 2 with a why from peers told nothing, and the .forever re-count a fortnight AFTER U4 lands, which is U4's own success criterion and is destroyed by running it early.
This commit is contained in:
@@ -0,0 +1,21 @@
|
||||
# Marks are one `.marks.json` per booth
|
||||
|
||||
_2026-09-21 · booth_
|
||||
|
||||
**Marks are stored as one `.marks.json` per booth**, atomic
|
||||
temp-file + `os.replace`, `fcntl` lock on the read-modify-write — operator
|
||||
decision, this session. Two alternatives were weighed and lost: a sidecar
|
||||
per item (`<rel>.marks.json`) and extending the existing `<stem>.ask.json`
|
||||
shape. Rationale, and the reason it is not `links.md`-shaped: **(a)** U4
|
||||
makes *"does this booth owe an answer?"* a hot question — the sweep asks it
|
||||
per booth per tick and the index asks it per card per page load, so per-item
|
||||
sidecars turn it into a full walk of all 25 booths, one of which holds 270
|
||||
files; **(b)** `links.md` is an `O_APPEND` content-hash log because **17
|
||||
agent handles write it concurrently**, whereas marks have exactly one writer
|
||||
(the operator, in one browser) and many readers — a different problem that
|
||||
must not inherit the append-log design; **(c)** `.blurred` / `.pins` /
|
||||
`.forever` already establish the per-booth dotfile as the house shape for
|
||||
operator state, and `booth_items()`'s dotfile skip means it costs nothing in
|
||||
counts, galleries or zips. Accepted cost: a corrupt `.marks.json` loses that
|
||||
booth's marks rather than one item's. Implementation deferred to U2 —
|
||||
tracked at `ROADMAP.md` U2 and by this entry.
|
||||
Reference in New Issue
Block a user