ehoandClaude Sonnet 5
e4ea75414b
CI / changes (push) Successful in 7s
CI / lint (push) Successful in 56s
CI / frontend (push) Successful in 1m32s
CI / backend (push) Successful in 10s
CI / e2e (push) Successful in 2m56s
CI / semgrep (push) Successful in 1m10s
CI / storybook-a11y (push) Successful in 6m38s
CI / api-client-drift (push) Successful in 1m56s
WP-61 (bootstrap the behandelportal app) is done — a separate sibling repo at /home/eho/repos/behandelportal, not a commit in this one. Records the one real kickoff deviation from the vanilla new-ssp recipe: create-ssp.mjs unconditionally renames the backend project even with --skip-backend, which conflicts with the WP's "no new backend service" decision. Resolved by deleting backend/ from the new repo and vendoring its swagger.json into api-contract/ instead, with gen:api regenerating only the client against that vendored doc. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
84 lines
3.9 KiB
Markdown
84 lines
3.9 KiB
Markdown
# 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](../reference/architecture/0002-user-groups-and-bounded-contexts.md)
|
|
- [ADR-0001 — BFF-lite decision DTOs](../reference/architecture/0001-bff-lite-decision-dtos.md)
|
|
|
|
## 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
|
|
|
|
1. Run the `new-ssp` bootstrap per its own checklist.
|
|
2. 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.
|
|
3. Land an empty landing/login page only — no `behandeling` context yet (that's WP-64+).
|
|
4. Get the new app's own CI green.
|
|
|
|
## Acceptance criteria
|
|
|
|
- [x] New app boots and its own `npm run ci` is green.
|
|
- [x] No citizen-facing business context (`registratie`, `herregistratie`, `brief`,
|
|
`showcase`) present.
|
|
- [x] 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.
|