Files

T

ehoandClaude Opus 5 12f17d9d73 docs: archive the finished backlogs (RD-30)

Two backlog trees are complete: `docs/project/backlog/` (75 files, every
WP done) and `docs/project/refactor-backlog-setup/` (the arc before it).
Move both under `docs/project/archive/` with `git mv`, so history stays
intact through `git log --follow`. `SHOWCASE-ROADMAP.md` moves with them,
because it points at the now-archived backlog README.

Add `docs/project/archive/README.md`. It states that these trees are
historical and names the two directories that are still live.

Repoint every inbound reference named in RD-30's Files table: CLAUDE.md,
the root README, both backend READMEs, `LetterHtml.cs`, `a11y.mdx`, the
`document-feature` and `new-ssp` skills, and the readable-codebase PLAN,
README, and RD-19 ticket. Fix two upward-relative links inside the moved
WP files (WP-68, WP-69) that gained a directory level and would otherwise
break. Repoint `.prettierignore`'s two agent-prompt exclusions to their
new path, so prettier keeps leaving those files' exact wording alone.

Mark RD-30 done and check off its acceptance criteria; flip its README
row to done.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-08 23:00:38 +02:00

3.9 KiB

Raw Blame History

WP-61 — Bootstrap the behandelportal app

Status: done (behandelportal@6b0c6ce — separate sibling repo, not a commit in this one) Phase: 11 — Behandelportal

Why

ADR-0002 already designed the Behandelaar/backoffice as a separate sibling frontend app, not a folder in this repo. Nothing exists yet — /beheer/zaken is confirmed to be only a cross-owner list+delete, no treatment workflow. The new-ssp skill exists precisely to bootstrap a new portal from this template; this slice is running that recipe for real, with no business context yet — an empty, correctly-scaffolded shell.

Read first

.claude/skills/new-ssp/SKILL.md
ADR-0002 — user groups & bounded contexts
ADR-0001 — BFF-lite decision DTOs

Decisions (pre-made, don't relitigate)

Follow new-ssp's own "keep vs. strip" checklist as-is: keep the shared/ui kernel, tooling/CI gates, ADRs 0001-0003; strip the four citizen contexts and citizen branding.
The new app talks to the same BigRegister.Api backend — no new backend service (confirmed by ADR-0002: contexts integrate through the backend).
Repo layout: separate sibling repo at /home/eho/repos/behandelportal (fresh clone — scripts/create-frontend.mjs's own header comment says to run it inside a fresh clone, not against this repo's working tree).

Resolution (kickoff deviation from the vanilla recipe)

create-frontend.mjs unconditionally renames the backend project regardless of --skip-backend (that flag only gates the gen:api regen step) — which conflicts with "no new backend service" above. Resolved by running the script as-is (--name Behandelportal --context behandeling --skip-backend), then in the new repo: deleting backend/ entirely, vendoring its swagger.json into api-contract/swagger.json, and pointing gen:api at nswag run nswag.json against that vendored doc instead of regenerating from a live backend. Dev workflow is two terminals: BigRegister.Api runs from this repo on :5000, Behandelportal serves on :4201 via its own unchanged proxy.conf.json.

Also found and fixed by hand (real bugs in create-frontend.mjs, not specific to this WP): plop context's .dependency-cruiser.js insertion anchors on the showcase CONTEXT_ALLOWED entry, which is already stripped by the time plop context runs in the same invocation — so a freshly scaffolded context silently gets no boundary-fence entry, and dep:check passes green with the architecture guarantee simply absent. Not re-fixed in create-frontend.mjs itself this pass (out of scope here) — just compensated for by hand in the new repo.

Files

Whatever new-ssp's recipe touches (new app root, package.json, shared/ui copy or workspace reference, CI config) — enumerate at kickoff by following the skill.

Steps

Run the new-ssp bootstrap per its own checklist.
Confirm the known un-genericizable rough edges it flags (shared/ui/debug-state/, the /dashboard route) are handled per the skill's own guidance (delete / TODO stopgap) rather than re-solved from scratch.
Land an empty landing/login page only — no behandeling context yet (that's WP-64+).
Get the new app's own CI green.

Acceptance criteria

New app boots and its own npm run ci is green.
No citizen-facing business context (registratie, herregistratie, brief, showcase) present.
Points at the same backend (BigRegister.Api) as this repo, no new backend stood up.

Verification

npm run ci in the new app; manual smoke — app loads to an empty shell page.

Out of scope

Any behandeling screens (WP-64/65), identity (WP-62), status lifecycle (WP-63).

Risks

new-ssp's own docs already name its rough edges (debug-state, /dashboard) — budget time for those rather than being surprised by them.

3.9 KiB Raw Blame History