The dirty-tree guard.

What the check reads

The check runs git status --porcelain at the repo root and parses every line. Tracked files that are modified, staged, renamed or deleted are counted and listed, up to twenty of them. Files git is not tracking yet are collected separately. A clean tree passes. Tracked changes fail the run. A tree with only untracked files produces a warning instead, because those are usually scratch files, and the record lists them so you can confirm they should not ship.

Why AI-built code ships this

AI sessions leave edits behind: a half-finished refactor, another session's uncommitted work, a debug flag flipped to see something locally. A CLI production deploy takes the working tree as it stands, so all of that goes live with your change, and nobody decided to ship it. This is the single most common way an AI-built repo ships something unintended.

Why it blocks

Blocks. If any tracked file is modified or staged, the verdict is NO-GO until the tree is clean: commit, stash or revert first, then deploy from a clean tree of the intended state. Untracked files alone warn rather than block, since a file git never tracked cannot change code that already ships, but the run still names each one for a human to confirm.

In the proof record

One line with the real state of the tree at that moment: clean, or the exact count of tracked files that were modified or staged, followed by the file list.

✓ Dirty-tree guard — Working tree is clean — nothing unintended would ship.
✗ Dirty-tree guard — 2 tracked file(s) modified/staged — a 'vercel --prod' would ship this unintended work.

Honest limits

It reads git's view of the tree and nothing else: a file your .gitignore already hides never appears here, and work in a different clone or worktree is out of sight. It also cannot tell an intended hotfix from an accident. The check reports the state of the tree; a person decides what belongs in the ship.