---
title: "When Your Own Guardrail Lies to You"
canonical: https://dxdev.com/blog/2026-07-13_automated-guard-false-positive-bare-filename/
datePublished: 2026-07-13
---
On June 27, a close guard rejected a legitimate item because it had found the wrong bundle.

I filed the problem during a 5-hour, 58-minute build session. The guard was supposed to do one useful thing before an automated close: stop the close if the artifact bundle was stale. Instead, it reported a match for a bundle that was not the bundle attached to the item being closed.

The first read looked like a normal safety intervention. A guard had found a stale artifact, so it stopped an irreversible state change. That is exactly what it was there to do. But the item had a current bundle, and the result did not line up with the files in front of me. The alert was specific enough to be believable and wrong enough to matter.

## The comparison that threw away the identity

The guard did not compare bundle paths. It compared bare filenames.

That distinction is small in code and absolute in a filesystem. Two artifacts can share a filename while belonging to different work paths. Once the guard discarded the directory, it no longer knew which artifact it had found. It only knew that a file with the same label existed somewhere in the candidate set.

The failure reduced to this shape:

```text
expected_key = filename(expected_bundle_path)
candidate_key = filename(candidate_bundle_path)

if expected_key == candidate_key:
    block_close_as_stale()
```

That is a valid comparison only if a filename is globally unique. Ours was not. The close could be blocked by a same-named bundle from another path even though the intended bundle was current and complete.

I followed the result backward rather than treating the guard as an authority. First I checked the bundle the item actually referenced. Then I checked the candidate that had satisfied the guard. The paths were different. The collision appeared only after both paths had been flattened to the last path segment.

Nothing was stale. The guard had converted a path identity problem into a filename equality problem.

## Why the obvious fixes lost

Removing the guard would have made the immediate false positive disappear. It would also have reopened the original failure mode: an automated close could proceed with a stale artifact bundle. That was not a fix.

Keeping the filename check and adding a timestamp check was not enough either. Timestamps can help answer whether an artifact is old. They cannot answer whether the artifact belongs to this item. A fresh bundle in the wrong directory is still the wrong bundle.

The durable key is the path, with whatever normalization the artifact store requires before comparison. The corrected shape is deliberately boring:

```text
expected_key = canonical_path(expected_bundle_path)
candidate_key = canonical_path(candidate_bundle_path)

if expected_key == candidate_key:
    evaluate_staleness()
```

The ordering matters. Identity comes first. Staleness is a property of the identified artifact, not a substitute for identifying it.

We shipped the path-aware bundle guard correction on July 13 alongside related guard work and verified it live. The code change was short. The test that matters is not: does the guard find a file with this name? It is: can two bundles with the same filename in different paths coexist without one blocking the other item's close?

## A guard is still a decision system

This class of bug does not announce itself with a crash. The automated close simply does not happen, and the guard provides a plausible explanation. That makes false positives dangerous. They accumulate as manual retries, exceptions, and distrust in the automation that was meant to remove that work.

I want a guard that blocks a transition to be easy to interrogate. It should show the full identity it compared, not a shortened label that merely looks distinctive. If a guard cannot tell me which exact artifact made it stop the workflow, it has not earned the authority to stop it.

The failure was a bare filename. The lesson was not to trust a compact key with a full identity.