Mechanics to checks, judgment to review

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

Use case

Tests repeatedly deep-import implementation code while prompts keep saying use entry points. This mechanical shape belongs in checks; if an existing checker is unwired, repair wiring. Cross-module judgment still belongs in review.

Mechanism

Read scripts, checkers and CI for existing support/execution. Encode fixed syntax/path/API policies in the cheapest suitable existing tool with allowed/forbidden/generated scope. Verify good/bad controls and wire applicable workflows. Reserve business/cross-file trade-offs for review rather than duplicate tools or encode every judgment.

Bad example

Repeat no-deep-import in global prompts while ignoring unwired checks, or claim a regex solves all architecture.

Good example

Reuse the project import checker, repair its missing CI invocation and encode public-entry imports for tests. Prove legal imports pass and deep imports trigger a named failure. Keep responsibilities/interface trade-offs in review and report scoped coverage.

Why the change matters

Deterministic checks repeatedly catch mechanical faults without long-instruction recall. Contextual design questions need judgment; separation assigns automation decidable work.

Observable expectation

Teaching CI visibly runs the boundary command, rejecting a deep import and accepting entry imports. Alias gaps remain scoped limits; an equivalent existing rule needs no duplicate tool.

Limits

Syntax cannot decide every semantic/design question and rules can misflag. Match the stack/workflow and authorized scope for enforcement changes. Prose can explain rationale but is not proof of execution.