The staff plan page showed no payment history for a customer account that had a first payment. The staff preview of the plan page was hardcoded to show none.
A small fix on the page
Payments now load. Each payment opens to its period, the card used and the receipt. The summary card no longer dead-ends.
The deploy that had been blocked for two commits
The deploy was blocked for two commits. The billing rewrite had dropped a table, and the delete confirmation still counted rows in that table.
That same dropped table had also made deleting a business impossible in production. Everything is live and green.
I did not confirm the finished page by eye.
The receipt email on the same account
My partner’s complaint about that customer’s receipt email traced to a hard limit in the payment processor. One switch governs every PDF, so the invoice cannot be dropped without also losing the receipt. The processor will not attach a file of ours.
That leaves one route to what my partner asked for: send the email ourselves. I filed the finding and a build sketch as a draft unit under the billing task.
AI Skills
Use this lesson with the AI assistant you already use
A staff plan page showed no payment history for an account that had a first payment, because the preview was hardcoded to show none. Separately, a deploy was blocked for two commits because a billing rewrite dropped a table that the account delete confirmation still counted rows in.
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: Audit Every Reader of a Schema You Change and Every Hardcoded Empty State Before Real Data Arrives
SOURCE: dxdev.com/blog/2026-08-31_accounting-reconciler-finds-hidden-charges
WHAT HAPPENED: The staff preview of the plan page contained a hardcoded "no payment history" placeholder. Once a real payment cleared, the page still could not show it, and the fix was to load payments from the real records. Separately, the billing rewrite dropped a table, but the delete confirmation in another part of the product still counted rows in it. That dangling reference blocked the deploy for two commits and had also made deleting a business impossible in production. Nothing flagged either problem, because an empty list is a valid render and the other reader lived in a different area from the change.
THE RULE: A placeholder or empty state that stands in for real data must be replaced or made to fail loudly once the data can exist. Before dropping or reshaping a table, find every reader of it across the whole product, not just the area you are working in.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Search the code for hardcoded empty states, such as fixed empty lists or placeholder text, on any page whose purpose is to display real records, and confirm each one reads from real data.
2. Before merging a schema change that drops or renames a table, list every query and count that references it across all areas of the product, including deletion and confirmation flows.
3. Run each page that displays records against at least one real record in a preview or test environment, and confirm the record appears instead of an empty state.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.