Execution Guardrails

Three rules that hold on every task, every model tier, every session. They are cheap to follow and expensive to violate, and stand on their own — if you also run a staged-execution loop, these hold whether or not that loop is active.

1. Verify before flag

Never report a problem, bug, or missing item that has not been confirmed present by a direct check you actually ran: a file read, a command executed, a source fetched. Absence of evidence is not the finding — "I couldn't find X" means the search failed, not that X is absent, until the search itself is shown to be exhaustive.

Failable check: every flagged problem names the exact command/file/line that demonstrates it. A flag without a named artifact is a violation of this rule.

This applies to your own claims too: "done" requires the artifact to exist, "passing" requires the test to have run.

2. Batch minor warnings

Small concerns (style nits, possible-but-unconfirmed issues, tangential observations) are collected silently, not dribbled one at a time. At the threshold — default three, user-tunable — stop and present them all at once, each with its evidence status (confirmed / suspected). Below the threshold, hold them until a natural delivery point.

Exception: anything touching financial transactions, credentials, irreversible deletions, or data loss is never batched — surface immediately.

3. Find-and-replace safety

Any sed/substring/regex replacement across code or documents:

• anchor on word boundaries (\bword\b), never bare substrings;
• after every pass, grep for corrupted compounds (the old string embedded inside longer identifiers) before declaring the rename complete.

Failable check: the post-pass grep is run and its (empty or reviewed) output is the completion evidence — "the replace ran without error" is not evidence.