6 Commits

Include renames

Author	SHA1	Message	Date
ehoandClaude Opus 5	f19185ed81	refactor(auth): land Session -> Principal, add MedewerkerAdapter (RB-13) ... ADR-0002 SS3 models Zorgverlener/Medewerker as different Principal variants with different login flows. Actor #2 (apps/behandelportal) landed in WP-61/67 and the union never followed: grep -rn "Principal" returned one hit, a comment. Both apps' auth/domain/session.ts stayed byte-identical (`{ bsn, naam }`), so the backoffice's Behandelaar carried a BSN and logged into the backoffice as a citizen, by DigiD, under a fabricated citizen's name (login.page.ts). The divergence ADR-0002 predicted took an orthogonal side door instead (medewerker.interceptor.ts's X-Medewerker/X-Rollen stamp, which never touches SessionStore) -- which is why ssp/auth and bhp/auth still measured as 100%/84% duplicated after ADR-C-006 shared the route guards. RB-09 (landed the day before) made the backend's IIdentityProvider able to say "no identity" and fail closed; this ticket is its named FE half. Each app's auth/domain/session.ts becomes principal.ts, holding the one Principal variant that app actually has an actor for: ssp keeps `{ kind: 'zorgverlener', bsn, naam }` (G1 still strips the BSN before persisting); behandelportal gets `{ kind: 'medewerker', medewerkerId, naam, rollen }` (no BSN to strip -- G2 shape validation only). A new MedewerkerAdapter replaces DigidAdapter in behandelportal, resolving the existing MEDEWERKER_ID/currentRollen() dev stand-in into a Principal; because there is no credential to check, it returns Principal directly rather than a Result whose error variant could never occur. login.page.ts stops being a BSN/wachtwoord form -- one explainer line and an "Inloggen met SSO" button -- and its dead error-handling branch goes with the Result wrapper that justified it. Measured with tools/baseline-scan.mjs --dup: auth duplication drops from 168/168 (ssp) and 168/200 (bhp) to 32/179 and 32/259 -- under the backlog's <40 target. What remains is the ADR-C-006 route-guard re-export (deliberately identical), generic test/story-file boilerplate, and one shared fragment of the root-singleton-store idiom -- not re-converged identity or login-flow logic. SS3's prediction that the two actors would authenticate differently enough to justify not sharing auth has now actually been tested, not just asserted, and held. Also: renamed Session.bsn to Principal.bsn in two doc comments (libs/shared/src/infrastructure/subject.ts, subject.interceptor.ts) that cited the old type name; regenerated libs/shared/docs/behaviour-spec.mdx (generated file, per its own banner); recorded the resolution in ADR-0002 as a new amendment, replacing its "Known debt" section. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 16:54:26 +02:00
ehoandClaude Opus 5	4b94f8edb5	fix(flags): surface a failed admin toggle instead of swallowing it ... FeatureFlagStore.set() was try/finally with no catch. A rejected PUT /admin/flags/{key} escaped into the `void this.store.set(...)` call site as an unhandled promise rejection; the finally-block reload then snapped the control back to its old value. The admin saw a toggle that silently refused to move, with no error rendered anywhere and nothing in the state. set() now folds through the existing runSubmit helper and returns Result<string, void>, reloading either way so the state still reflects the server. The page awaits it and renders the failure in an app-alert. Found by the CQRS-light pass (CQ-002/CQ-004) as one of three mutations that reach the raw ApiClient without producing a Result — the baseline's BL-007 inventory had missed all three. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 18:13:29 +02:00
ehoandClaude Sonnet 5	af8a011819	feat(behandelportal): WP-65b beoordeling besluit (decision write) ... Adds POST /beoordeling/{id}/besluit: a Besluit enum (Goedkeuren/Afwijzen/ MeerInfoOpvragen) backed by new Aanvraag.BesluitStatus/BesluitToelichting columns, gated by the same BeoordelingRules.CanDecide the read side's canBesluiten flag already uses (409 on an illegal transition, 400 on a missing required toelichting). Mappers.ToStatusDto gains the "a recorded decision wins" branch. FE: besluit.machine.ts + besluit-form organism (same form idiom as change-request-form), wired into the beoordeling page behind the server's canBesluiten flag. Completes WP-65 (65a + 65b) — verified end-to-end against a running backend (werkvoorraad -> beoordeling -> besluit -> status reflected back). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-03 09:46:20 +02:00
ehoandClaude Sonnet 5	4133b30e5d	feat(behandelportal): WP-65a beoordeling detail (read) + fix unreachable medewerker login ... New GET /beoordeling/{id} shows one aanvraag's status, linked documents, and a canBesluiten decision flag, gated by the same CanBeoordelen capability as the werkvoorraad list. Reads through IZaakSource.ListCases rather than a new seam method (WP-66 needs one anyway for the real write); owner BSN is masked. Fixes a real gap found while wiring this up: the behandelportal's login was still WP-61's copied citizen/BSN DigiD flow, so nothing ever sent X-Medewerker and the werkvoorraad screen (WP-64) always denied in a real browser. A dev-only medewerkerInterceptor (mirrors the existing ?role= stand-in as ?rollen=) fixes that. WP-65's own Risks note authorized splitting read from write across sessions given its size; this is the read half. The decision-recording mutation is next (65b). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-03 09:01:09 +02:00
ehoandClaude Sonnet 5	fe69caee63	feat(behandelportal): WP-64 werkvoorraad (queue) screen ... New GET /werkvoorraad endpoint lists aanvragen still open (Ingediend/InBehandeling), gated by the medewerker capability (CanBeoordelen) rather than the admin role — reuses the existing ApplicationSummaryDto, no new DTO. GET /me now surfaces aanvraag:beoordelen for a behandelaar so the FE can gate with the same AccessStore/capabilityGuard idiom every other page uses. FE: a behandeling domain type deliberately narrower than ssp's full AanvraagStatus union (only the two open tags — illegal states unrepresentable), composed into a werkvoorraad-list organism from existing shared/ui molecules. Replaces WP-61's scaffold placeholder as the app's real landing page. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-02 22:02:35 +02:00
ehoandClaude Sonnet 5	e7156c5132	feat(WP-67): merge behandelportal into this repo as a monorepo ... Restructures into apps/ssp + apps/behandelportal (two Angular projects) plus libs/shared + libs/beheer (cross-app libraries), replacing WP-61's separate sibling repo. That split had already produced real drift: a hand-vendored copy of the backend's OpenAPI doc, a shared/ui+layout tree forked and silently diverging (7 files), and beheer + the styles.scss token bridge duplicated byte-for-byte across both repos. - git mv the SSP's src/app/* into apps/ssp/; fold shared/, beheer/, environments/, the Storybook docs/*.mdx, and styles.scss into libs/shared + libs/beheer (all confirmed identical between the two repos before merging). auth stays deliberately duplicated per ADR-0002 (actor-specific, expected to diverge) - amended there. - One generated API client (libs/shared), no more vendored swagger.json. - .dependency-cruiser split into a base factory + one config per app, and Storybook into .storybook-ssp/.storybook-behandelportal - both forced by the @auth/* alias resolving to different directories per app. - SiteHeaderComponent/ShellComponent gained HEADER_NAV_ITEMS/ HEADER_ADMIN_LINKS/DEBUG_PANEL injection tokens so each app supplies its own nav/admin-links/dev-panel instead of one being hardcoded. - CLAUDE.md, ARCHITECTURE.md, dependencies.md, and ADR-0002 updated; WP-67 backlog entry documents the full decision trail. npm run ci green (lint, dep:check x2, 360 tests across ssp/ behandelportal/shared/beheer, both localized builds, backend tests, snippet + api-client drift); both dev servers, both Storybook instances, and docker compose verified working. The old sibling repo (/home/eho/repos/behandelportal) is left untouched, not deleted. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-02 21:01:57 +02:00