F-r-ldraledigplannerare/NextSteps260915.md

# Next Steps — handoff, 2026-09-15

**Format note for whoever dispatches this:** each task below (§2 onward) is written as a
self-contained brief. Copy ONE brief verbatim into a subagent prompt — it does not need the rest
of this file, `NextSteps260914.md`, or `NextSteps260913.md`. Only the orchestrator needs §0/§1.
`NextSteps260913.md` and `NextSteps260914.md` are history — do not edit them.

---

## 0. State as of now (all committed, working tree clean)

Commits this session: `e3d19f2`, `42cebba`, `dd7f0ff`, `084ee91`, `760b312`.

Gates, all currently green — **these are the baselines to paste into every verifier**:
- Backend: **439 tests passing**, `ruff check` clean, `ruff format --check` clean (128 files)
- Frontend: **710 tests passing / 56 files**, `npm run typecheck` clean, `npm run lint` 0 issues
- Coverage (frontend): 96.54% lines/statements, 91.08% functions, 86.84% branches. Thresholds are
  a **regression ratchet — never lower them**: lines 95 / statements 95 / functions 89 / branches
  85. Backend CI gate `--cov-fail-under=75` (measured ~81), set in `.github/workflows/ci.yml`.

Everything in `NextSteps260914.md`'s roadmap is DONE, including full browser verification.

---

## 1. Shared preamble (orchestrator reads this once; do not forward to subagents)

**Stack:** Python 3.14 / FastAPI / uv backend (no ORM, hand-rolled repositories, Alembic
migrations); TypeScript / React 18.3 / Vite 5 / Vitest frontend (no TanStack Query, no Redux,
hand-rolled i18n). Full conventions in `/Users/jhag/projects/Föräldraledigplannerare/CLAUDE.md`.

**Run the app:**
```bash
cd frontend && npm run dev     # starts BOTH vite (5173) and uvicorn (8000)
```
Vite binds IPv6 `::1` — use `http://localhost:5173`, **not** `127.0.0.1`. If the API behaves
impossibly, check `lsof -nP -iTCP:8000 -sTCP:LISTEN` for a squatter (macOS resolves `localhost` to
`::1` first).

**Seed demo data:**
```bash
cd backend && uv run python scripts/seed_demo.py --reset
```
Login `demo@example.com` / `DemoPass123!`. Creates a couple workspace: Alex (has a login, a
near-drained pool) and Sam (no-login partner, created via `add_placeholder_parent`, large
surplus), child Nova, vacation rows for only some years (so `is_assumed` badges show), a worked
override and an off override, and four wishes including a flexible one and a deliberately
underfunded one (produces both shortfalls and surplus advice).

**Sanity-check the engine without a browser:** `backend/scripts/demo_plan.py`.

**Verification commands:**
```bash
cd backend  && uv run ruff check . && uv run ruff format --check . && uv run pytest
cd frontend && npm run typecheck && npm run lint && npx vitest run && npm run coverage
```

**Cost rule (from `CLAUDE.md`):** a Haiku subagent runs these itself, immediately. A Sonnet-or-larger
subagent must NOT run full-suite verification itself — it finishes the code change, then spawns a
Haiku subagent with the exact commands, the directory to run them from, the numeric baseline above,
and an instruction to paste **raw verbatim output**, not a summary. Several agents have reported
gates as "all green" that were in fact failing — a report without pasted output is not accepted.
This rule does not apply to a single focused test run while mid-task.

**Browser verification matters.** Every significant bug found this project — the calendar
overshoot, the flexible-wish double-booking, the doubled age-4 entitlement, two stale-data bugs —
was found by driving the running app while the entire suite was green. Suites confirm the code
does what it was written to do, not what it should do. `backend/tests/integration/test_user_journey.py`
guards the main journey but is not a substitute for clicking.

---

## 2. Waves

- **Wave 1 — investigation, no code guessed.** Task A only. It touches read paths across
  frontend and backend but the brief explicitly forbids shipping a fix before the behaviour is
  confirmed, so it cannot safely run in parallel with a wave that edits the same files for a
  different reason. Not blocked on anything.
