Changing a field from one value to a collection affects records that already exist. In Reset, the habit reader handles that transition at the persistence boundary.
Convert the legacy shape once#
Older habit records can store motivation as a string. Newer records use a list. The model reader accepts both, wrapping a valid legacy string in a list and exposing the resulting list to the rest of the application.
That conversion keeps widgets from making their own decisions about which record version they received. A motivation editor can operate on the model's list rather than branching on raw database types.
The write path stores the newer shape. This gives the application a direction for future records while retaining a way to read the older ones.
Review date compatibility separately#
The same model accepts a Firestore timestamp or a stored date string for the habit start date. These are two storage representations of a date, rather than two meanings for the habit itself.
A fallback to the current time keeps parsing from stopping the interface, but can obscure an invalid historical start date. The inspected implementation includes fallback behavior; a future improvement would distinguish missing or invalid dates explicitly instead of silently presenting a new start date as history.
Keep mutations aligned with the collection#
The provider uses array operations for motivation changes. Adding a value uses an array union, deleting uses array removal, and replacing a value combines removal and addition.
Those operations explain why the collection model matters beyond rendering. Compatibility should be reviewed alongside the mutations that create future records.
Treat migration behavior as product behavior#
A successful migration preserves what a person wrote and how the interface explains it. Reading old records, writing new records, and handling malformed values are separate checks. This source review demonstrates the conversion path; it does not report a new execution of the application's tests.