You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Record the deployed commit for each layer source #473
Finding, 2026-09-06: the deployed commit per layer is already recorded — in the graph, not the trace.
Today's first base-layer deploy (writ deploy --allow-dirty --conflict=replace common, two layers) left this
in the persisted graph, graphs/sha256-ff9be840….yaml:
deploy.go pins every layer source to a detached git worktree at HEAD before planning
(snapshot.Pin, under ~/.cache/devlore/snapshots/<layer>-<hash12>/), and PinInfo.CommitHashes / DirtyLayers "ride the graphs' origin annotations" (plan.go, pkg/op/graph.go:702). Both layers'
hashes and the dirty-layer list are there.
The trace for the same run carries none of it — top level is still graph_checksum run_status stack catalog checksum signature — and writ reconcile reports layer per entry but no commit. So
the question "what was deployed here, and from where" is answerable today by reading the graph, and
by nothing a user actually runs.
What this changes for beat 3
Not "record the commit" — it is recorded. Surface it: the trace's metadata gains the origin block
(layer, repository, ref, dirty) copied from the graph's annotations at run time, and reconcile
prints the ref beside the layer. That is smaller than the beat was filed as, and it is exactly the
shape #806 sketched.
One semantic worth writing down while here
Plan from HEAD, serve from the working tree. Planning enumerates the pinned snapshot, so an
uncommitted addition is never linked and an uncommitted deletion is planned and then dangles. But
the links themselves point at the working tree (~/Workspace/…/Home/…), not the snapshot — the
snapshot is removed after the run — so a file that exists at HEAD and is locally modified serves the
modified content. --allow-dirty only lifts the refusal; it does not change any of that. The origin
block should say dirty: true for such a layer, which DirtyLayers already knows.
Closes with #971 (lane 17 of #916), 2026-09-28: under kept snapshots each layer is pinned by a refs/devlore/ ref and the record names each layer's commit and snapshot, so the deployed commit per layer is structural.
Activity
David-Noble-at-work commentedon Sep 6, 2026
Finding, 2026-09-06: the deployed commit per layer is already recorded — in the graph, not the trace.
Today's first base-layer deploy (
writ deploy --allow-dirty --conflict=replace common, two layers) left thisin the persisted graph,
graphs/sha256-ff9be840….yaml:deploy.gopins every layer source to a detached git worktree atHEADbefore planning(
snapshot.Pin, under~/.cache/devlore/snapshots/<layer>-<hash12>/), andPinInfo.CommitHashes/DirtyLayers"ride the graphs' origin annotations" (plan.go,pkg/op/graph.go:702). Both layers'hashes and the dirty-layer list are there.
The trace for the same run carries none of it — top level is still
graph_checksum run_status stack catalog checksum signature— andwrit reconcilereportslayerper entry but no commit. Sothe question "what was deployed here, and from where" is answerable today by reading the graph, and
by nothing a user actually runs.
What this changes for beat 3
Not "record the commit" — it is recorded. Surface it: the trace's metadata gains the origin block
(layer, repository, ref, dirty) copied from the graph's annotations at run time, and
reconcileprints the ref beside the layer. That is smaller than the beat was filed as, and it is exactly the
shape #806 sketched.
One semantic worth writing down while here
Plan from HEAD, serve from the working tree. Planning enumerates the pinned snapshot, so an
uncommitted addition is never linked and an uncommitted deletion is planned and then dangles. But
the links themselves point at the working tree (
~/Workspace/…/Home/…), not the snapshot — thesnapshot is removed after the run — so a file that exists at HEAD and is locally modified serves the
modified content.
--allow-dirtyonly lifts the refusal; it does not change any of that. The originblock should say
dirty: truefor such a layer, whichDirtyLayersalready knows.David-Noble-at-work commentedon Sep 28, 2026
Closes with #971 (lane 17 of #916), 2026-09-28: under kept snapshots each layer is pinned by a
refs/devlore/ref and the record names each layer's commit and snapshot, so the deployed commit per layer is structural.