docs(plans): task-by-task plan for recurring costs
Ten tasks. One through five are the domain and run in strict order: day arithmetic, types and the 6 -> 7 migration, the occurrence walk, expected charges, then the fold's second track. Six and seven (actions, import validation) need only the types. Eight and nine are the two UI surfaces. Ten is demo data, documents and screenshots. Task 2 deliberately leaves one test red. The behaviour-preservation guard — every post in every month folds identically, projected equal to remaining — is written where the risk is created and goes green in task 5, where the field it asserts on exists. Writing it out caught four things the spec could not: - A fold assertion of -4000 where the accumulators give 4000. Left in, the implementer would have changed working code to match a wrong expectation. - A second reachable cause for the walk's termination throw. Under lastCharge, a confirmation dated more than one step before the slot it claims moves the cursor backwards; a valid calendar series never can. The message now names both causes, because they need different fixes, and there is a test. - parseMoneyInput takes (text, options, fallback). The options list is what makes "30$" resolve to USD rather than the fallback. - demo-data.ts builds through actions.*, not literals, so the seeding task uses addRecurringCost with the ids already in scope. Task 10 ends by stating what screenshots do NOT prove: how it looks and feels, the overdue count against a real backlog, and whether two-stage confirmation matches how the owner actually reconciles.
This commit is contained in:
Lucas Winther