The question on the ticket was whether a false alarm was real: our gap checker flagged a deliberate Story Points value of 0.1 as missing. The fix was already in, so the agent changed no code and made no commit.
The false alarm
The old check flagged any value under 1, so the deliberate 0.1 default our tooling sets read as missing. One item on a larger ticket asked whether that false positive was real, and it turned out to be already fixed. I handed the question to an AI agent.
What was already on main
A commit on origin/main had changed the gap-check script to flag only a blank or zero value, written in the code as pts <= 0. So 0.1 passes and zero still gets flagged.
The agent checked that against the live ticket as well as the code. The ticket holds customfield_10022 = 0.1. A read-only scan of the last 30 days found no gaps at all, so there were no Story Points gaps and that ticket was not in the gap list.
The tests agreed. The false-positive test file passes, 13 tests, and it already has the 0.1 regression case and a case where zero stays flagged. The agent added nothing, so there was no fails-before/passes-after run and no gate.
What the agent left alone
The state file for the close-gaps run still holds an old dedupe signature for that ticket’s Story Points, last stamped 2026-09-23. It is stale history rather than an open gap row. The agent did not edit it, because whether to clear it is the manager’s call, and it found no supported command for that.
It also did not run close-gaps scan, because without --no-notify that command can notify and touch state. Instead it used two read-only scripts: one fetches the raw field from the ticket, and one calls the gap finder over the last 30 days and reads the state file.
It posted its verdict as a comment on the larger ticket and did not transition or close it. Item 4 was the last open item on that ticket.
Where it ended
The check flags only a blank or zero value, pts <= 0, and the ticket holds 0.1 in customfield_10022 and sits in no gap list. The only trace of the false alarm left is a stale dedupe signature stamped 2026-09-23 in the state file, and clearing it is the manager’s call.
AI Skills
Use this lesson with the AI assistant you already use
A ticket asked whether the gap checker wrongly flagged a deliberate Story Points value of 0.1 as missing. An agent checked the code, the live ticket and the tests, and found a fix was already on main, so it changed nothing.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: Check Whether The Bug Still Exists On Main Before Writing Any Fix
SOURCE: dxdev.com/blog/check-whether-the-bug-still-exists-first
WHAT HAPPENED: The old gap check flagged any Story Points value under 1, so the deliberate 0.1 default read as missing. A commit on origin/main had already changed the check to flag only a blank or zero value, written as `pts <= 0`. The agent confirmed this against the live ticket, which holds `customfield_10022` = 0.1, and a read-only 30 day scan that found no gaps. The false-positive test file already passed with 13 tests, including a 0.1 regression case and a case where zero stays flagged. The agent therefore wrote no code and made no commit. It also left a stale dedupe signature in the state file alone, avoided a scan command that could notify or touch state, and posted its verdict as a comment on the larger ticket.
THE RULE: Before fixing a reported bug, verify against current code, live data and existing tests whether it still exists, because the fix may already have shipped. When it has, report the evidence and leave state you do not own untouched.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Before any bug fix starts, a step reproduces the reported behavior against the current main branch and live data, and records the result.
2. A regression test for the reported case already exists or is added, and it is run to confirm the expected pass or fail before deciding whether code needs to change.
3. Verification of a reported issue uses read-only commands, and any command that could notify or modify state is avoided or run with its no-notify option.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
