Skip to content
quarry Tags and Properties
Login

Tags and Properties

Tags and Properties for Check-in e326831901

Context
2026-08-17
13:13
ci: wire the trigger, poll runs, record the verdict as a tag

Completes the loop 0001 §6 describes. The trigger runs after each ingest fold — the moment a check-in becomes visible whatever brought it in, a local commit, a push or a sync. A poller refreshes runs quarry still thinks are going, and a terminal run becomes a tag artifact on the check-in, so CI history clones with the repository instead of living in the forge.

The verdict tag is --raw, and that is not a detail: without it the name enters the symbolic namespace where it resolves to a check-in like a release name, and the SECOND check-in to pass would make 'ci-pass' ambiguous for both. zit#80 landed exactly this last night.

It is written through the lease holder, like every artifact quarry mints, so two nodes cannot both record a verdict.

Proven end to end against the live dagnats: a commit to synthetic launched ci/build.json read AT that check-in, the run was recorded, cancelling it drove the poller to write ci-fail with the run id as the tag's value, and the tag came back through ingest into the index. check-in: e326831901 user: dmestas tags: trunk

2026-08-14
20:06
root: RFCs, Go skeleton, ops registry core with import-graph gate check-in: 7619ba9563 user: dmestas tags: trunk