F-r-ldraledigplannerare/frontend_mvp_complete.md

Junior Developer — Frontend MVP Completion TODO

Owner: Junior developer Status: Ready to implement (tackle after frontend_polish.md) Goal: Close the gap between the bare happy path and the app described in ARCHITECTURE.md — a usable shell with navigation, a working settings page, calendar planning, the manual-data fallback, and partner planning.

Why this plan exists: the current dashboard has no header nav, no logged-in user, no child indicator, no logout, and no reachable settings — so features that already exist in code (Calendar, Tips, Settings, manual entry) are stranded. The backend endpoints for all of this already exist; this is almost entirely frontend wiring.

Work in tiers, top to bottom. Tier 1 is the highest value (it's what makes the app feel like an app). Keep tsc/lint/tests green per task. CSS stays optional — structure and function over looks.

---

TIER 1 — App shell: navigation, identity, working settings

T1.1 — Real header (user, current child + switcher, nav, logout)

Problem: components/layout/Header.tsx already accepts onLogout / onWorkspaceSelect, but pages only pass { title }, so the nav is empty. There's no way to log out, switch pages, or see who/which child you're viewing.

Do — extend Header and wire it via Layout on every page:

• Logged-in identity: show the current parent's name. ⚠️ GET /api/auth/context does not currently return the parent's display name (only personal_data_uuid, workspace_id, children). Either show the email from GET /api/auth/me, or ask the senior to add name to the /auth/context payload (small, preferred). Don't hardcode.
• Current child + switcher: useWorkspace() exposes children, selectedChildId, selectChild(). Render a <select> of children; changing it calls selectChild(id). Show the selected child's name in the header. (If only one child, a static label is fine.)
• Nav links: Översikt (/), Kalender (/calendar), Tips (/tips), Inställningar (/settings) using react-router <Link>/NavLink. These routes already exist in App.tsx.
• Logout: a "Logga ut" button → useAuth().logout() then navigate('/auth', { replace: true }).
• Apply the header consistently: pass the nav/user/logout props through Layout so every page gets the same shell (Dashboard, Calendar, Tips, Settings).

Acceptance: Every authenticated page shows a header with the parent's name, a child selector reflecting/affecting selectedChildId, working nav links to all four pages, and a logout button that returns you to /auth.

---

T1.2 — Make Settings reachable and actually save

Problem: pages/Settings.tsx renders the right inputs but most saves are no-ops or broken. Notably handleSaveVacationDays sends personalDataUuid: 'current-user' (a hardcoded string, not a UUID); the parent profile (salary_type / employment_status) and planning goal have no save handlers at all; child birth/preschool date in settings doesn't persist. The page is also unreachable (fixed by T1.1 nav).

Do — wire each section to its real endpoint (all exist; use the IDs from useWorkspace() context — personalDataUuid, workspace.id, selectedChildId):

Setting	Endpoint	Notes
Parent profile (salary_type, employment_status)	PUT /api/settings/parent/{personal_data_uuid}	Drives the salary-gated tips (§6). Add a save handler — currently local state only.
Planning goal (max_time / max_money / balanced)	PUT /api/workspace/{workspace_id}	Add a save handler. Note the value strings the backend expects (check WorkspaceUpdate schema) — the page currently defaults to 'balance', confirm it's 'balanced'.
Vacation days / year	POST /api/vacation-days	Fix the 'current-user' bug → pass the real personalDataUuid.
Child birth date + preschool start date	PUT /api/settings/child/{child_id}	Preschool date powers the studiedagar tip.
Break periods	POST/PUT/DELETE /api/break-periods	Mostly wired already — verify add/remove persist and reload.

• Load current values into the form (don't always default to 25 vacation days / 'balance' — read from the fetched workspace/parent/vacation data).
• Give each section its own save button + success/error message, and re-fetch after save so the UI reflects persisted state.

Acceptance: From Inställningar you can set salary type, employment status, planning goal, annual vacation days, and the child's birth/preschool dates; each persists (survives reload) and shows a success message. No 'current-user' placeholder.

---

TIER 2 — Planning & data entry

T2.1 — Calendar: add / edit / delete planned days

Problem: pages/Calendar.tsx renders a month grid but day clicks do nothing (per the round-3 report). Planning days is the core of the app.

Do:

• Clicking a day opens a small day-planner (reuse/extend the existing inputs): choose day type (sjukpenning / lägstanivå / vacation), and for two-parent workspaces, which parent + whether it's a dubbeldag.
• Persist via POST /api/planned-days; allow delete via DELETE /api/planned-days/{id}; edit via the PUT route.
• Validate against remaining days before saving (ARCHITECTURE feature): don't let planned FP exceed days_left from the latest snapshot; surface the analytics/validation error (the backend has dubbeldagar validation — show its message).
• Refresh the calendar + the dashboard breakdown after changes.

Acceptance: You can add, edit, and delete planned days from the calendar; the day shows its type; over-planning is blocked with a clear message; the dashboard's "Planerade dagar" reflects changes.

---

T2.2 — Manual data-entry fallback

Problem: ARCHITECTURE §2.3 mandates a manual-entry path that always works even if scraping is unavailable. The backend has it (POST /api/parental-leave/manual, api.saveManualFetch), but there's no UI — the only way to get data in is the scraper.

Do:

• Add a "Ange uppgifter manuellt" form (near the FK fetch button or in Settings) collecting the same fields the user sees on FK: total_days, days_used, reserved total/left, transferable left, dubbeldagar left, and the tier breakdown. Use the field bounds from the backend schema (total_days 0–480, dubbeldagar_left 0–60, etc.).
• Save via api.saveManualFetch (source='manual'), then refresh the overview. The provenance line from P1 will then show "Manuellt angiven …".

Acceptance: A user can enter their FK numbers by hand and see the overview populate, with no scraper involved.

---

TIER 3 — Partner planning & tips (rounds it out)

T3.1 — Add a partner (solo planning path)

Problem: The product premise is planning with a partner, but there's no UI to add a second parent. The backend supports the no-login "solo planning" path: POST /api/workspace/{workspace_id}/parents adds a placeholder parent profile (just a name).

Do:

• In Settings, add "Lägg till partner" → creates a placeholder PersonalData via that endpoint, then re-fetch context so the second parent appears.
• Let per-parent settings (T1.2) and calendar planning (T2.1) target either parent.
• Optional / stretch: collaborative planning via invitations (POST /api/workspace/{id}/invitations, POST /api/invitations/redeem) — list it but defer unless time allows.

Acceptance: A user can add a partner profile and plan/configure days for both parents in one workspace.

T3.2 — Verify Tips end-to-end

Problem: pages/Tips.tsx + TipCard exist and the backend tips engine is implemented, but the page was unreachable.

Do: Now reachable via T1.1 nav — verify it loads tips for the selected workspace/child (GET /api/tips/{workspace_id}), renders severity badges, and that the salary-/goal-gated tips actually appear once T1.2 lets users set salary type and planning goal. Fix any contract mismatches you find.

Acceptance: Tips page shows real tips driven by the user's configured settings.

---

Suggested order & notes

1. T1.1 → T1.2 first: navigation + working settings unlock everything else and deliver the most visible improvement.
2. Then T2.1 (calendar) — the biggest single chunk; budget accordingly.
3. T2.2 (manual fallback) is small and satisfies an architectural must-have — good quick win.
4. Tier 3 rounds out the partner story; invitations are optional.

One backend dependency to flag to the senior: the parent display name isn't in GET /api/auth/context (T1.1). Everything else uses endpoints that already exist — read each router's actual @router decorator and request/response schema before wiring, and don't invent paths (see the path-mismatch lesson from the last round).

Out of scope: real CSS/visual design, responsive/mobile, accessibility audit, real-time updates — separate passes once the functionality is complete.