glm-5.3-flash
6c583af81a
Root cause of the two taskgraph validate errors: the sdd_process doc never recorded the full frontmatter enum set (impact was entirely undocumented), so agents invented variants. - oq-06: status done → completed; n5-unborn-head-rider: impact wire-claim → component (schema-valid nearest value). - oq-19/oq-21 tracker files had no frontmatter at all (silently skipped by every taskgraph command — validate does not flag them); scaffolded both as proper tasks. oq-19 now depends_on the n5 rider task (rider 1 executes there; the container closes when both done), with a body note explaining the split. - sdd_process.md: added the impact table, the exact enum variant list for all five categorical fields (probed from taskgraph 0.1.3), and the three gotchas agents hit (done ≠ completed; frontmatter-less files silently vanish from the graph; closed status lifecycle). Verification: taskgraph validate ✓ (9 tasks), taskgraph topo shows the n5 → oq-19 edge correctly.
2.9 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) | pending | 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
When the session runs, lfs.md (§Lock server) and the OQ-21 entry
record the outcome; OQ-03's blocked-on drops this item (resolved or
retracted). The build deferral itself only closes on a real client
requirement.