Guardrail negative-control proof

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A boundary rule forbids tests importing lib/impl and permits public entry points. Configuration presence does not prove lint:boundaries loads it; use allowed→violation→restored controls.

Mechanism

In an isolated copy, record command/version and observe clean success. Add a temporary explicit forbidden import, run the same command and require failure from the named rule rather than an unrelated error. Remove only that change, rerun success and verify initial files. Investigate wiring if expectations fail without weakening the rule.

Bad example

A saved config proves protection, or any syntax-error failure from a violation counts.

Good example

Run lint:boundaries on a legal entry-point example. Add a syntactically valid forbidden deep import and require the boundary diagnostic. Remove the teaching mutation and observe success again, retaining all results without touching unrelated changes.

Why the change matters

Negative controls establish actual rejection and restoration excludes a permanently broken environment. Named diagnostics distinguish protection from unrelated failure.

Observable expectation

Teaching sequence is pass, named-rule fail, pass. Second-step success leaves protection unproved; module-not-found needs a corrected fixture, not acceptance. Residual mutation prevents completion. Unrun sequences are plans only.

Limits

One counterexample does not prove complete bypass resistance; aliases/generation/configuration may need more checks. Isolate and restore precisely instead of destructive Git cleanup. Policy suitability remains project-owned.