inspect

Inspect — Discovery-Led Depth

Inspect is not a mode. It is a set of checks that fire in response to a specific discovery. The discovery-led principle: active discovery pulls depth in, not the other way around — depth is not a dial you turn up before knowing what you are looking at.

When a System 1 signal (see Triggers below) surfaces, inspect pulls System 2 checks scoped to that specific signal. One discovery → depth on that discovery → checks resolve → back to default operation. No "inspect on / inspect off" state.

Manual invocation (/inspect) is still available when the user wants to force a depth pass without waiting for an auto-detected trigger — but even then, it runs once for the current change and exits.

---

What inspect does when triggered

Scope of a single depth pass

Default operation	Depth pass fires
Changed files only	Changed files + direct dependents
Tests pass?	Tests pass + are tests covering the right cases?
Does it work?	Does it work + what could it break?

The depth scope is bounded by the trigger. A "shared utility edit" trigger pulls depth into its dependents; it does not turn on "inspect mode" for the rest of the session.

Additional checks (on top of guard)

Four check types. A depth pass does not run all four by default — which check fires is determined by the trigger. Running all four regardless of trigger would violate the discovery-led principle (depth chosen without a specific discovery).

1. Dependency trace: For each modified function/module, list callers and downstream consumers. Flag any that might behave differently.
2. Side effect scan: State changes (DB writes, file writes, env mutations, global state) — are they intended? Are they reversible?
3. Assumption audit: What does this code assume about its inputs, environment, or execution order? Are those assumptions documented or tested?
4. Rollback viability: If this change goes wrong in production, how do you undo it? Is there a migration, a flag, a revert path?