docs: replace SHOWCASE-ROADMAP.md with docs/backlog/ (17 WPs)
Turns the prior roadmap sketch into ordered, gated work packages (enforcement gates, FP/DDD consistency, CIBG fidelity, Storybook curriculum, a11y) from the 2026-07-02 showcase-hardening audit.
This commit is contained in:
79
docs/backlog/WP-13-cibg-gap-register.md
Normal file
79
docs/backlog/WP-13-cibg-gap-register.md
Normal file
@@ -0,0 +1,79 @@
|
||||
# WP-13 — CIBG-gap register + hygiene + MDX
|
||||
|
||||
Status: todo
|
||||
Phase: 2 — CIBG fidelity
|
||||
|
||||
## Why
|
||||
|
||||
User decision: hand-rolled token-bridge components are allowed **only if explicitly
|
||||
marked** as CIBG-gap extensions in code + Storybook, so every deviation from the design
|
||||
system is auditable. Plus two hygiene items from the audit: a dead wrapper to delete and
|
||||
the list-family rationale to document.
|
||||
|
||||
## Read first
|
||||
|
||||
- `docs/architecture/0003-*.md` (ADR-0003 — the token-bridge rationale this extends)
|
||||
- The audit's gap list (below)
|
||||
|
||||
## Decisions (pre-made, don't relitigate)
|
||||
|
||||
- Marker format (header comment in the component):
|
||||
`// CIBG-GAP EXTENSION: <closest CIBG concept> — <why hand-rolled>` plus
|
||||
`parameters: { cibgGap: true }` and a "CIBG-gap extension" line in the story
|
||||
description.
|
||||
- **Keep all three list families** — each maps a distinct CIBG pattern: `task-list` →
|
||||
Actieblok, `application-list` → Aanvragen, `choice-list` → Keuzelijst. Header comment
|
||||
in each names its pattern. Consolidation would blur exactly the design-system mapping
|
||||
this showcase demonstrates.
|
||||
- **Delete `upload-status-banner`** (`shared/ui/upload/upload-status-banner/`): a
|
||||
23-line near-identity wrapper over `alert` with one consumer — inline `<app-alert>`
|
||||
there.
|
||||
|
||||
## Files
|
||||
|
||||
Components to mark (closest CIBG concept in parens):
|
||||
- `skeleton`, `spinner` (Laadindicatie — no vendored class, verified)
|
||||
- `upload/` suite (Bestand-upload)
|
||||
- `rich-text-editor` (Tekstgebied)
|
||||
- `wizard-shell` (Wizard; error summary → Foutmelding, if WP-11 marked it)
|
||||
- `confirmation` (Bevestiging — verify: it wraps vendored classes; if so it needs no
|
||||
marker, only the pattern comment)
|
||||
- `debug-state` (devtool, no CIBG concept)
|
||||
- `status-badge` (deliberate custom, documented in code), `card` (`.app-card`),
|
||||
`placeholder-chip`
|
||||
Plus:
|
||||
- Delete `upload-status-banner` + its story; inline alert at its consumer
|
||||
- Header comments on `task-list`/`application-list`/`choice-list`
|
||||
- New `src/docs/cibg-gaps.mdx` — title `Foundations/CIBG Gap Register`
|
||||
- ADR-0003 gets a cross-link to the register
|
||||
|
||||
## Steps
|
||||
|
||||
1. Add the marker to each gap component + `cibgGap` story parameter.
|
||||
2. Delete the banner; migrate its one consumer; run its former story's states through
|
||||
the consumer's story if coverage would drop.
|
||||
3. Write the MDX register: a table (component → closest CIBG concept → why) + the rule
|
||||
"grep the vendored CSS before hand-rolling anything".
|
||||
4. Optional but cheap: a `check:cibg-gaps` script that greps markers and diffs against
|
||||
the MDX table, so the register can't silently rot — add to `check:tokens`' CI step if
|
||||
trivial, else note as skipped.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- [ ] Every component with hand-rolled surface CSS either wraps vendored classes or
|
||||
carries the marker (spot-check with a grep for `styles: [` vs markers).
|
||||
- [ ] Register MDX complete, linked from ADR-0003.
|
||||
- [ ] `upload-status-banner` gone; consumer green; no story coverage lost.
|
||||
- [ ] List trio documented.
|
||||
|
||||
## Verification
|
||||
|
||||
GREEN + `npm run test-storybook:ci`.
|
||||
|
||||
## Out of scope
|
||||
|
||||
Rebuilding any gap component against the design system (they're sanctioned by decision).
|
||||
|
||||
## Risks
|
||||
|
||||
Low — mostly annotation; the deletion is the only behavior-touching change.
|
||||
Reference in New Issue
Block a user