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
parent d3f3b13345
commit e7156c5132
403 changed files with 7103 additions and 60917 deletions
@@ -0,0 +1,15 @@
+/**
+ * WIRE CONTRACT for the BRP address lookup ("BFF-lite" — one screen-shaped call).
+ *
+ * In production this is GENERATED from the OpenAPI/TypeSpec spec and served by our
+ * own backend, which talks to the BRP behind an adapter. The frontend never sees
+ * the BRP's own wire format. See docs/reference/architecture/0001-bff-lite-decision-dtos.md.
+ *
+ * "Geen adres bekend" is a first-class outcome (`gevonden: false`), not an error —
+ * the wizard falls back to manual entry (PRD §7). Slice 1 ships only the happy
+ * path (gevonden: true).
+ */
+export interface BrpAddressDto {
+  gevonden: boolean;
+  adres?: { straat: string; postcode: string; woonplaats: string };
+}
@@ -0,0 +1,59 @@
+/**
+ * WIRE CONTRACT for the dashboard screen — the "BFF-lite" response.
+ *
+ * PURE wire shapes: this file imports NOTHING (CLAUDE.md §1, ADR-0001). Enums are
+ * inlined string-literal unions that describe the wire, not the domain. The
+ * adapter's `parseDashboardView` validates this untrusted shape and MAPS it onto
+ * the FE domain model (Registration/Person/BigProfile) — that map is the
+ * decoupling seam: the wire can change without the domain following.
+ *
+ * In production these types are GENERATED from the OpenAPI/TypeSpec spec (one
+ * source of truth for both sides), and the `decisions` block is computed BY THE
+ * BACKEND — never recomputed on the client. The frontend renders decisions; it
+ * does not own the rules. See docs/reference/architecture/0001-bff-lite-decision-dtos.md.
+ *
+ * One screen-shaped call replaces the previous three (BIG-register + BRP + …),
+ * so the page always sees one consistent snapshot instead of three independently
+ * loading/erroring resources.
+ */
+
+/** Registration status on the wire: the discriminant tags as they arrive. */
+export type RegistrationStatusDto =
+  | { tag: 'Geregistreerd'; herregistratieDatum: string } // ISO date
+  | { tag: 'Geschorst'; geschorstTot: string; reden: string }
+  | { tag: 'Doorgehaald'; doorgehaaldOp: string; reden: string };
+
+export interface RegistrationDto {
+  bigNummer: string;
+  naam: string;
+  beroep: string;
+  registratiedatum: string; // ISO date
+  geboortedatum: string;
+  status: RegistrationStatusDto;
+}
+
+export interface AdresDto {
+  straat: string;
+  postcode: string;
+  woonplaats: string;
+}
+
+export interface PersonDto {
+  naam: string;
+  geboortedatum: string; // ISO date
+  adres: AdresDto;
+}
+
+/** Server-computed decisions. Rendered by the FE as-is (decision DTO, ADR-0001):
+    the eligibility rule lives on the backend; the optional reason lets the UI
+    explain itself without knowing the rule. */
+export interface HerregistratieDecisions {
+  eligibleForHerregistratie: boolean;
+  herregistratieReason?: string;
+}
+
+export interface DashboardViewDto {
+  registration: RegistrationDto;
+  person: PersonDto;
+  decisions: HerregistratieDecisions;
+}
@@ -0,0 +1,38 @@
+/**
+ * WIRE CONTRACT for the DUO diploma lookup ("BFF-lite" — one screen-shaped call
+ * returning everything the beroep step needs).
+ *
+ * Each diploma carries its server-computed `beroep` (the profession it maps to)
+ * and the `policyQuestions` (geldigheidsvragen) that apply to it. These are
+ * DECISIONS computed by the backend from the diploma's attributes — the frontend
+ * renders them, it does not derive them (decision-DTO pattern, ADR-0001). E.g. an
+ * English-language diploma carries the Dutch-proficiency question.
+ *
+ * `handmatig` is the fallback when the diploma is not in the DUO list: the
+ * professions the user may declare and the MAXIMAL policy-question set that then
+ * applies (a manual diploma is unverified, so the strictest set is used).
+ */
+export interface DuoLookupDto {
+  diplomas: DuoDiplomaDto[];
+  handmatig: ManualDiplomaPolicyDto;
+}
+
+export interface DuoDiplomaDto {
+  id: string;
+  naam: string;
+  instelling: string;
+  jaar: number;
+  beroep: string; // server-derived profession
+  policyQuestions: PolicyQuestionDto[]; // server-decided geldigheidsvragen
+}
+
+export interface ManualDiplomaPolicyDto {
+  beroepen: string[]; // professions the user may declare for a manual diploma
+  policyQuestions: PolicyQuestionDto[]; // maximal set applied to a manual diploma
+}
+
+export interface PolicyQuestionDto {
+  id: string;
+  vraag: string;
+  type: 'ja-nee' | 'tekst';
+}