- **Wave 2 — independent file-owning tasks, can run fully in parallel.** Tasks B (frontend
  `WishEditor.tsx` UI, blocked on a product decision — see brief), C (frontend test files only,
  raises branch coverage), and D (backend `analytics_service.py` docs/decision framing, blocked on
  a product decision). B, C, D touch disjoint files (B: `WishEditor.tsx` + its test + i18n; C: test
  files across the frontend under existing components; D: `analytics_service.py` region + possibly
  `Dashboard.tsx`) and none touches a file Task A investigates, so all three can be dispatched
  together once Wave 1's finding is known (Task A might turn out to change what Task B/D need, but
  neither B nor D depends on A's *outcome* to start — see each brief's decision-flag).

If Task A concludes "this is a real bug and the fix is obvious and small," that fix is a **new**
task, not folded into A's brief — A is investigation-only per the instructions below.

---

## Task A — Investigate the Settings partner section

### Goal
Determine, with evidence (not assumption), whether the Inställningar (Settings) page's partner UI
is broken or working as designed. In the seeded couple workspace, partner "Sam" exists in the
workspace and is planned around (wishes, allocations, the surplus/shortfall picture all reference
Sam), but the Settings page currently shows only an empty "Add a partner" form with no visible
indication a partner is already linked. This was spotted in passing during a previous session and
was **not** dug into — it may be correct behaviour with unusual seed data, or it may be a real gap.
Done looks like: a clear, evidenced verdict — "this is a bug, here is exactly what's wrong and
where" or "this is correct, here is why the seed data made it look wrong" — with no code changed
unless the fix is trivial and you have explicit confirmation from whoever dispatched you that
shipping it is in scope.

### Owned files
Read-only investigation. If (and only if) you get explicit go-ahead to fix something, the only
files in scope are:
- `frontend/src/pages/Settings.tsx`
- `frontend/src/context/WorkspaceContext.tsx`
- `backend/app/routers/workspace.py`

Do not touch anything else without asking first.

### Constraints and traps that apply to THIS task
- **`vi.mock('@/context')` does NOT intercept direct submodule imports** like
  `@/context/AuthContext`. Mock the exact specifier the component imports — this caused 14 test
  failures once. `Calendar.test.tsx` / `Settings.test.tsx` show the right idiom.
- **`localStorage` is unreliable in this test sandbox** (Node's experimental webstorage shadows
  jsdom's). Use `vi.stubGlobal('localStorage', mock)`.
- **Every user-facing string must be `message_key` + `data`**, never a hardcoded Swedish string.
  `backend/tests/integration/test_user_journey.py::TestNoSwedishOnTheWire` walks responses for
  å/ä/ö and will fail violations. `frontend/src/i18n/sv.ts` is the source of truth; `en.ts` derives
  its type from it, so a key missing from either is a compile error.
- **No `any`, `@ts-ignore` or `@ts-expect-error`** — `no-explicit-any` is an ESLint error and CI
  runs `--max-warnings 0`.
- **Use `npm run typecheck`, never `npx tsc`** — npx resolves a newer TypeScript and emits a bogus
  `TS5101 baseUrl is deprecated` error.
- **`git grep` only searches tracked files** — use plain `grep` when checking new or uncommitted
  work.
- **Never delete, skip or weaken a test to make a suite pass.**

### Facts already gathered (starting point — verify, don't re-derive from scratch)
- `frontend/src/pages/Settings.tsx` has an "Add partner" form (`handleAddPartner`, around line 230;
  the JSX section starts around line 397 with `settings.partnerSectionTitle`) that POSTs via
  `api.addPartner`. It does **not** appear to call `api.listWorkspaceMembers` anywhere, nor render
  any existing-member list — grep confirms `members`/`Members` do not appear in `Settings.tsx`.
- `frontend/src/services/api.ts` around line 868–872 has `listWorkspaceMembers(workspaceId)` which
  calls `GET /workspace/{id}/members` — this function exists and is used elsewhere (for picking
  which parent a wish belongs to in wish editing) but is a candidate for what Settings is missing.
- `backend/app/routers/workspace.py` has `GET /api/workspace/{workspace_id}/members` (returns all
  `PersonalDataResponse` rows, i.e. both the logged-in user and any placeholder partner) and
  `POST /api/workspace/{workspace_id}/parents` (`add_placeholder_parent`) which is how the seeded
  partner "Sam" was created — a `PersonalData` row with **no login**, per
  `backend/scripts/seed_demo.py` (`PARTNER_NAME = "Sam"`, `add_placeholder_parent`).
- `frontend/src/context/WorkspaceContext.tsx` exposes `parentName` (the *current logged-in user's*
  name) and `personalDataUuid`, but has no field for "other members" or "partner name" — check
  whether this is intentional (Settings might be expected to fetch members itself) or a real gap.

### What to actually check
1. Run the app with seeded demo data, log in as `demo@example.com`, open Inställningar, and look
   at the partner section with your own eyes (or via `mcp__claude-in-chrome__*` browser tools).
   Confirm what is and isn't shown.
2. Read all of `Settings.tsx` to see if there's member-fetching logic you missed (e.g. behind a
   loading state, an error being swallowed, or a condition that's never true for this seed).
3. Check the network tab / add a temporary log to see if `GET /workspace/{id}/members` is even
   called from Settings, and if so, what it returns for the demo workspace.
4. Check `Settings.test.tsx` for existing coverage of the partner section — does a test already
   assert "no member list is shown," which would mean it's a deliberate v1 scope cut rather than a
   bug that slipped through?
5. Decide: is the correct behaviour "show existing partner(s) with a way to manage/remove them" and
   Settings simply never got that view built (a real gap), or is the current one-shot "add a
   partner" form intentional because a workspace only ever gets one partner added once, after
   which the UI doesn't need to display them here (they show up in the Plan/Calendar contexts
   instead)? Look for the second parent's name surfacing anywhere else in Settings (e.g. a
   per-parent vacation table) as evidence for the second reading.

