jacobh2
76b1e712b9
Works through every numbered item in NextSteps260913.md section 3, plus the three known verification issues in section 4.1. Surface what the backend already computed: - 3.1 render surplus_advice in PlanResults, mirroring the shortfall remedies - 3.2 surface VacationBalance.is_assumed so assumed statutory years are visible - 3.3 age-4 expiry given the proposed plan, via a new Age4Projection reusing the existing _age4_projections arithmetic (Dashboard stat verified, not rebuilt) Calendar cluster (one pass over the holiday data): - new GET /api/calendar/days exposing roda dagar, klamdagar and day overrides, paginated four years at a time - 3.4 shade roda dagar/klamdagar, with R/K badges so colour is not the only signal - 3.6 click-to-override behind an explicit mode toggle, leaving drag multi-select intact - 3.7 click month/year to advance - 3.8 per-year red-days list in Settings, statutory days plus overrides i18n: - 3.5 five backend-generated Swedish surfaces converted to message_key + data, following the tips_service pattern; old string fields replaced, not kept Flexible wishes (3.9): - PLANNING_ENGINE_SPEC section 10: window_mode, candidate search, cost function, deterministic tie-break, two-pass ordering, test matrix rows 15-24 - backend: entity, migration 006, _FULL_SCHEMA sync, repository, allocator - frontend: season-preset toggle in WishEditor, unplaced outcome rendering Fixes (4.1): - pin typecheck to the local tsc rather than npx resolving a newer TypeScript - ignore generated coverage/ and dist/ in the ESLint flat config - fix the flaky usePlanApply test properly, with waitFor rather than a retry Tests: backend 361 -> 404, frontend 540 -> 704. Coverage 89.47% -> 96.52% lines. Not yet verified in a browser. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RXMhc9nT6sNz1SL4j8dznL
32 lines
1.3 KiB
Python
32 lines
1.3 KiB
Python
"""Domain entity: PersonalData (parent profile).
|
|
|
|
A PersonalData represents a parent in the planning workspace. It intentionally
|
|
exists without a User login so that solo planning for a partner who hasn't
|
|
registered is possible (see ARCHITECTURE.md §3.0).
|
|
|
|
personnummer storage is discouraged (see §11). If kept, personnummer_enc must
|
|
be keyed HMAC / authenticated encryption — never a plain SHA-256.
|
|
"""
|
|
|
|
from dataclasses import dataclass, field
|
|
from datetime import datetime
|
|
from uuid import UUID
|
|
|
|
|
|
@dataclass
|
|
class PersonalData:
|
|
uuid: UUID
|
|
workspace_id: UUID
|
|
name: str
|
|
salary_type: str = "monthly" # 'monthly' | 'hourly'
|
|
employment_status: str = "employed" # 'employed' | 'jobseeking' | 'none'
|
|
# Semesterlagen: minimum vacation days that must be *taken* each year;
|
|
# only days above this may be saved (up to 5 years). Default is the
|
|
# statutory 20, but employers may set a higher floor and entitlements
|
|
# differ per parent, so this is user-editable (see PLANNING_ENGINE_SPEC
|
|
# §9.2 and app.config.LeaveRules.min_vacation_days_per_year).
|
|
min_vacation_days_per_year: int = 20
|
|
personnummer_enc: str | None = None # encrypted/HMAC; prefer None
|
|
created_at: datetime | None = field(default=None)
|
|
deleted_at: datetime | None = field(default=None)
|