At 3:58 in the afternoon we ran a routine update 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. We 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, and we had just written new text over its subject line and its message. For about four seconds we didn’t do anything. You don’t know yet whether you broke something small or something that matters.
Two checks before deciding anything
We pulled the version of that record from right before the change, to see what had been sitting in the fields we’d overwritten. It was blank. Subject and message body were both empty in the copy taken seconds before we touched them. Whatever “Staff Reminders” was supposed to say, it had never said anything yet.
Then we checked how that notice actually gets sent when it goes out. The fields we’d overwritten weren’t even part of that path. The real content came from somewhere else entirely. We hadn’t damaged a message anyone was about to receive. We’d damaged two fields that were sitting there empty and unused.
That reversal only exists because we checked two things: what was there before, and what actually gets read when the notice fires. Skip either one and you’re left with “we overwrote a live notice’s content,” which sounds like a call you need to make to whoever owns it.
Putting it back anyway
We restored the original blank content at 4:04:18, six minutes after we’d broken it. The send process wouldn’t have cared either way. But 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.
The part six minutes didn’t fix
There was a second list in the same folder with the exact same slot number written into it. It was ready to make the identical mistake the next time anyone ran it.
If you change a record by slot number instead of by name, check what was in it before the change and what the send process actually reads. Then look for other copies of the list that carry the same number.
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/everyday-ai/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.
