The CIBG UI fidelity pass completed WP-11 (aanvragen/application-link) and WP-12 (Datablock), and reworked the upload suite to wrap vendored CIBG classes rather than mark it as a gap (WP-13's assumption corrected). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
3.9 KiB
WP-13 — CIBG-gap register + hygiene + MDX
Status: todo Phase: 2 — CIBG fidelity
Correction (CIBG UI fidelity pass,
b5c5d30): this WP assumed theupload/suite had no vendored CIBG classes and would be marked as a CIBG-gap ("Bestand-upload"). The vendored build actually ships a full upload vocabulary (.file-picker-drop-area,ul.file-list,.file-container,.file-name/.file-meta,.btn-upload,.upload-validation), so the suite was reworked to wrap those classes instead — it is no longer a gap to mark. WP-13's remaining register still covers skeleton/ spinner, rich-text-editor, wizard-shell, confirmation, card (.app-card), status-badge, placeholder-chip, etc. (Note:application-link's non-navigating.static-rowmirrors the aanvragen card surface from tokens — a small marked-gap candidate.)
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>plusparameters: { 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 overalertwith 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-chipPlus:- 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— titleFoundations/CIBG Gap Register - ADR-0003 gets a cross-link to the register
Steps
- Add the marker to each gap component +
cibgGapstory parameter. - Delete the banner; migrate its one consumer; run its former story's states through the consumer's story if coverage would drop.
- Write the MDX register: a table (component → closest CIBG concept → why) + the rule "grep the vendored CSS before hand-rolling anything".
- Optional but cheap: a
check:cibg-gapsscript that greps markers and diffs against the MDX table, so the register can't silently rot — add tocheck: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-bannergone; 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.