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
Follow-up surfaced reviewing PR #8 (closes #7). The default registry now ships gate-self-mod (path) + checkpoint-removed (semantic) + destructive-ops, which is a real improvement. But the self-protection is self-referential: the thing that guards the registry lives in the registry, so removing it removes its own guard in the same act.
With-base / self-removal leg: even with a base registry, a checkpoint cannot detect its own removal. Documented on-disk:
residual_gap_adr0010_checkpoint_removed_itself_removed (src/lib.rs:774) — the semantic guard's self-removal blindness.
The shipped checkpoints.yaml comments themselves (lines 74/179): "checkpoint cannot fire, and no other checkpoint watches the registry."
Net effect: a single commit that deletes the guarding checkpoints (repo-local registry, or the no-base path) fires nothing. PR #8 should not be read as "the registry protects itself" without this caveat.
Ask
Give the self-protection an out-of-band anchor the on-disk registry cannot delete. Options to weigh in an ADR:
A compiled-in minimum checkpoint set (a floor detect() always applies, independent of the on-disk registry) so gate-self-mod/checkpoint-removed can't be removed by editing the file.
A registry-integrity check anchored outside the registry (e.g. a signed/known-good baseline diff).
Acceptance
A single commit deleting gate-self-mod + checkpoint-removed (+ adding a dangerous op) produces at least one fire on the native commit-msg git-hook path — not just at the engine layer. RED test drives the real hook invocation, not detect() directly.
Relates to #4 (no-base leg) and #7/PR #8 (the self-protection this residualizes).
Context
Follow-up surfaced reviewing PR #8 (closes #7). The default registry now ships
gate-self-mod(path) +checkpoint-removed(semantic) +destructive-ops, which is a real improvement. But the self-protection is self-referential: the thing that guards the registry lives in the registry, so removing it removes its own guard in the same act.The residual (two legs)
checkpoint-removedis inactive without a base registry — documented atcheckpoints.yaml:45/56, 125-126.residual_gap_adr0010_checkpoint_removed_itself_removed(src/lib.rs:774) — the semantic guard's self-removal blindness.checkpoints.yamlcomments themselves (lines 74/179): "checkpoint cannot fire, and no other checkpoint watches the registry."Net effect: a single commit that deletes the guarding checkpoints (repo-local registry, or the no-base path) fires nothing. PR #8 should not be read as "the registry protects itself" without this caveat.
Ask
Give the self-protection an out-of-band anchor the on-disk registry cannot delete. Options to weigh in an ADR:
detect()always applies, independent of the on-disk registry) sogate-self-mod/checkpoint-removedcan't be removed by editing the file.Acceptance
A single commit deleting
gate-self-mod+checkpoint-removed(+ adding a dangerous op) produces at least one fire on the native commit-msg git-hook path — not just at the engine layer. RED test drives the real hook invocation, notdetect()directly.Relates to #4 (no-base leg) and #7/PR #8 (the self-protection this residualizes).