### Done criteria
No code changes are the default outcome. Report:
- The concrete behaviour observed (with a screenshot or copied DOM/text if using the browser
  tools).
- Whether `GET /workspace/{id}/members` is called from Settings, and what it returns.
- A clear verdict: bug vs. by-design vs. "by-design but confusing enough to flag for a product
  decision."
- If you conclude it's a bug and the fix is small and obvious (e.g. "just render the existing
  members list that `listWorkspaceMembers` already returns"), you may implement it, but only after
  making the verdict explicit in your own reasoning — do not silently patch it as a side effect of
  investigating. If you do fix it, run:
  ```bash
  cd frontend && npm run typecheck && npm run lint && npx vitest run && npm run coverage
  ```
  and confirm no regression against the frontend baseline (710 tests passing / 56 files, coverage
  ≥ 96.54/91.08/86.84 for lines/functions/branches) before reporting done. Per the cost rule, if
  you are a Sonnet-or-larger agent, delegate that run to a Haiku subagent and require verbatim
  output.

### Anything needing a product decision
If Task A finds the display is ambiguous-but-defensible (e.g. the partner does show up elsewhere,
just not in Settings), flag to the product owner: *should Settings show a "Partner: Sam" line with
a remove/replace action once a partner exists, instead of (or alongside) the add-partner form?*
Do not guess an answer and build it.

---

## Task B — Custom bounding-range picker for flexible wishes

### Goal
A flexible wish ("när det passar bäst") today can only be bounded by one of four season presets
(vår 03-01→05-31, sommar 06-01→08-31, höst 09-01→10-31, jul 12-01→01-31, which wraps the year
end). This was a deliberate v1 scope cut, not a rejection. Done looks like: a family can pick an
arbitrary date range (e.g. "sometime between March 15 and April 20") as the bounding range for a
flexible wish, in addition to keeping the four season presets as one-click shortcuts. The engine
side needs no changes — a flexible wish already reuses the existing `window_start_month/day` /
`window_end_month/day` fields as its search bound; this is a UI-only addition.

### Owned files
- `frontend/src/components/planning/WishEditor.tsx`
- `frontend/src/components/planning/WishEditor.test.tsx` (or wherever its existing test file is —
  confirm the exact name with `git ls-files | grep -i wisheditor` before starting)
- `frontend/src/i18n/sv.ts` and `frontend/src/i18n/en.ts` (new keys only, additive)

Do not touch `backend/app/services/allocation_service.py`, `backend/app/entities/leave_wish.py`,
or `PLANNING_ENGINE_SPEC.md` — no engine or spec change is needed for this task.

### Constraints and traps that apply to THIS task
- **A literal `*/` inside a JSDoc block comment prematurely closes it and breaks the whole file** —
  this already bit this exact file (`WishEditor.tsx`) once. Avoid nested JSDoc strings containing
  `*/`, or escape them carefully, in any comment you add or edit.
