In August I wrote about the output gate, a fixed checklist that runs before the assistant produces anything that looks like a message from me. It handles words. Actions are a different problem, because a bad sentence can be retracted and a bad publish cannot. So there is a second gate, a mandatory preflight that runs before any high-stakes action, and it is the last of the gates in this track because it is the one that protects everything the others produce.
What Counts as High Stakes
The trigger has to be observable, or it will not fire. An action gets preflight if it is any of these:
| Property | Examples |
|---|---|
| Irreversible | Deleting, overwriting without a backup, force-pushing, sending |
| Outward-facing | Publishing to a site or wiki, posting a status, emailing a group, opening a pull request others will read |
| Cross-file | An edit that touches many files at once, a rename, a search and replace |
| Asserting a fact | Reporting a status, a number, a date, or a completion to someone who will act on it |
If none apply, preflight is skipped. That is deliberate. The list has to stay reserved for actions that earn it, because a checklist that runs on everything becomes noise and stops being run on anything.
The Checks
Eight lines, each pass or fail. The target is verified: I looked at the thing I am about to change in this session, not from memory. The state matches the description: if what I found differs from how it was described to me, I stop and report the difference instead of proceeding. A backup exists, or the change is under version control with a clean tree. The blast radius is named in one sentence: which files, which readers, which downstream job. Markers are preserved: if the target carries someone else's edits or inline comments, my change keeps them, and a publish that wipes a reviewer's notes is a failed publish. Every fact in what I am about to send traces to a source I opened, nothing inferred from a timestamp or a filename. A dry run happened where one exists: build before deploy, preview before publish, diff before commit. And the authorization is current: I was told to do this, for this target, in this context, because approval for an earlier action does not carry forward.
That second check is the one that has saved me most often. The description of a thing and the thing itself drift apart constantly. A gate that says "stop when they differ" converts a silent wrong action into a loud question.
The Second Half
Most checklists end when the action starts. Mine has two more lines. Verified live: I checked the result where it landed, the page loads, the row exists, the message is in the sent folder, not just that the command returned. And recorded: one line in the session log saying what changed, where, and how to reverse it. A command returning zero is not the same as the thing having happened, and this site has taught me that more than once.
Why a List and Not Judgment
Judgment is the right tool for deciding whether an action is high stakes. Once it is, judgment is the wrong tool for the checks themselves, because the moments that most need the checks are the moments you are most confident. The list does not get confident. That is the whole design, and it is the same design as every gate in this track: observable trigger, binary checks, run before the thing you cannot take back.
The trigger table, the eight checks, and the second half are in preflight.md. Adapt the items, keep the shape, and keep it short. A preflight that takes longer than the action gets skipped, and a skipped preflight is worse than none, because everyone believes it ran.
This is part of a track on agent tooling and spec-driven development that goes deeper than a field report, with something you can download and run in each one. Free for now while the track grows; the deepest installments become a paid tier later.