Flag the superseded sections of the design docs

ARCHITECTURE.md and PLANNING_ENGINE_SPEC.md still described the planning
goal, the per-wish goal override, and a per-parent age-4 ceiling of 96 days
as current. Rather than rewrite two long documents that remain useful as
history, each stale section now carries a SUPERSEDED banner naming what is
true instead. The banners sit above the code fences they annotate, not
inside them.

ARCHITECTURE.md

@@ -1,5 +1,7 @@
 # Föräldraledigplannerare - Architecture & Implementation Plan
 
+> Parts of this document are superseded — search for **SUPERSEDED** for the current behaviour.
+
 **Date:** 2026-05-31 (updated 2026-09-13)  
 **Status:** Planning phase - reviewed, decisions incorporated (see §0). Planning engine drafted in **PLANNING_ENGINE_SPEC.md**.  
 **Tech Stack:** TypeScript + React + Vite (frontend), FastAPI + Python 3.14 (backend), SQLite → Postgres  
@@ -276,6 +278,8 @@ Two ways a second parent enters a workspace:
 
 ### 3.1 Entities (Domain Layer)
 
+> **SUPERSEDED (2026-09-15).** `goal_override` was removed entirely (migration 009). The allocator now applies a single policy based solely on `salary_type`. `PlannedLeaveDay` gained `wish_id` (migration 008) linking it back to the wish that produced it (nullable, for ad-hoc/legacy days), and `is_pinned` to mark days the user hand-edited so the allocator won't retype them.
+
 ```typescript
 // backend/app/entities/personal_data.py
 from dataclasses import dataclass
@@ -458,6 +462,8 @@ class PlannedLeaveDay:
 
 ### 3.2 Database Schema (SQLite/Postgres)
 
+> **SUPERSEDED (2026-09-15).** `planned_leave_day` gained `wish_id` (migration 008) to link persisted days back to the wish that produced them, and `is_pinned` to mark hand-edited days the allocator should not retype. `workspace.planning_goal` was removed entirely (migration 009). `leave_wish` gained nullable `target_days` (migration 008, overrides `target_weeks`), and `goal_override` was removed entirely (migration 009).
+
 ```sql
 -- personal_data: a parent profile (login optional). Isolated for GDPR.
 CREATE TABLE personal_data (
@@ -777,6 +783,8 @@ class PlanningService:
 
 ## 5. API Endpoints
 
+> **SUPERSEDED (2026-09-15).** The `planning_goal` endpoint was removed entirely (migration 009).
+
 ```
 # Authentication
 POST   /api/auth/register
@@ -854,6 +862,8 @@ The app provides contextual recommendations. Because the app does **not** comput
 - During the child's **first year**, SGI is protected regardless of how few days are taken — so a parent can take little or no föräldrapenning that year and preserve days for later without losing SGI.
 - After the child turns **1**, a non-working parent generally must take out parental benefit **at least 5 days/week** (or be a registered jobseeker) to keep full SGI.
 
+> **SUPERSEDED (2026-09-15).** `planning_goal` was removed entirely (migration 009). The engine now applies a single allocation policy based solely on `salary_type`, as described in PLANNING_ENGINE_SPEC.md §3.3.
+
 The engine derives these from the child's birth date and the planned weekly intensity; **no salary figure is needed** — only the categorical `salary_type` (monthly vs hourly) and `employment_status` on each parent, plus the workspace `planning_goal`. Tips are ranked by the active goal (`max_time` surfaces day-preserving tips; `max_money` surfaces salary-protecting tips). The rules below reference helper predicates that operate on the combined plan (fetched snapshot + planned days).
 
 ### 6.1 Tip catalogue (incl. user-specified strategies)
@@ -995,9 +1005,11 @@ The weekend/red-day "wrapping" tips reflect a common monthly-salary pattern, but
 
 This is the app's reason to exist, but the original draft never defined it. It combines three inputs **per parent, per child**:
 
+> **SUPERSEDED (2026-09-15).** The age-4 savable cap was incorrectly applied as 96 per parent. It is now 48 per parent in couple mode with two parents, and 96 otherwise (commit 6da947f, `resolve_age4_savable_cap`).
+
 1. **Actual usage** from the latest `ParentalLeaveFetch` (or manual entry): `days_used`, `days_left`, tier breakdown.
 2. **Planned future days** the workspace has laid out in the calendar (not yet reported to FK).
-3. **Statutory caps**: the 480/parent pool, the 96-day age-4 ceiling, and the age-12 hard expiry.
+3. **Statutory caps**: the 480/parent pool, the 96-day age-4 ceiling (or 48 in couple mode with two parents), and the age-12 hard expiry.
 
 **Definitions** (compute as of the child's 4th birthday `B4 = birth_date + 4 years`):
 
@@ -1439,6 +1451,8 @@ The planner never makes API calls at runtime — it uses a committed calendar ca
 
 1. **`AllocationInputLoader`** (async) — the ONLY part that touches repositories or the wall clock. Assembles a frozen `AllocationInput` from database state.
 
+> **SUPERSEDED (2026-09-15).** The allocator no longer uses `planning_goal`. It now applies a single policy based solely on `salary_type` (PLANNING_ENGINE_SPEC.md §3.3).
+
 2. **`Allocator`** (pure) — no `await`, no repository access, no `date.today()`. Given the same `AllocationInput`, always produces identical output. This is the engine's heart: it turns `LeaveWish` intents into `ProposedDay` rows, choosing between föräldrapenning tiers and vacation based on the workspace `planning_goal` and parent `salary_type`, modeling parent-swap, dubbeldagar, and preschool day reserves along the way.
 
 The separation is critical: the pure allocator is cheap, re-runnable on every wish edit, and trivially unit-testable without a database. For the full design (window expansion, tier selection, shortfall remedies, warnings), see **PLANNING_ENGINE_SPEC.md**.