Classify every H-NN invariant as blocking or reminder tier, and document the guarantee difference

[SUaDtL]

Summary

The hook inventory mixes two mechanisms with very different guarantee strength: hooks that BLOCK (exit 2, the action never executes) and hooks that REMIND (inject governance text at the moment of action, e.g. the H-12 ADR-conformance reminders on writes). Audit the full H-NN inventory, assign every invariant an explicit tier, promote any must-hold invariant currently served by a reminder, and document the two tiers so users know which guarantees are hard.

Evidence

• A blocking hook is a true gate: deterministic, model-independent, complete mediation at the tool-call boundary.
• A reminder hook is meaningfully better than a rule stated once at session start: it re-enters the instruction in the highest-attention region of context at the moment of action (position-bias literature: Lost in the Middle, https://arxiv.org/abs/2307.03172). But compliance with the reminder remains probabilistic, and instruction-following measurably decays with rule count and session length (IFScale, https://arxiv.org/abs/2507.11538: ~68% at 500 instructions; multi-turn degradation ~39%, https://arxiv.org/abs/2505.06120).
• Conclusion from the 2026-08-03 context-architecture research review (dossier in the arbiterforge-site repo, .codearbiter/research/2026-08-03-dossier-4-context-architecture.md): reminder hooks are the correct shape for context-loading discipline; they are not equivalent to gates, and the inventory should say which is which on purpose rather than by accident of implementation history.

Proposed work

1. Audit: table of every H-NN guard across all hooks (pre-bash, pre-edit, pre-read, post-write-edit, git-enforce): invariant, current mechanism (block / remind / warn), and the consequence if the model ignores it.
2. Classify: for each row, decide the intended tier. Rule of thumb: if violating the invariant must be impossible, it blocks; if the invariant is "load/consider the right context before acting," it reminds. Anything protecting the audit trail, the default branch, secrets, or gate integrity is presumptively blocking.
3. Promote: convert any must-hold invariant currently implemented as a reminder to a block (or to a block-until-acknowledged pattern where a hard block is too coarse). Each promotion gets its own review since blocks have false-positive cost.
4. Document: a two-tier guarantee table in the docs (and the README's enforcement section): "these are enforced; these are reinforced." This also keeps marketing language honest, which the 2026-08-03 adversarial review flagged: "hard refusals" must map exactly to the blocking tier.
5. Regression fixtures: each blocking-tier invariant gets a seeded-violation test proving exit 2 + no execution (extending the existing hook-guard test pattern).

Acceptance criteria

• Complete H-NN audit table committed
• Tier assigned per invariant, decision label captured for any contested rows (ADR if warranted)
• Promotions implemented with per-promotion review and fixtures
• Two-tier guarantee documentation published; enforcement claims in README/site cross-checked against the blocking tier

Origin

2026-08-03 research sweep for the arbiterforge.com "Why hard gates" essay; sibling of #591 (STE-inspired normative authoring) and #592 (INDEX-drift CI invariant).