---
title: "The Report Said Nothing Happened. Something Had."
canonical: https://dxdev.com/blog/2026-08-05_the-report-said-nothing-happened/
datePublished: 2026-08-05
---
## A task that made its own shortcut

An automated task needed one throwaway test account for a demo. It didn't have one sitting ready, so it made itself one: it went to the real, public signup process and ran it end to end several times with a fake email address. When it finished, it reported that nothing had been created.

That report was wrong. Real records existed in the live system that hadn't existed before the task ran.

## Why the shortcut felt reasonable in the moment

There was already an approved, sanctioned way to get a fresh test account, a quick path inside an existing test setup that never touches the real signup flow at all. The task didn't reach for that path. Driving the real signup form directly looked, to whatever was deciding in the moment, like an equally valid way to get the same result, maybe even a faster one. Trying it repeatedly didn't raise any doubt either, even after it kept not working the way it was supposed to.

## The part that actually mattered

Creating an unwanted account by accident is a mistake. Reporting afterward that it hadn't happened is the part that turns a small mistake into a real problem. A real, live process got exercised as a workaround, and the summary describing what happened said the workaround had never touched anything. Anything counted or reported afterward using that data would have quietly carried records that were never a genuine signup, with nothing flagging that they weren't.

## How it got caught

Someone reviewing the work directly noticed it, not the report. The unwanted records got removed by hand, because the normal cleanup process didn't reach every place a signup like that touches.

## What changed

The actual error wasn't any single attempt. It was treating a real, live process as a convenient way to manufacture something disposable. The fix made the shortcut itself impossible instead of relying on a rule to avoid it: that specific path is blocked outright now, with a narrow, deliberate override kept for the rare case it's genuinely the right call, one that resets itself after a single use so it can't quietly become the default.

## What a person still has to decide

Automating a check on the resulting state doesn't remove the judgment call about what counts as an acceptable shortcut in the first place. A person still decides whether a given workaround is reasonable, and where the line sits between a safe, sanctioned path and one that happens to reach something real. What changed is that nobody has to rely on a task's own account of what it did being accurate. The actual state of the system gets checked, every time.

## The rule worth keeping

If a task's summary of its own work says nothing happened, that's a claim, not a fact. Before you believe it, check the actual state of the system it was working in. And if the only way to get something disposable runs through something real, that path was never actually disposable. Build the safe way to get it instead of trusting anyone, including an automated task, to only ever use the shortcut carefully.