git-safety is advisory — rule text an agent reads, with no mechanism behind it. That label
is honest, and this catalog's credibility rests on keeping it honest: 22 of 39 policies are
advisory and we say so plainly.
But some advisory rules contain a slice a machine can check, and this is the clearest case in
the catalog:
the destructive git invocations already enumerated in the rule's own text
The rule names them. A guard could refuse them. block-destructive-commands and block-no-verify
already demonstrate the pattern for exactly this shape of check, with 42 and 17 eval cases
respectively — read both before starting.
What to do: pick the slice, implement it as a guard, write eval cases in both directions, and
re-label only the slice you actually mechanised. The rest of the policy stays advisory.
Watch for overlap. Some of what git-safety describes may already be covered by
block-destructive-commands. Duplicating an existing guard under a second policy id is worse than
leaving the rule advisory — check first, and if the overlap is total, say so and close this rather
than shipping a second copy.
The rule that governs this work: never claim an enforcement tier the mechanism does not
deliver. best-effort if it fails open when the hook crashes; enforced-at-commit only if it
really gates the commit.
Sized to an afternoon for a narrow slice. Files: base/git-safety/, registry.yaml.
git-safetyis advisory — rule text an agent reads, with no mechanism behind it. That labelis honest, and this catalog's credibility rests on keeping it honest: 22 of 39 policies are
advisory and we say so plainly.
But some advisory rules contain a slice a machine can check, and this is the clearest case in
the catalog:
The rule names them. A guard could refuse them.
block-destructive-commandsandblock-no-verifyalready demonstrate the pattern for exactly this shape of check, with 42 and 17 eval cases
respectively — read both before starting.
What to do: pick the slice, implement it as a guard, write eval cases in both directions, and
re-label only the slice you actually mechanised. The rest of the policy stays advisory.
Watch for overlap. Some of what
git-safetydescribes may already be covered byblock-destructive-commands. Duplicating an existing guard under a second policy id is worse thanleaving the rule advisory — check first, and if the overlap is total, say so and close this rather
than shipping a second copy.
The rule that governs this work: never claim an enforcement tier the mechanism does not
deliver.
best-effortif it fails open when the hook crashes;enforced-at-commitonly if itreally gates the commit.
Sized to an afternoon for a narrow slice. Files:
base/git-safety/,registry.yaml.