Livecheck Charge Kept Ahead of the DXdev Deploy

Our AI agent skipped a code review finding because no live DXdev charge existed, and four minutes later the hub told it one did.

What the agent was building

We are launching a paid service, and its public buy route is not on yet. Its payments go through our card processor, and the charges are mirrored into our books. Think of a filing cabinet. The agent’s job was to give DXdev sales a shelf of their own, so they don’t land on the shelf for client revenue.

A DXdev charge carries a tag, venture=dxdev. A tagged charge now files under its own DXdev category, split by product. The card fee and any refund are netted into the same row, and none of it is attributed to a client.

Refunds were the awkward part. The refund record’s own metadata is empty, so the rule reads the tag from the original charge through refund.charge, which is newly expanded.

The proof and the review

The agent tested the rule against our real sandbox Stripe account, read-only. The tagged test transactions categorized correctly through the real mapping code, with the fee netted and zero leakage. Targeted tests passed at 309, and tsc and lint were clean.

Then a second review, run with Codex, covered only the five files we had changed. It found three issues. The agent fixed two.

• A tagged refund_failure would have become a zero-value “DXdev payment” row and hidden the real money movement. The tag now applies only to charge, payment, refund and payment_refund.
• A charge tagged venture=dxdev with no product would have fallen back into client revenue. It now files under DXdev as “(no product)”.

Both got new tests. The count went from 309 to 312.

The finding it skipped

The third issue was that mirror rows stored before this change carry no DXdev tag. The agent skipped it. Its reasoning was that no live DXdev charge existed yet, so nothing old needed the tag. The first live one would be fetched fresh, and a test-to-live key flip forces a full backfill. It wrote that the point needed revisiting only if live DXdev charges ever predate a deploy.

Earlier it had also checked that the ledger-sync timer has been off since 10/19/26, so it saw no live risk.

Four minutes later

At 2:19 pm the hub told the agent a live DXdev charge existed. It was a standing 1 dollar minus the card fee, in live mode, tagged venture=dxdev and product=livecheck, and it was being kept, not refunded.

The belief behind the skip was wrong. A live charge existed, and the five files were still uncommitted, with the push go still open with me. A live charge had come ahead of the deploy, the exact case the agent said would need revisiting.

We do not know whether the books have copied that charge. The timer was off and the live check had not been run. The hub’s instruction was not to run it then.

What went on the ticket

The agent recorded the state on the ticket: the five uncommitted files, the finished second review and the pending push go. The kept live charge must be confirmed in the DXdev category before the public buy route flips. The refund leg was proven in test mode only, so the live path stays unverified.

The skip answered a review finding with a belief about timing, and the belief was wrong. Until the kept livecheck charge is confirmed in the DXdev category, the public buy route stays off.

dxdev LESSON · paste into your AI coding agent
LESSON: Check Whether The World Has Changed Before Dismissing A Review Finding With A Belief About Timing
SOURCE: dxdev.com/blog/slug-every-sale-needs-its-own-shelf
WHAT HAPPENED: The agent gave DXdev sales their own category in the books, using a venture=dxdev tag on each charge and reading the tag from the original charge for refunds. Targeted tests passed at 309, and a second Codex review of five changed files found three issues. The agent fixed two and added tests, taking the count to 312. It skipped the third, that mirror rows stored before the change carry no DXdev tag. Its reason was that no live DXdev charge existed, so nothing old needed the tag. At 2:19 pm the hub said a live charge tagged product=livecheck existed and was being kept, and the work log had recorded it at 10:29 that morning. The five files were still uncommitted, so a live charge had come ahead of the deploy, the exact case the agent said would need revisiting.
THE RULE: Do not dismiss a review finding on an unverified assumption about timing or state. Check the live record, and when you do defer a finding, write down the exact condition that would reverse the decision.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Every review finding dismissed as not applicable cites a verified fact, such as a log entry or a query result, rather than a belief about current state.
      2. Each deferred finding names the concrete condition that would make it apply, and that condition is checked against live data before the change ships.
      3. A release gate, such as turning on a public buy route, stays closed until the data produced by earlier live activity has been confirmed in the new category.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.