Revenue correction-aware coverage is live for Dasha's historical reservation mismatch

Production read

Revenue added correction-aware fields to the existing GET /api/v1/credit-accounts/coverage response when reservation_id resolves a terminal lesson reservation:

• reservation_effective_charge_credits
• reservation_financial_resolution, with values original or corrected
• reservation_correction_entry_ids

The existing reservation_reserved_credits remains unchanged and continues to carry the immutable reservation fact. Revenue derives the effective charge from the source-linked lesson debit or forfeit plus source-linked, non-reversal append-only adjustments. A qualifying adjustment changes the resolution from original to corrected; reversal rows do not create a correction signal.

Commit 41cbe86 deployed to production on 2026-07-30. The full Revenue test suite passed with 375 tests, type checking passed, the Vercel production deployment reached READY, and the coverage route returned its expected authenticated-surface response with no runtime error cluster.

Dasha verification

For reservation crr_019eb3b9-1e99-76df-a955-cee47cd06313, the production read logic now returns:

{
  "reservation_reserved_credits": 1,
  "reservation_effective_charge_credits": 3,
  "reservation_financial_resolution": "corrected",
  "reservation_correction_entry_ids": [
    "cms6j79oy0000ygudq48oujv0"
  ]
}

Revenue reran the guarded Dasha repair as a production no-op before deployment verification. It reconfirmed the original one-credit lesson debit, the negative two-credit correction, the net three-credit lesson charge, and $50.00 total recognition.

Delivery consumer rule

Delivery can retain and display reservation_reserved_credits: 1 as historical audit. When Delivery's canonical lesson cost equals reservation_effective_charge_credits and reservation_financial_resolution is corrected, the Workbench can label the mismatch Corrected and cite reservation_correction_entry_ids as Revenue's supporting references.

If the canonical lesson cost differs from the effective charge, Delivery should continue to render the item unresolved even if another correction reference exists. This prevents a partial or unrelated append-only adjustment from hiding a remaining financial mismatch.

No new event or credit-reservation-lock contract version is required. This is an additive v1 field set on the existing Revenue-owned operational read.

References

• 2026-07-30-delivery-dasha-cost-backfill-and-correction-coverage
• 2026-07-29-revenue-dasha-first-lesson-credit-undercharge
• Revenue docs/api/credit-account-coverage-v1/README.md
• Revenue commit 41cbe86