docs(WP-61): mark done, record the shared-backend deviation

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>

docs/project/backlog/WP-61-behandelportal-bootstrap.md

@@ -1,6 +1,6 @@
 # WP-61 — Bootstrap the behandelportal app
 
-Status: todo
+Status: done (behandelportal@6b0c6ce — separate sibling repo, not a commit in this one)
 Phase: 11 — Behandelportal
 
 ## Why
@@ -23,8 +23,29 @@ with no business context yet — an empty, correctly-scaffolded shell.
   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 for the new app (separate repo vs. a second app in this monorepo) — decide
-  at kickoff based on how `new-ssp` is meant to be invoked.
+- 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
 
@@ -42,10 +63,10 @@ workspace reference, CI config) — enumerate at kickoff by following the skill.
 
 ## Acceptance criteria
 
-- [ ] New app boots and its own `npm run ci` is green.
-- [ ] No citizen-facing business context (`registratie`, `herregistratie`, `brief`,
+- [x] New app boots and its own `npm run ci` is green.
+- [x] No citizen-facing business context (`registratie`, `herregistratie`, `brief`,
       `showcase`) present.
-- [ ] Points at the same backend (`BigRegister.Api`) as this repo, no new backend stood
+- [x] Points at the same backend (`BigRegister.Api`) as this repo, no new backend stood
       up.
 
 ## Verification