"A module is a faster way to write down what happened — never a claim about what was supposed to happen."
What a Module Actually Is
Dad and Pippa maintain recurring-capture modules together in the Modules tab, in two kinds: workout (indoor bike, the 3x total-body strength session, walks with Mom) and intake (protein powder, creatine, other repeated non-meal products). A module is a small template — an id, an immutable kind, a name, free-form default_values, notes, and an active flag. It is referenced by crumbs, and one shared CRUD implementation serves both kinds. That is the whole entity: a preset, not a plan.
Dropping a Chip Records Today
From the Stream, a module drops in as a chip. Pick Indoor Bike and adjust today's duration; pick Protein Powder and adjust today's servings. In both cases the module gives reusable structure while the new crumb records that day's actual event — the module_ref plus the day's adjusted module_values. The server, not the client, derives the crumb's surface from the module's immutable kind: a workout module makes a workout crumb, an intake module makes an intake crumb. The preset is a shortcut into the same free-prose stream, not a second kind of record.
Deactivate, Don't Destroy
Because crumbs reference modules, deleting a module would strand the crumbs that mention it. So modules deactivate rather than delete — the template goes inactive, and every crumb that ever used it keeps its module_ref and its recorded values intact. Even the schema evolution honored this: when the immutable kind field was added, pre-existing events replayed as workout rather than being rewritten. The append-only truth is never edited to fit a new shape; the new shape is derived over it. And note the boundary: changing meals stay free prose plus the optional slot chips — they are not modules, because a meal is not a repeated identical event the way a supplement is.