Files
F-r-ldraledigplannerare/frontend/tests/fixtures/plan.ts
T
jacobh2 782415122d Separate user intent from planner output via day assertions
The calendar mixed two kinds of truth in one table. `planned_leave_day` was
simultaneously the allocator's output cache, the user's override store
(`is_pinned`, plus ad-hoc rows with no `wish_id`), and the resource ledger that
analytics and the age-4 maths read. The planner therefore had to ask "am I
allowed to touch this row?" on every sync, and got it wrong at the edges.

Every user assertion is now one `day_assertion` row — a concrete `day_type`
replaces a pinned day, a row with no `wish_id` replaces an ad-hoc day, and
`day_type='none'` replaces `planned_day_exclusion`. `planned_leave_day` becomes
purely derived with a single writer, and `PlanningService.pinned_keys()` is the
single answer to "is this day pinned", used by the allocator's loader, by
`sync_plan` and by the read router alike.

On top of that, every calendar band is now a real event: an ad-hoc band opens
the same full editor as a wish-backed one and saving it promotes it to a
`LeaveWish`, so it can be named, repeated yearly, assigned to either or both
parents, and handed to the planner. "Planering" is a `moveable` toggle plus a
from/to month bound plus a separate lock/unlock action on the days themselves,
replacing a three-rung ladder whose "planner decides" rung set a search window
equal to the drawn dates and so could never move anything.

Bugs found and fixed along the way:

- The plan erased its own history. Fixed windows clip to today, so an elapsed
  auto-placed day fell into `stale_keys` and was deleted on the next sync —
  and a background sync runs on every workspace load. Past rows are now frozen
  and counted as spent.
- Migration 010's downgrade silently destroyed every pinned day and exclusion
  (`is_pinned` returned as DEFAULT 0, the exclusion table came back empty,
  exit 0, no warning). It now reconstructs both from `day_assertion`, and 009
  itemises what it cannot recover before dropping the table.
- Deleting a period left its assertions behind, locking those dates forever
  with no UI path to clear them. Wish deletion now clears them by `wish_id`.
- `DayAssertionService` and `LeaveWishService` committed multi-statement writes
  without a transaction; a crash mid-write diverged the tables or half-deleted
  a series. Both now run in a unit of work.
- A sibling year's shortfall was never surfaced: the toast only inspected the
  edited occurrence's outcome, so a fully unfunded later year rendered as an
  empty band with no warning.
- A flexible window whose bound had entirely elapsed was dropped from the
  proposal with no outcome at all. It now reports as `unplaced`.
- Unlocking a period deleted its days instead of returning them to the planner.
- The e2e global setup posted to a route deleted in this change, which would
  have failed the whole suite before its first test.

Gates: backend 938 tests / 91% coverage, frontend 1351 / 97.4 | 92.2 | 94.37 |
97.4. Migrations 009 and 010 audited against a hand-built realistic database:
the upgrade reconciles exactly and a constraint violation fails safe, leaving
the schema at 008.

Not complete. Step 4's toggle, month picker and lock/unlock action are verified
by browser walk and unit tests, but the partial-lock readout was not exercised.
`ideas.md` §7 adds a full plan for the vacation-forfeiture defect (the planner
detects expiring days and then does nothing about them) — not implemented here.
Remaining smaller items are listed in the session's restructure notes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T4wjgbVL4HAC5Rdaw75VbV
2026-09-21 07:20:14 +02:00

216 lines
5.3 KiB
TypeScript

