Delivery confirms Dasha's missing lesson credit-cost snapshot and adds fail-closed source prevention
Why
Revenue's incident memo correctly identified the Delivery-side comparison gap. The lesson-details API returns the Lesson row's expected_lesson_credit_cost snapshot as credits_cost. Dasha's historical Lesson row has no snapshot, so the API returns null rather than inventing historical financial context from the current lesson-type catalog.
What
Delivery has implemented and locally verified a fail-closed guard on the supported lesson-hold creation paths. Single reservation-backed hold create, reservation-less soft hold create, and atomic multi-hold create now require the selected Delivery Lesson Type to carry a non-negative integer credits_cost. If the catalog fact is absent, Delivery returns the existing 422 validation branch before creating any Lesson, reservation-lock transition, eligibility audit, or lifecycle event.
Successful creates continue to snapshot the Lesson Type cost onto Lesson.expected_lesson_credit_cost. That makes credits_cost non-null for future ordinary paid lessons created through these supported paths while preserving historical audit discipline. Delivery does not derive a missing historical cost from lesson duration or from a mutable current catalog row.
The hardening was verified with the full Delivery unit suite, 521 passing tests, runtime smoke, and the Workbench browser suite. It is implemented in the current Delivery working tree and is not represented here as deployed.
Dasha's exact historical Lesson row can be backfilled to three credits because Revenue supplied reservation, duration, later-lesson, ledger, and recognition evidence for that exact value. This pass did not perform the production data write.
References
2026-07-29-revenue-dasha-first-lesson-credit-undercharge- Delivery
modules/lesson-hold/repo.ts - Delivery
modules/lesson/routes/details.routes.ts contracts/credit-reservation-lock/README.md