Five Bugs Deep: The Auto-Organiser That Had Never Once Executed

I got a screenshot with one line under it: tickets keep skipping the current sprint. Also the developer field is empty. Also, if there’s code involved, the fix version isn’t there either. Not once. Not a fluke. Every time.

That’s the kind of report that used to send me spelunking through the ticket tracker’s UI trying to remember which screen has which field. This time I had an agent go look at the actual close tooling instead, the script that’s supposed to set all three of those fields automatically when a ticket gets closed.

The code that claimed to already handle this

The close path runs through item_close.py, a large script that walks a ticket through the screen-bearing close transition that accepts Story Points, Sprint, and Fix Versions in the same POST. Right there in the comments, in plain language, it says the values are auto-stamped from the next-upcoming release and the active sprint “when missing, so they no longer cause halts.”

Read that again. The code isn’t ambiguous about what it’s supposed to do. Someone, at some point, sat down and wrote logic to solve exactly the problem I was staring at. Parse the sprint field, which keeps the full history of every sprint a ticket ever rolled through. Skip the closed ones. Find the one still marked active. Stamp it. Same idea for fix version. This was designed, written, and merged.

And it had never once fired. Not on a real ticket, not for me, not for anyone.

Working backward from “never”

That’s the part that stuck. This wasn’t a script with an edge case. It was a script that appeared to work in whatever fixture or dry run it got demoed against, and then simply never ran again after that, because nothing downstream of “merged” was watching whether it actually executed on real tickets.

Once the agent started tracing the actual call path instead of the comments describing it, the picture got worse. The auto-stamp logic sat behind a chain of preconditions. Get the transition list. Confirm the close transition is available from the ticket’s current status. Confirm story points are already set, because the code treats that as a hard requirement and dies if it’s missing. Only after all of that does it even reach the block that resolves sprint and fix version.

Five separate points in that chain could silently take the whole thing down, and they stacked. The first was the dumbest one: an import at the top of the file that crashed the CLI before a single line of the close logic ran. Not a logic bug. Not a wrong field ID. The script never got past its own header. Everything downstream of that, the sprint parsing, the active-sprint preference, the fix version resolution, the story points check, was correct code that had simply never been executed, because execution never got that far.

Shipped and demoed are not the same as running

That’s the whole story. Nobody wrote sloppy code here. The sprint-resolution logic, when I finally got to read it in isolation, was careful. It knew the difference between a ticket’s full sprint history and its current active sprint. It knew fix version and sprint needed to be resolved at plan-preview time but written only through the transition itself, so a dry run stayed read-only. Somebody thought hard about this.

What nobody built was a way to know the difference between “this logic exists in the file” and “this logic ran on recent closes.” The demo passed. The fixture passed. Then it shipped, and from that point forward the only signal anyone had that it was working was the absence of complaints, which is not a signal, it’s silence.

I keep three fields I care about, sprint, developer, fix version, and I found out about all three being broken from the same screenshot, on the same day, because I happened to be looking. If I hadn’t looked, the auto-stamp logic would still be sitting in that file today, technically present, technically correct past its first line, and still doing nothing.

What I’m changing

The fix for the import was five minutes. The fix for my process is the part I actually care about. A feature that closes tickets and touches ticket fields needs a live check, not just a merged PR and a demo screenshot. Something that confirms, on an actual close, that the fields it claims to stamp got stamped. Shipped was never the bar. Running was.

dxdev LESSON · paste into your AI coding agent
LESSON: Code demoed once and merged is not the same as code that has ever run on a real case afterward
SOURCE: dxdev.com/blog/2026-08-14_the-automation-that-never-ran
WHAT HAPPENED: An auto-stamp feature meant to set three ticket fields automatically on close had careful logic sitting in the codebase, with comments explicitly describing exactly what it was designed to do, and it had never once fired on a real ticket since being merged. Tracing the actual call path, rather than the comments describing it, found five stacked preconditions any one of which could silently kill the whole chain. The first was the simplest possible failure: a bare import at the top of the file that crashed the command before a single line of the close logic ran, meaning the well-designed downstream logic, which correctly distinguished a ticket's full sprint history from its currently active sprint, had simply never been executed at all, because execution never got that far. The bug surfaced only because a screenshot happened to be reviewed that day.
THE RULE: A feature passing its demo and getting merged proves it worked in that one fixture; it does not prove it has ever run successfully against a real case afterward, and the absence of complaints is not a signal, it is silence. Anything that touches production data on a schedule or a trigger needs a live check confirming a recent, actual execution, not just a green demo from the past.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any feature whose only evidence of working is a demo or fixture test run at merge time, with no ongoing check confirming it is still executing successfully against real, current data.
      2. Any function or script with a chain of preconditions where an early failure, such as an import or a guard clause, could silently prevent well-designed downstream logic from ever running, with nothing surfacing that the downstream code never executed.
      3. A bug report treated as one problem when tracing the actual execution path, rather than the code's own comments about what it does, might reveal several independent points of failure stacked in sequence.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.