An agent told me our venture’s Discord channel was unreachable, and it had not checked the code to say so.
The session had been running overnight, 8h 55m by the time it closed at 8:41 AM. The report was wrong.
What the agent read
The agent read the header on the secrets file for that Discord token. The header still described the file as a placeholder for a personal bot, created on July 19, waiting for someone to paste in a token. From that wording it concluded the venture’s bot was unavailable, and told me it could not post to #ops.
The file had been repurposed since then. It held the venture’s bot token, and that token had been posting to #ops daily since July 6. The header was a snapshot of an earlier week.
The fix
The fix had three parts:
One sanctioned way to post. The channel table, the token lookup and the request code now live in a single module, and a command-line front door sits on top of it. The daily, weekly and monthly review jobs call the same module, so the copy of the request code that one of them carried is gone.
A command that verifies the token against the live service, so the answer to “is the bot available?” is a response and not an inference.
A rewritten header. It now says what the token actually is, that the filename is historical, which code consumes it, and to stop reading there if you need the venture’s Discord.
I also wrote one gotcha into that header. Discord sits behind Cloudflare, which rejects requests with no User-Agent header with a 403 and error code 1010. That is an edge block, not an authentication failure, and it is exactly the kind of thing that looks like “unreachable” from a distance.
Asking for the line
When an agent says an integration is broken, the useful question is which file and line it based that on. A comment, a README or a config header is documentation about the system, and a stale one keeps asserting without failing. The answer worth accepting is code or a live response.
The header on that file now says what the token is for, and the verify command is documented in it.
AI Skills
Use this lesson with the AI assistant you already use
During an 8h 55m overnight session, an agent told its owner the team Discord channel was unreachable without checking the code. The cause was a stale header on the secrets file, and the same token had been posting to that channel daily.
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: Verify Live Paths Before Diagnosing A Dependency Outage
SOURCE: dxdev.com/blog/2026-07-25_stale-config-misdiagnosis
WHAT HAPPENED: An agent read a secrets-file header that still described the Discord token as a placeholder for a personal bot, concluded the venture's bot was unavailable, and told its owner the channel was unreachable. It never checked the code. The token had been posting to that channel daily for weeks. The fix was a single sanctioned posting path, a command to verify the token, and a rewritten header that says what the token is for and who uses it.
THE RULE: Before acting on a report that a dependency is down, require the code path or a live response that supports the claim. Treat comments, READMEs, and config headers as unverified documentation that can contradict the system they describe.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. For every claimed integration outage, record the file and line in executable code or the live response that proves the claim.
2. Verify that each secret's header or README entry matches how the secret is actually used today.
3. Provide one command that verifies a token against the live service, so nobody has to infer its state from a comment.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.