Files
atomic-design-poc/docs/project/archive/backlog/WP-44-context-generator.md
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

2.7 KiB

WP-44 — gen:context generator

Status: done Phase: 8 — platform/DX/showcase Priority: P3 Depends on: WP-38, WP-43

Outcome

npm run gen:context (plop, extends WP-43's plopfile.mjs) prompts for a lowercase context name and emits: src/app/<ctx>/{domain,application,infrastructure,contracts}/.gitkeep + a starter ui/<ctx>.page.ts (a PageShellComponent wrapper — replace with the real first feature slice); the @<ctx>/* tsconfig alias; one new key in .dependency-cruiser.js's CONTEXT_ALLOWED map; and a lazy, authGuard-gated route in app.routes.ts inserted before the catch-all.

Refactored .dependency-cruiser.js to make "one config entry" literally true. The pre-WP file hand-duplicated each context's forbidden-imports list as a separate contextRule(name, from, forbidden) call — adding a context meant editing N existing calls to add it to their forbidden list, not adding one entry. Replaced with a single CONTEXT_ALLOWED map (context → contexts it may additionally import) that every rule + the FEATURES string is derived from; showcase maps to null (unrestricted — the one exempt case) and is skipped when generating rules. Verified behavior-preserving: npm run dep:check reports the same module/dependency counts before and after, npm run dep:graph's committed output is byte-identical, and a planted cross-context violation (auth importing @herregistratie, type-only) is still caught under the new auth-scope rule name.

Smoke-tested by generating a real vergunning context end-to-end (dep:check, lint, build all green, including the new lazy chunk), then removed the demo output. .claude/skills/new-context/ SKILL.md now points at the generator as step 1.

Why

Adding a bounded context is currently a manual multi-file edit (folders + tsconfig alias + copied ESLint boundary block + lazy route) — the new-context skill's most error-prone steps. Mechanise it.

Decisions

  • gen:context (same tool as WP-43) emits {domain,application,infrastructure,ui,contracts} folders + the @ctx/* tsconfig path alias + a lazy route + the boundary entry.
  • Simpler because of WP-38: boundaries are declarative by then, so the generator adds one config entry instead of hand-copying ESLint blocks.
  • Replaces the manual portion of the new-context skill.

Files

  • Extend the WP-43 generator setup with a context generator + templates.
  • Wire tsconfig alias + boundary config + route insertion (idempotent edits).
  • Update .claude/skills/new-context/SKILL.md.

Acceptance criteria

  • npm run gen:context <name> produces a context that lints clean (boundaries recognised) and routes lazily.
  • Boundary tool (WP-38) validates the new context's allowed edges.
  • npm run ci green.