glm-5.3-flash
a54a75abd9
- The OQ-21 branch-mode POC ran (commit 9f520a9 on poc/w10-oq21-lock, dropped): the real lfs.locks API composes over the substrate stack against a real git-lfs 3.7.0 client with lfs.locksverify true. - The mapping decided with a corrected claim: plain co-tenant rows carry the exclusion, not alkstore's named-TTL machinery — the machinery's silent TTL lapse is the two-writer data-loss window, its custody is process-local, and its trait surface carries no enumeration for the API's list/verify verbs (all measured, alkstore 0.1.0); positions stated on TTL lapse (N/A — no TTL) and renew (N/A — no client verb; measured that published renew DOES refresh the exclusion, a new full TTL window from now). - The verify-then-transfer interplay confirmed: a locked-by-another push refused before the batch (no transfer, no residue); the unlock- then-push riding the pre-keyed custody unchanged. - The sqlite contact point measured: lock-traffic hammer vs receive- pack on the co-tenant file — push median ~1.3-1.6x under concurrent lock traffic, zero storage failures (closes the DQ-7 gap). - Records: lfs.md §Lock server note; OQ-21 entry (Investigation resolved, build deferral stands unchanged); OQ-03's substrate publish blocker dropped; README's OQ summary updated; the POC task + tracker completed (taskgraph valid). Verification: cargo test (default + --all-features, live pg green), clippy --all-targets/-D warnings (both feature sets), fmt --check, cargo doc --no-deps, the fuzz corpus gate (13 passed).
3.7 KiB
id, name, status, depends_on, scope, risk, impact, level, tags
| id | name | status | depends_on | scope | risk | impact | level | tags | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| architecture/oq-21-lfs-lock-validation | OQ-21 — LFS lock-server composition-validation POC (owed before the v0.1 publish) | completed |
|
narrow | low | component | research |
|
OQ-21 tracker: the LFS lock server — composition validation
Tracker for OQ-21 (deferred(scope), two layers): the surface build
stays deferred on the first client needing lfs.locks;
the composition validation owed before the v0.1 publish is this
task. The specs currently assert "the door routes and alkstore lock
machinery (named TTL locks) exist and compose" — that compose half has
no execution evidence (POC-L recorded the lock server as
unimplemented); this POC supplies it or forces a retraction.
What the POC walks
The real lfs.locks API flows over the substrate stack, against a
real git-lfs client with lfs.locksverify true (the default on
their side — no workaround posture in this session):
- create/list/verify/unlock over the batch door's routing — the four API verbs (create lock on a path, list with cursor/filters, batch verify before transfer, unlock) mapping onto co-tenant lock rows.
- alkstore's named-TTL lock machinery against the API's actual
semantics — LFS locks are explicit create/delete path exclusions
(created-at timestamps, no server-side TTL expiry), so the candidate
mappings are (a) the lock machinery's TTL + release as the custody
carrier and (b) plain rows; the POC decides which shape is honest
rather than guessing. Note alkstore's contract rows: exclusion
lapses silently on TTL expiry,
renewdoes not refresh TTL — any mapping must state a position on both. - Co-tenancy contact points — lock rows and machinery on the engine alkblobs and alkstore share; on sqlite, the single-writer contention shape: does lock-acquire/verify traffic contend with receive-pack writes on the same file? (DQ-7's measured story did not include lock traffic.)
- The verify-then-transfer interplay with POC-L's custody pieces — lock verification rides the same batch/transfer href/token plumbing; confirm the composition survives the pre-keyed wire-put world of alkblobs 0.2 (ADR-020 there).
The two outcomes
- Posture evidenced: the "exists and compose" claim gets its record; the build deferral stands unchanged, the OQ entry's Investigation section resolves to the evidence pointer and OQ-21 reduces to the pure deferred(scope) on the build.
- Substrate gaps found: they surface as upstream asks (alkstore/alkblobs ADR conversations) while the family is young — the cheap failure mode, versus a publish-time guess made "real".
Resolution note
Resolved 2026-10-24 (the POC ran in branch mode — poc/w10-oq21-lock,
commit 9f520a9, dropped after the merge): posture evidenced. The
lfs.locks API composes over the substrate stack against a real
git-lfs 3.7.0 client with lfs.locksverify true — create/list/
verify/unlock over co-tenant plain rows (the decided mapping: the
named-TTL machinery measured out — silent TTL lapse, process-local
custody, no enumeration surface — so the rows carry the exclusion),
the verify-then-transfer interplay confirmed (locked push refused
before the batch; the unlock-then-push riding the pre-keyed custody
unchanged), and the sqlite contact point measured (push median
~1.3–1.6x under concurrent lock traffic, zero storage failures). The
full record: open-questions.md §OQ-21's Investigation;
lfs.md §"Constraints and posture" — the Lock server note. OQ-03's
substrate publish blocker dropped. The build deferral stands unchanged
and closes only on a real client requirement.