- **Every user-facing string must be `message_key` + `data`**, never a hardcoded Swedish string in
  the frontend component — use `frontend/src/i18n/sv.ts` as the source of truth; `en.ts` derives
  its type from it, so a key missing from either is a compile error.
- **No `any`, `@ts-ignore` or `@ts-expect-error`** — `no-explicit-any` is an ESLint error and CI
  runs `--max-warnings 0`.
- **Use `npm run typecheck`, never `npx tsc`** — npx resolves a newer TypeScript and emits a bogus
  `TS5101 baseUrl is deprecated` error.
- **Never delete, skip or weaken a test to make a suite pass.**
- **`localStorage` is unreliable in this test sandbox** — use `vi.stubGlobal('localStorage', mock)`
  if the component or its tests touch it.
- The bounding-range fields already exist and are named `windowStartMonth` / `windowStartDay` /
  `windowEndMonth` / `windowEndDay` in the wish object built by `WishEditor.tsx` (see
  `addPreset`/`addSeasonPreset`, around lines 162–182) — a custom picker must populate exactly
  these same fields, in the same month/day (not full-date) shape, since that's what the backend
  entity and allocator expect. Do not invent a new field or a full ISO-date representation.
- Season presets fill the bounding range only, **not** the final placement (see the existing
  `PLANNING_ENGINE_SPEC.md §10.1`/§10.7 comments already in the file around lines 58–65 and
  179–182) — a custom range picker must follow the same contract: it sets the search bound, the
  engine still picks the actual placement inside it at propose time.

### Done criteria
```bash
cd frontend && npm run typecheck && npm run lint && npx vitest run && npm run coverage
```
Must show: typecheck clean, lint 0 issues, all tests passing (baseline 710 passing / 56 files, this
task adds tests so the count should only go up), and coverage not regressing below the current
ratchet (lines 95 / statements 95 / functions 89 / branches 85 — current measured 96.54 / 96.54 /
91.08 / 86.84). Per the cost rule, if you are a Sonnet-or-larger agent, delegate this run to a
Haiku subagent and require verbatim output, not a summary.

Also do a manual browser pass (seed demo data per §1, log in, open a wish editor, add a flexible
wish, use the custom picker, propose a plan) — this project's history is that suites pass while the
feature is subtly broken in the browser (double-booking, overshoot, etc. were all browser-only
finds).

### Anything needing a product decision
**This entire task is blocked on a product decision that has not been made:** how much freedom to
expose in the custom picker. Options include (not exhaustive, do not pick one yourself):
- Any two dates, unconstrained (family could pick a 300-day bounding range).
- A minimum/maximum span (e.g. must be between 1 and ~90 days) to keep the engine's
  window-scanning inside sane limits.
- Whether the picker allows a range that wraps the calendar year end, the way the `jul` preset
  does, or restricts custom ranges to a single calendar year for simplicity.
- Whether the four season presets stay as visible quick-picks alongside the custom picker, or the
  custom picker replaces them once available.
Do not guess and build; get this decided (or explicitly ask the user) before writing UI, since it
changes the validation logic and the i18n copy.

---

## Task C — Raise frontend branch coverage

### Goal
Frontend branch coverage (86.84%) is the weakest of the four coverage metrics and has the least
headroom above its ratchet floor (85%). Done looks like: branch coverage measurably higher than
86.84% (ideally comfortably clear of 85, e.g. 88%+), achieved by adding real tests for genuinely
untested branches — not by deleting or weakening any existing test, and not by chasing the number
with low-value tests that don't exercise a real decision path.

### Owned files
Test files only — do not modify any non-test source file to make coverage easier to hit. Before
starting, run `npm run coverage` and read the generated HTML/text report
(`frontend/coverage/`) to find the actual weakly-covered branches (this project's own history notes
that `Auth.tsx`, `Tips.tsx`, `DevFetch.tsx` were previously at or near 0% — check whether that is
still true or has since improved before assuming those are still the gaps). Pick specific files
based on the report, then add or extend the corresponding `*.test.tsx`/`*.test.ts` file for each.
Do not touch files owned by Task A (`Settings.tsx`) or Task B (`WishEditor.tsx`) — if the coverage
report points you at either of those, pick a different low-coverage file first and leave a note
about the overlap instead of racing another task's edit.

### Constraints and traps that apply to THIS task
- **`vi.mock('@/context')` does NOT intercept direct submodule imports** like
  `@/context/AuthContext`. Mock the exact specifier the component imports — this caused 14 test
  failures once. `Calendar.test.tsx` / `Settings.test.tsx` show the right idiom.
