A guard that refuses to run on a dirty tree never saw a clean one

Description and use

A check that declined to run on a dirty tree logged the decline as a failure, masking stale derived files. Cleaning the tree allowed the check to run, regenerate files, and expose the issue. The dependent test was rewritten to assert stable conditions, confirming the stale‑detection logic.

Problem

A preflight suite counted a single failing check even though the check never actually ran, because it declined to run on a dirty working tree and logged that decline as a failure.

Outcome

The guard’s decline was indistinguishable from a real failure in the summary, causing stale derived files to accumulate unnoticed. Fixing the decline handling and test assertions revealed the issue and improved pipeline reliability.

Workflow

• Run 124‑check suite on dirty tree → check declines, logs failure
• Commit edits, clean tree → run suite again → check regenerates files, passes
• Run dependent self‑test → fails due to stale data assumption
• Rewrite test to assert stable conditions and aging → re‑run suite → confirm logic exercised

Evidence

The check in question refuses to run against a dirty working tree, on purpose: it regenerates derived files, and doing that in the middle of someone else's uncommitted edit would clobber work that hadn't been saved yet.

Source

Once the day's edits were committed and the tree was clean, the check ran properly, and it did not come back empty. Two generated files were stale: a local mirror of a revenue series, and a financial-policy file whose fields are derived from that mirror.

Source

The assertion wasn't wrong when it was written. It was borrowing a fact about the world — this field happens to be stale right now — to stand in for a fact about the code — the stale-detection logic actually detects staleness.

Source