[process·qa] Cash-anchor recompute mid-first_review has no documented receipt slot for its second preview card

[atomchung]

Trigger

Same /fomo-qa dogfood session as #662 (2026-07-31, main@e58fef9, mock persona sample_ai_holder, first_review). flows/first-review.md step 6 says: after the user answers the cash-anchor ask, run add-cash, "rerun preview on the session it returns, and show that card before the commitment is written." I followed that literally: I had already recorded artifact_generated/card_presented for stage=preview against the pre-cash-anchor card (holdings-only view, no account-level return), then resolved the cash ask, called add-cash, reran preview on the new session id, and showed that second, materially different preview card (now carrying account-level return, cash-drag framing, and a new acct_perf_basis honesty sentence) — all before the rule choice / commitment.

ux_receipt.py's own contract requires artifact_generated and card_presented to appear exactly once per stage (tools/ux_receipt.py:1289,1291). Nothing in references/ux-receipt.md, flows/first-review.md, or the fomo-qa skill's known-traps list says whether this second, materially-different preview presentation should be its own stage=preview event pair, a stage=final-shaped event, or is simply not meant to be separately receipted at all. I recorded the first (pre-cash) preview presentation once and could not re-record the second per the exactly-once rule, so the archived trace's stage=preview artifact path points at a card the user did not actually use to make their commitment decision — the append-only trace has no way to correct this after the fact (same class of gap as #523: a real, product-prescribed user-visible step with no clean receipt slot).

Why this matters

references/ux-receipt.md:61 already handles the session id half of this ("keep the original session id for the whole trace... a receipt records one conversation, not one engine session"), but not the artifact/card_presented half. Any first_review or weekly_review walkthrough that resolves an absent cash anchor (which #357/#379 suggest is common — a first_review's input.cash_anchor.status starts absent whenever the source carries none) hits this same gap and has no documented, correct way to receipt it.

Proposal (for discussion, not decided)

• Simplest: state explicitly (in references/ux-receipt.md) that the stage=preview artifact/card pair should be recorded after any pre-commitment recompute loop (cash anchor being the only one today) settles, not at the first preview call — i.e., defer the receipt event, not the presentation itself, when the agent knows a recompute may follow.
• Or: give the post-cash-anchor recompute its own distinct, repeatable event (not bound by the stage's exactly-once rule) so both presentations are auditable.

Evidence

Mock-only session (sample_ai_holder.csv), no real account data. This walkthrough's own trace (isolated dogfood coach root) shows the sequencing described above if useful for reproduction.

Privacy

No real trade data.