Updates

ideas.md

@@ -5,23 +5,7 @@ value. Not a backlog — things worth arguing about.
 
 ---
 
-## 1. Sole custody has no way to exist
-
-A parent with sole custody is entitled to all 480 days. The app cannot express that: every parent
-row defaults to half the child's total, and `planning_mode` (`solo` | `couple`) is an *app-usage*
-flag — whether you are coordinating two calendars — not a custody flag. So a sole-custody parent
-and someone who simply has not added their co-parent yet are byte-identical in the data, and both
-are told they have 240 days.
-
-`config.py`'s module docstring already flags single custody as deliberately unbuilt. It needs its
-own field, never a reuse of `planning_mode`, and the rule for what it grants needs confirming
-against Försäkringskassan before a number is written down.
-
-**Why it matters:** the app silently halves a real user's entitlement.
-
-**Update (2026-09-19):** Addressed. One member = sole parent (480 days, 96 savable at age 4); two members = 240 each (48 savable at age 4 per parent). Entitlement follows parent count, and onboarding asks explicitly ("Bara jag" / "Vi är två föräldrar").
-
-## 2. Multi-child is half-built
+## 1. Multi-child is half-built
 
 The tips engine now runs per child. The rest does not really. `TipsContext` was single-child until
 a fix two commits ago; the dashboard shows one child at a time via a header selector; the age-4
@@ -34,7 +18,7 @@ birthdays mean two cliffs.
 **Suggestion:** decide whether multi-child is a supported scenario. If yes, the timeline on
 Översikt is the natural place to show both; if no, say so in the UI rather than half-supporting it.
 
-## 3. The planner cannot explain itself
+## 2. The planner cannot explain itself
 
 Every funded day already carries a `reason` code (`vacation_wrap_red_day`, `fp_interior`,
 `swap_first_half`, `dubbeldag`, …) and every window produces a `WindowOutcome` with a cost
@@ -47,7 +31,7 @@ answer, and the data is already on the wire.
 **Suggestion:** surface the reason in the day popover — one line, plain Swedish. Cheapest
 high-value change on this list.
 
-## 4. Flexible periods can move without warning
+## 3. Flexible periods can move without warning
 
 A flexible wish is re-placed on every sync, and sync now runs on every edit. A summer period can
 therefore shift because you edited something in December. The change toast reports it, but a toast
@@ -56,7 +40,7 @@ is ephemeral and the user may not connect cause to effect.
 **Suggestion:** mark a flexible period visually as "placed by the planner, may move", and offer a
 one-click pin to fix it where it is. The machinery exists — `is_pinned` already protects days.
 
-## 5. Dismissed tips could hide a growing problem
+## 4. Dismissed tips could hide a growing problem
 
 Dismissals expire when the tip's `data` changes, which is the right instinct. But `preserve_for_age_4`
 is a warning whose numbers change slowly and monotonically — dismiss it in year two and it may not
@@ -65,18 +49,7 @@ resurface until the figure has moved materially, by which point less can be done
 **Suggestion:** exempt the age-4 warnings from dismissal entirely, or make them re-surface on a
 calendar cadence rather than only on data change.
 
-## 6. Onboarding asks for the hardest thing last
-
-The balances step asks a new user to fetch or type Försäkringskassan figures before they have seen
-the app do anything. The skip path exists and is labelled as estimated, which is good — but the
-ordering still front-loads the friction.
-
-**Suggestion:** consider letting the user reach a working calendar first and prompting for real
-balances once they have a plan worth making accurate. Worth an A/B if this ever gets real users.
-
-**Update (2026-09-19):** Step 3 now presents per-parent cards (one or two, depending on household size) with a "Klar" (Done) button that is always enabled, letting the user advance without entering data first. Skip copy was corrected.
-
-## 7. Vacation is modelled more thinly than parental leave
+## 5. Vacation is modelled more thinly than parental leave
 
 Parental-leave days have tiers, reserved portions, transferability, dubbeldagar and an age-4
 ceiling. Vacation has `total_days` and `saved_days_in` per year, plus a statutory floor on what
@@ -87,7 +60,7 @@ earned and advance days.
 Not obviously worth building. Worth knowing that vacation is the weaker half of the model, given
 the app's premise is optimising the two *together*.
 
-## 8. Smaller things
+## 6. Smaller things
 
 - **`ParentFacts.name` is dead.** Carried through the allocator, never read. Removing it churns
   fixtures across 580+ tests, which is why it survived a cleanup sweep. Do it opportunistically.