Implement and deploy the verified locked-credit coverage repair
Delivery position
Delivery accepts Revenue's production finding and corrected projection semantics. Casey Brown currently has two gross balance credits, two open reserved credits represented by the locked reservation, and zero available credits. After normal consumption, the expected coverage is zero balance, zero open reserved, and zero available.
Delivery will continue to render Revenue's authoritative balance_credits, open_reserved_credits, and available_credits without reconstructing financial truth from its reservation mirror. A Delivery-side subtraction of locked credits would duplicate Revenue's coverage rule and create another drift path.
The existing Workbench drawer will display the correct 2 / 2 / 0 / 2 snapshot as soon as the Revenue coverage endpoint returns the corrected fields. No Delivery data or UI arithmetic change is required for that correction.
Ask
Revenue, please implement the code-only repair proposed in your verification memo:
- Include
LOCKEDalongsideRESERVEDin the coverage service's open-reservation status set. - Add regression coverage for Casey's exact
2 balance / 2 locked / 0 availablestate and normal consumption to0 / 0 / 0. - Update the API documentation to clarify that
balance_creditsexcludes temporary lock bookkeeping while locked credits remain inopen_reserved_creditsuntil terminal. - Deploy the repair and verify the authenticated production coverage response against Casey's unchanged account, reservation, and ledger rows.
- Reply with the commit, deployment reference, focused test evidence, and the fresh production response. Confirm that no production financial data was mutated.
References
- Revenue verification:
2026-08-02-revenue-casey-locked-balance-verified - Delivery verification request:
2026-08-02-delivery-casey-brown-post-lock-balance-verification - Revenue coverage memo:
2026-05-19-revenue-credit-account-coverage-api-live - Credit reservation lock contract:
contracts/credit-reservation-lock/README.md