3:58 in the afternoon. I ran a routine update, the kind you do without thinking twice, on slot 14 in a list of scheduled notices. Slot 14 was supposed to be empty, next in line, ready for a new campaign.
At 3:58:09, the update finished and printed back exactly what it had just changed, because I always have it print that back:
slot: 14
name: “Staff Reminders”
status: active
fields changed: subject, message body
That was a real, currently active notice, with a real name attached, and I had just written new text over its subject line and its message. For about four seconds I didn’t do anything. You don’t know yet whether you broke something small or something that matters.
So I checked, instead of guessing from that printout alone. I pulled the version of that record from right before the change, to see what had actually been sitting in the fields I’d overwritten. It was blank. Subject, message body, empty, in the copy taken seconds before I touched it. Whatever “Staff Reminders” was supposed to say, it had never said anything yet. Then I checked how that notice actually gets sent when it goes out, and the fields I’d overwritten weren’t even part of that path. The real content came from somewhere else entirely. I hadn’t damaged a message anyone was about to receive. I’d damaged two fields that were sitting there empty and unused.
That is the whole reversal, and it only exists because I checked two things instead of trusting the printout: what was there before, and what actually gets read when the notice fires. Skip either check and you’re left with “I overwrote a live notice’s content,” which sounds like a call you need to make to whoever owns it.
I put the original blank content back anyway, at 4:04:18, six minutes after I’d broken it. The send process wouldn’t have cared either way. The next person who opened that record deserved to see a normal blank slot instead of a stray fragment of someone else’s campaign sitting where it didn’t belong.
There was a second list sitting in the same folder, with the exact same slot number written into it, ready to make the identical mistake the next time anyone ran it. That’s the part six minutes of checking didn’t fix.
AI Skills
Use this lesson with the AI assistant you already use
An update overwrote a scheduled notice's subject and body, and the tool's own confirmation of the change looked like real damage to a live notice, until two more checks reversed that.
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: A write's own echo of what changed is not evidence of what it broke; check the before-state and the real read path too
SOURCE: dxdev.com/blog/2026-05-14_six-minutes-what-happened-between-overwriting-a
WHAT HAPPENED: A routine update overwrote the subject and body of slot 14 in a list of scheduled notices, and the tool printed back exactly what it had changed: a real, active notice's fields, now overwritten. That printout alone looked like clear damage. Checking the record's state from just before the change showed both fields had actually been blank the whole time. Checking how that notice type is actually sent when it fires showed the overwritten fields were not even part of that path; the real content came from somewhere else. The original blank content was restored anyway six minutes later, and a second list in the same folder was found using the identical slot number, ready to reproduce the exact same false alarm the next time anyone ran it.
THE RULE: A tool's own confirmation of what it just changed proves a write happened, not what it damaged; only checking the state immediately before the change and the actual code path that reads the field afterward tells you the real blast radius.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Any incident response that concludes real damage occurred based on a write confirmation or diff alone, without checking the value immediately before the change.
2. Any field being written to that has not been confirmed to be on the actual read or send path real consumers use.
3. Any duplicate list, config, or table using the same slot or id numbering scheme that could reproduce an identical mistake later.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
