checkpoint-removed guard silently disabled when no base registry is available

[lyubomir-bozhinov]

Severity: Medium (the guard protecting the registry is conditional)

Problem

The checkpoint-removed semantic guard — which detects a commit that removes a checkpoint from the registry — only works under two conditions (detect, SemanticKind::CheckpointRemoved):

1. base_checkpoint_names is Some(...) — if the caller cannot/does not supply the base registry (no base ref, shallow clone, first commit), it returns vec![] and the guard is silently off.
2. A changed file path ends with checkpoints.yaml — removal achieved by other means (changing which registry file is included, or editing the global baseline outside the repo) is not detected.

Why it matters

This is the gate that protects the gate. A silent no-op when the base is unavailable means an author (or an automated flow without a base ref) can strip checkpoints undetected — the highest-leverage bypass, since removing a checkpoint disables all its future firing.

Proposed fix

When the base registry cannot be resolved, fail loud (surface a warning / distinct exit signal) rather than silently disabling the guard; broaden detection to any registry mutation path, not just files literally ending in checkpoints.yaml.

Acceptance criteria

• Inability to resolve the base registry is surfaced, not silently treated as "nothing removed".
• Removing a checkpoint is detected across the supported registry-inclusion mechanisms.

[lyubomir-bozhinov]

Audit sharpening (2026-07-21). Broader than the checkpoint-removed guard: the default registry ships no self-protection at all — no path guard on the registry files, CheckpointRemoved dormant — so an agent can delete the destructive-ops checkpoint AND add rm -rf in the same commit with nothing firing. Plus HITL-ACK is self-authorable (the gated agent writes the commit message that lifts the gate; empty reason accepted) while the README implies human sign-off, and the gate subcommand swallows registry parse errors into a clean pass. Ship the self-guard checkpoints (code already supports them) + a threat-model note that HITL-ACK is honesty-based.

[lyubomir-bozhinov]

Re-scope after the anchor landed (PR #8) — the headline is no longer true; a narrower residual is.

This issue's severity rested on "a silent no-op when the base is unavailable means an author can strip checkpoints undetected." That specific bypass is now closed:

anchor-gate-integrity is compiled into the binary and merged by compile() into every registry — including an empty one and the no-registry case. It is path-mode, so it needs no base registry to fire, and it watches both registry paths plus the commit-msg hook and install-hook.sh. A commit that strips checkpoints with no base ref, on a shallow clone, or on a first commit now fires. Condition 2 ("only files literally ending checkpoints.yaml") is also partly addressed — the anchor's paths cover .commitward/checkpoints.yaml and the hook installation surface.

What genuinely remains (and is worth keeping this open for, at reduced severity):

• The semantic checkpoint_removed guard still returns vec![] without base_checkpoint_names. The anchor covers the act of touching the registry, not which checkpoint was removed. So you get a fire, but not the specific "this checkpoint was deleted" signal — a coarser telemetry, not a bypass.
• Removal via changing which registry file is included, or editing a baseline outside the repo, is still not detected semantically.

Suggested: retitle toward "checkpoint_removed semantics require a base registry — coarse anchor fire is the only signal without one" and drop severity from Medium. The gate-protecting-the-gate concern that justified Medium is handled by the anchor.

Refs #9 (closed by PR #8), PR #8.