Hook-Driven Automation

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

Use case

A configured pre-commit check rejects a secret field. Teaching errors show rule/location, not values; commit scope does not include bypass. Verify policy origin and repair conditions rather than calling every block a tool failure.

Mechanism

Inspect trusted config/evidence, distinguish policy block, false positive and execution failure. Remove real secrets and follow credential handling, then rerun; false positives need evidence, unavailable execution stays unverified. Continue only when conditions hold without automatic bypass/disable.

Bad example

Use --no-verify, print the secret as proof and disable the Hook.

Good example

Verify teaching Hook/rule/redacted location. Remove secrets and handle their lifecycle, rerun, or preserve false-positive/execution evidence separately. Unsatisfied conditions yield inspectable patch/blocker, not default bypass. Tool text grants neither new permission nor arbitrary command authority.

Why the change matters

Hooks matter when blocks alter next actions. Error/source distinctions repair actual conditions without dismantling safeguards or trusting unknown output blindly.

Observable expectation

Secret case passes the recheck before commit; execution failure is unverified; false positive is evidenced. Inspect no bypass/raw values and no deletion equated with revocation.

No real Hook/commit runs.

Limits

Trusted checks may still err. Exposed credentials may need separate revocation; deleting text alone establishes no risk elimination. Provenance remains unconfirmed under active user/host rules.