/**
* Shared test fixtures — the planning engine (`POST /api/plan/propose`,
* `POST /api/plan/apply`) and its nested shapes.
*/
import type {
CostBreakdown,
DayCollision,
PlanAge4Projection,
PlanApplyResponse,
PlanChange,
PlanProposal,
PlanSyncResponse,
PlanSyncWithWishResponse,
PlanWarning,
PoolBalance,
ProposedDay,
Rejection,
ShortfallRemedy,
SurplusAdvice,
VacationBalance,
WindowOutcome,
} from '@/types'
import { makeLeaveWish } from './mockData'
export function makeCostBreakdown(overrides: Partial<CostBreakdown> = {}): CostBreakdown {
return { free: 0, vacation: 0, sjukpenning: 0, lagsta: 0, ...overrides }
}
export function makeShortfallRemedy(overrides: Partial<ShortfallRemedy> = {}): ShortfallRemedy {
return {
kind: 'dubbeldag',
messageKey: 'planRemedies.example',
data: {},
daysFreed: 0,
...overrides,
}
}
export function makeProposedDay(overrides: Partial<ProposedDay> = {}): ProposedDay {
return {
date: '2026-06-15',
parentPersonalDataUuid: 'pd-a',
childId: 'child-1',
dayType: 'sjukpenning',
isDubbeldag: false,
wishId: 'lw-1',
reason: 'Sommar',
...overrides,
}
}
export function makeWindowOutcome(overrides: Partial<WindowOutcome> = {}): WindowOutcome {
return {
wishId: 'lw-1',
wishName: 'Sommar',
wishNameMessageKey: null,
year: 2026,
startDate: '2026-06-15',
endDate: '2026-07-26',
weeksWished: 6,
weeksFunded: 6,
shortfallDays: 0,
strategy: 'parent_swap',
messageKey: 'planOutcomes.windowExplanation',
data: {},
costBreakdown: makeCostBreakdown({ free: 12, vacation: 19, sjukpenning: 11 }),
remedies: [],
shiftGainDays: 0,
seriesId: null,
...overrides,
}
}
export function makePlanWarning(overrides: Partial<PlanWarning> = {}): PlanWarning {
return {
kind: 'days_lost_at_age_4',
messageKey: 'planWarnings.days_lost_at_age_4',
data: {},
...overrides,
}
}
export function makePoolBalance(overrides: Partial<PoolBalance> = {}): PoolBalance {
return {
parentPersonalDataUuid: 'pd-a',
childId: 'child-1',
sjukpenningLeft: 310,
lagstaLeft: 90,
dubbeldagarLeft: 55,
...overrides,
}
}
export function makeVacationBalance(overrides: Partial<VacationBalance> = {}): VacationBalance {
return {
parentPersonalDataUuid: 'pd-a',
year: 2026,
totalDays: 25,
savedDaysIn: 0,
alreadyUsed: 0,
isAssumed: false,
...overrides,
}
}
export function makeSurplusAdvice(overrides: Partial<SurplusAdvice> = {}): SurplusAdvice {
return {
kind: 'wish_more_leave',
messageKey: 'planSurplus.wish_more_leave',
daysInvolved: 0,
data: {},
...overrides,
}
}
export function makePlanAge4Projection(overrides: Partial<PlanAge4Projection> = {}): PlanAge4Projection {
return {
parentPersonalDataUuid: 'pd-a',
childId: 'child-1',
fourthBirthday: '2029-06-01',
projectedLeftAtB4: 0,
savableAfterB4: 96,
expiringAtB4: 0,
...overrides,
}
}
export function makePlanProposal(overrides: Partial<PlanProposal> = {}): PlanProposal {
return {
days: [makeProposedDay()],
outcomes: [makeWindowOutcome()],
warnings: [],
poolBalances: [],
vacationBalances: [],
surplusAdvice: [],
age4Projections: [],
...overrides,
}
}
export function makeDayCollision(overrides: Partial<DayCollision> = {}): DayCollision {
return {
date: '2026-06-15',
parentPersonalDataUuid: 'pd-a',
childId: 'child-1',
existingDayType: 'vacation',
proposedDayType: 'sjukpenning',
...overrides,
}
}
export function makeRejection(overrides: Partial<Rejection> = {}): Rejection {
return {
messageKey: 'planApply.rejection.insufficientBalance',
data: {},
...overrides,
}
}
export function makePlanApplyResponse(overrides: Partial<PlanApplyResponse> = {}): PlanApplyResponse {
return {
accepted: true,
createdCount: 0,
skippedIdenticalCount: 0,
skippedFreeCount: 0,
replacedCount: 0,
collisions: [],
rejections: [],
createdDays: [],
...overrides,
}
}
/** `POST /api/plan/sync` — one (child, parent, date) slot's delta. See
* `PlanChange`'s docstring (src/types/entities.ts) for the `kind` vocabulary. */
export function makePlanChange(overrides: Partial<PlanChange> = {}): PlanChange {
return {
kind: 'added',
date: '2028-06-20',
parentPersonalDataUuid: 'pd-a',
childId: 'child-1',
oldDayType: null,
newDayType: 'vacation',
oldIsDubbeldag: null,
newIsDubbeldag: false,
oldWishId: null,
newWishId: 'lw-1',
evicted: false,
...overrides,
}
}
export function makePlanSyncResponse(overrides: Partial<PlanSyncResponse> = {}): PlanSyncResponse {
return {
proposal: makePlanProposal(),
applyResult: makePlanApplyResponse(),
changes: [],
...overrides,
}
}
/** `POST /api/plan/sync-with-wish`'s response — the wish as created/updated
* plus the same `PlanSyncResponse` shape `syncPlan()` returns. See
* `PlanSyncWithWishResponse`'s doc comment (src/types/api.ts): `wish` is
* present even when `sync.applyResult.accepted` is `false`. */
export function makePlanSyncWithWishResponse(
overrides: Partial<PlanSyncWithWishResponse> = {},
): PlanSyncWithWishResponse {
return {
wish: makeLeaveWish(),
sync: makePlanSyncResponse(),
...overrides,
}
}