- **`localStorage` is unreliable in this test sandbox** (Node's experimental webstorage shadows
  jsdom's). Use `vi.stubGlobal('localStorage', mock)`.
- **No `any`, `@ts-ignore` or `@ts-expect-error`** — `no-explicit-any` is an ESLint error and CI
  runs `--max-warnings 0`.
- **Use `npm run typecheck`, never `npx tsc`** — npx resolves a newer TypeScript and emits a bogus
  `TS5101 baseUrl is deprecated` error.
- **Never delete, skip or weaken a test to make a suite pass.** This applies doubly here: the whole
  point of this task is more real coverage, not a smaller denominator.
- **A literal `*/` inside a JSDoc block comment prematurely closes it** — be careful if any test
  file you touch has JSDoc-style comments.
- **`git grep` only searches tracked files** — use plain `grep` when checking new or uncommitted
  work by other in-flight tasks so you don't collide with them.

### Done criteria
```bash
cd frontend && npm run typecheck && npm run lint && npx vitest run && npm run coverage
```
Baseline to compare against: 710 tests / 56 files passing, coverage 96.54% lines/statements,
91.08% functions, 86.84% branches. After this task: test count should increase, all four coverage
numbers should be equal or higher (branches specifically should move up meaningfully, not by
0.01%), and none of the ratchet floors (lines 95 / statements 95 / functions 89 / branches 85)
should regress. Per the cost rule, if you are a Sonnet-or-larger agent, delegate this run to a
Haiku subagent and require verbatim output, not a summary.

### Anything needing a product decision
None — this is pure test-quality work with no user-visible behaviour change. If while adding tests
you discover a branch that looks like a real bug (not just untested), stop and report it separately
rather than writing a test that locks in wrong behaviour.

---

## Task D — Per-parent age-4 breakdown on the Dashboard

### Goal
The Dashboard's age-4 stat ("Förfaller vid 4 års ålder") is workspace-wide — it sums both parents'
projected expiring days into one number and the label says "all parents". The Plan tab, by
contrast, already breaks this down per parent. Both numbers are currently correct (a prior bug that
doubled one parent's entitlement was fixed in commit `760b312`), so this is **not** a bug fix — it
is a product decision about whether the Dashboard should also show a per-parent breakdown for
clarity, the way the Plan tab does. Done looks like, IF the product owner confirms they want it: the
Dashboard shows each parent's own expiring-day count (not just the combined total) using the
per-parent projection the backend already computes, with the combined total kept or clearly
labelled as a sum, whichever the product owner picks.

### Owned files
- `backend/app/services/analytics_service.py` (read-only reference; a per-parent breakdown is
  likely already computed here — do not change its arithmetic without a specific reason)
- `frontend/src/pages/Dashboard.tsx`
- `frontend/src/pages/Dashboard.test.tsx`
- `frontend/src/i18n/sv.ts` / `frontend/src/i18n/en.ts` (new keys only, additive, if new labels are
  needed)

Do not touch `backend/app/models/plan.py`'s dataclass→response mapping unless the per-parent field
needed on the Dashboard genuinely isn't on the wire yet — check first (see traps below).

### Constraints and traps that apply to THIS task
- **The 390 + 90 tier totals are the whole CHILD's entitlement across BOTH parents**, not one
  parent's. One parent's no-snapshot default is `days_per_parent` (240 = 195 + 45). Getting this
  wrong doubled a parent's entitlement and made two screens disagree — this was fixed in `760b312`
  precisely in this area of the code (`analytics_service.py`), so be careful not to reintroduce it
  while restructuring how the numbers are displayed.
- **The dataclass→response mapping in `backend/app/models/plan.py` is hand-written** and has
  silently dropped new engine fields twice before. If you need a new field on the wire, add an
  **API-level** test, not just a service test, to prove it actually reaches the response body.
- **Every user-facing string must be `message_key` + `data`**, never a hardcoded Swedish string.
  `frontend/src/i18n/sv.ts` is the source of truth; `en.ts` derives its type from it, so a key
  missing from either is a compile error.
- **No `any`, `@ts-ignore` or `@ts-expect-error`** — `no-explicit-any` is an ESLint error and CI
  runs `--max-warnings 0`.
- **Use `npm run typecheck`, never `npx tsc`** — npx resolves a newer TypeScript and emits a bogus
  `TS5101 baseUrl is deprecated` error.
- **Never delete, skip or weaken a test to make a suite pass.**
- Reference facts already confirmed in `backend/app/services/analytics_service.py`: it has
  `expiring_at_b4` per parent (a single-parent projection, `max(projected_left - 96, 0)`) and a
  combined view with `combined_days_used`, `combined_days_left`, `combined_expiring_at_b4` (sum
  across all parents' projections) — the per-parent numbers this task needs already exist
  server-side; check whether they already reach the Dashboard's API response or need adding to the
  relevant response model.

### Done criteria
Backend (only if you touch it):
```bash
cd backend && uv run ruff check . && uv run ruff format --check . && uv run pytest
```
Baseline: 439 tests passing, ruff check clean, ruff format --check clean (128 files); count should
only increase.

Frontend:
```bash
cd frontend && npm run typecheck && npm run lint && npx vitest run && npm run coverage
```
Baseline: 710 tests / 56 files passing, coverage 96.54%/96.54%/91.08%/86.84% (lines/statements/
functions/branches); none of the ratchet floors (95/95/89/85) may regress.

Per the cost rule, if you are a Sonnet-or-larger agent, delegate both runs to a Haiku subagent and
require verbatim output, not a summary. Also do a manual browser pass with seeded demo data (see
§1) comparing the Dashboard and Plan tab numbers for Alex and Sam side by side — this is exactly
the kind of two-screens-disagree bug that has bitten this project before (`760b312`).

### Anything needing a product decision
**This entire task is blocked on a product decision:** does the product owner actually want a
per-parent breakdown on the Dashboard, or is the current combined "all parents" framing intentional
(e.g. because the Dashboard is meant to be an at-a-glance household view and per-parent detail
belongs only in the Plan tab)? If yes, also decide: does the combined total stay visible alongside
the per-parent numbers, or does the per-parent breakdown replace it? Do not guess and build either
answer.

---

## 3. Traps reference (for the orchestrator only — already duplicated into each brief above)

Kept here once for the orchestrator's own awareness; do not point a subagent at this section
instead of the duplicated version in its brief — that defeats the point of self-contained briefs.

- `holidays` library combined names (`"Påskdagen; Söndag"`) — exact-string match only.
- `_FULL_SCHEMA` in `backend/app/db/connection.py` must track Alembic migrations.
- `vi.mock('@/context')` doesn't intercept direct submodule imports.
- `backend/app/models/plan.py` dataclass→response mapping is hand-written and has dropped fields
  twice.
- `localStorage` unreliable in the test sandbox — `vi.stubGlobal`.
- `git grep` only searches tracked files.
- Literal `*/` inside JSDoc breaks the file (bit `WishEditor.tsx` once).
- `npm run typecheck`, never `npx tsc` (npx resolves a newer TS, bogus `TS5101`).
- No `any` / `@ts-ignore` / `@ts-expect-error` — ESLint error, CI `--max-warnings 0`.
- Never delete/skip/weaken a test to make a suite pass.
- Keep the `Allocator` pure — no DB, no `date.today()`.
- Every user-facing string is `message_key` + `data`; `TestNoSwedishOnTheWire` enforces it.
- 390+90 tiers are the whole child's entitlement across both parents, not one parent's.

## 4. Decisions already made — do not relitigate (for the orchestrator's awareness)

- Planning horizon runs past B4; the FP pool is capped at `min(remaining, 96)` after — show the
  squeeze, don't refuse.
- Valborgsmässoafton is NOT a default day off.
- No API calls at runtime in the planner; calendar cache covers 2026–2055, `strict=True` raises
  `UncachedYearError` → 422 rather than silently degrading.
- 2049 and 2055 legitimately have 17 red days (Pingstdagen coincides with Sveriges nationaldag).
- Flexible wishes are propose-time suggestions, never auto-applied; fixed wishes always win.
- An applied flexible occurrence may move on a later re-propose (no `wish_id` on
  `planned_leave_day`).
- WishEditor v1 ships season presets only — a custom range picker (Task B above) is deferred, not
  rejected.
- Coverage thresholds are a regression ratchet, never lowered to make a gate pass.
- i18n is hand-rolled on purpose — no `react-i18next`.
- Verification cost rule: Haiku runs the suites itself; Sonnet+ delegates and requires verbatim
  output.