Read-Only Boundary

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

Use case

A user requests read-only review of whitespace-email handling in validator.py. Reading code/callers is authorized, not incidental fixes, staging or remote comments.

Mechanism

Establish permitted reads/prohibited effects and actual tool permissions. Inspect validator/callers with static tracing or isolated nonmutating checks. Commands writing caches or external state need read-only alternatives. Report locations/triggers/proposed patches and check relevant tree/index/refs/actions afterward; prose alone does not enforce restrictions.

Bad example

Review then edit, stage and post comments without distinguishing diagnosis from repair.

Good example

Read validator.py and relevant entries only, reporting whitespace behavior/evidence/suggestions without changing targets/index/refs/remotes. Inspect command effects/tool limits; unsafe runtime paths remain static inference. Apply repairs only in an actually authorized task.

Why the change matters

Scope prevents review becoming implementation and makes suggestions assessable. Tool constraints/state checks provide concrete evidence beyond read-only wording.

Observable expectation

Teaching target files/Git state remain unchanged with no edit/stage/send calls. Patch text is explicitly unapplied. Without remote verification, claim only no issued writes rather than global unchanged state.

Limits

Prompts do not enforce permission; shell/network/test setup may mutate. Reads remain scoped, and absolute no-state-change claims need bounded evidence amid concurrent processes.