Refactoring Project and Carry-Forward

Project: a reviewable compatibility migration

Budget 16–22 hours; reuse the five labs rather than inventing a new application.

1. Freeze the invoice and grid baseline; write public observations and failure cases.
2. Refactor the invoice through checked intermediate snapshots. Keep a generator failure, rounding boundary and clock trace. Explain one candidate you rejected.
3. Change the internal Grid representation while preserving old and new APIs on the same state. Include mixed-version sequences and unchanged-state failures.
4. Submit a migration note covering supported consumers, authority, recovery and alias retirement. Use the uncertain-write experiment as a counterexample to automatic fallback; no live service or deployment is required.
5. In a separate implementation or private branch, change invoice rounding to aggregate rounding. Record exact before/after expectations and label this as a policy change. Do not modify the frozen preservation baseline.

Deliver a fresh-run README, contracts, actual intermediate diffs and check logs, three experiment records, a short design decision, and an assistance declaration. The supplied reference is calibration, not a substitute for your own process.

A reviewer should trace an unseen mixed-client sequence and a failure between an effect and its acknowledgement. If no reviewer is available, label the result self-assessed and independent review pending. All ten competency gates, core behavior and the changed-case defense are required; line counts and speed add no credit by themselves.

Carry the public contracts and migration record into Module 3: Behavioral Patterns. This module does not complete the semester's separate accessibility and usability strand. Retain that evidence requirement at semester integration.