Files
ehoandClaude Sonnet 5 3895588b9a refactor: story titles to Domein/<Context>/<Name>; add 2 missing stories (RD-04)
Three dashboard-section stories used a fourth title segment
(`Domein/Registratie/Dashboard/<Name>`) that the sidebar rule does not have.
Drop the `Dashboard/` segment so all story titles follow the one rule from
CLAUDE.md decision 5.

Add the two missing stories for sections that have more than one visual
state: `wat-moet-ik-regelen` (4 states) and `wat-wilt-u-doen` (2 states, the
first story in the new `Domein/Overzicht/` bucket). `beheer-links` gets no
story — it has one visual state and its other branch renders nothing.

The `MetTaken` story disables the a11y addon with the same reason and WP-11
reference already used on `task-list.stories.ts` and `choice-list.stories.ts`:
`app-choice-link`'s host sits between the keuzelijst `<ul>` and its `<li>`,
a pre-existing structural gap this ticket does not fix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-04 20:56:17 +02:00

171 lines
9.6 KiB
Markdown

# RD-04 — Story titles to `Domein/<Context>/<Name>`, and the two missing stories
Status: done
Source: PLAN.md Phase 0 ("Also settle the two deviations the refactor left behind")
## Why
CLAUDE.md decision 5 sets one title rule for a component in an app context's `ui/`:
`Domein/<Context>/<Name>` — "full stop, regardless of which atomic layer it is". The three
dashboard-section stories break it. They read `Domein/Registratie/Dashboard/<Name>`, a fourth
segment that invents a sidebar folder the rule does not have. All 66 other story files comply.
RD-03 split the dashboard into two contexts but did not touch the stories. Three of the six
sections still have no story at all.
## Read first
- `apps/ssp/src/app/registratie/ui/dashboard/mijn-registratie.section.stories.ts` — the shape
to copy: a `storeStub` returning only the members the template reads, one
`applicationConfig` decorator per story, and `loading`/`success`/`failure` from
`@shared/testing/remote-data`.
- `apps/ssp/src/app/registratie/ui/dashboard/wat-moet-ik-regelen.section.ts` — needs a story.
- `apps/ssp/src/app/overzicht/ui/wat-wilt-u-doen.section.ts` — needs a story.
- `apps/ssp/src/app/registratie/domain/tasks.ts``tasksFromProfile`, which decides whether
the task list renders full or empty.
- CLAUDE.md decision 5, the paragraph starting "Story titles mirror the sidebar's".
## Decisions (pre-made, don't relitigate)
1. **Retitle the three existing stories. Drop the `Dashboard/` segment only.**
| File | From | To |
| ----------------------------------------------- | ----------------------------------------------- | ------------------------------------- |
| `dashboard/mijn-aanvragen.section.stories.ts` | `Domein/Registratie/Dashboard/Mijn Aanvragen` | `Domein/Registratie/Mijn Aanvragen` |
| `dashboard/mijn-registratie.section.stories.ts` | `Domein/Registratie/Dashboard/Mijn Registratie` | `Domein/Registratie/Mijn Registratie` |
| `dashboard/specialismen.section.stories.ts` | `Domein/Registratie/Dashboard/Specialismen` | `Domein/Registratie/Specialismen` |
The files stay where they are. RD-03 decision 3 keeps the four data sections in
`registratie/ui/dashboard/`; the folder is not the title.
2. **Add exactly two story files, not three.** PLAN's rule is "add one only where the section
has more than one visual state".
- `wat-moet-ik-regelen.section.stories.ts`, titled `Domein/Registratie/Wat Moet Ik Regelen`
— four states.
- `wat-wilt-u-doen.section.stories.ts`, titled `Domein/Overzicht/Wat Wilt U Doen` — two
states. This creates the `Domein/Overzicht/` sidebar bucket; it is the first story in
that context.
3. **`beheer-links.section.ts` gets no story.** It has one visual state. Its other branch
renders nothing at all — `@if (adminLinks().length)` wraps the whole template — and a story
whose canvas is blank documents nothing and gives the a11y addon nothing to check. The
capability filter it applies (`AccessStore.can`) is already covered where it can actually be
asserted, in the application layer. Do not add the file.
4. **`wat-moet-ik-regelen` gets four stories**, from a stub with the four members its template
and class read — `profile()`, `decisions()`, `pendingHerregistratie()`, `reloadProfile()`:
| Story | `profile()` | `decisions()` | `pendingHerregistratie()` | Renders |
| ----------------- | ------------ | ----------------------------------------------- | ------------------------- | ------------------------------ |
| `Loading` | `loading()` | `loading()` | `false` | two skeleton bars |
| `MetTaken` | `success(p)` | `success({ eligibleForHerregistratie: true })` | `false` | the task list, one task |
| `NietsOpenstaand` | `success(p)` | `success({ eligibleForHerregistratie: false })` | `false` | the "niets openstaan" text |
| `InBehandeling` | `success(p)` | `success({ eligibleForHerregistratie: false })` | `true` | the info alert above the above |
`Failed` is deliberately absent — `<app-async>`'s failure template is already exercised by
`Mijn Registratie`'s `Failed` story, and this section adds nothing to it.
5. **The task count follows from `tasksFromProfile`, so pick the profile deliberately.** With
`status.tag === 'Geregistreerd'`, the list is empty unless `eligibleForHerregistratie` is
true. That is what separates `MetTaken` from `NietsOpenstaand` — the eligibility flag, not
the profile. Reuse the `profile` fixture from `mijn-registratie.section.stories.ts`
verbatim (copy it; do not export it from the other story file and import it — story files
in this repo are self-contained).
6. **`wat-wilt-u-doen` gets two stories**, from a `FeatureFlagStore` stub whose only member is
`enabled`:
| Story | stub | Renders |
| ------------------- | -------------------------- | -------------------------------- |
| `InschrijvingOpen` | `{ enabled: () => true }` | six actions, "Inschrijven" first |
| `InschrijvingDicht` | `{ enabled: () => false }` | five actions, no "Inschrijven" |
7. **`libs/beheer`'s title stays wrong here.** `Domein/Beheer/Stamdata Table Editor` is a
different deviation with a different verdict (the doc changes, not the code). RD-28 owns it.
Do not touch it.
## Files
- `apps/ssp/src/app/registratie/ui/dashboard/mijn-aanvragen.section.stories.ts` (title only)
- `apps/ssp/src/app/registratie/ui/dashboard/mijn-registratie.section.stories.ts` (title only)
- `apps/ssp/src/app/registratie/ui/dashboard/specialismen.section.stories.ts` (title only)
- `apps/ssp/src/app/registratie/ui/dashboard/wat-moet-ik-regelen.section.stories.ts` (new)
- `apps/ssp/src/app/overzicht/ui/wat-wilt-u-doen.section.stories.ts` (new)
## Steps
1. Retitle the three files per decision 1. Nothing else in those files changes.
2. Write `wat-moet-ik-regelen.section.stories.ts` per decisions 4 and 5.
3. Write `wat-wilt-u-doen.section.stories.ts` per decision 6.
4. `git add` all five files, then run the acceptance commands.
5. Update this ticket's `Status:` to `done` and the README's RD-04 row to `done`.
6. Commit all of it together.
## Acceptance criteria
Dry-run against the tree before handover; the "is" numbers are measured, not estimated.
**Run these after `git add`.** `git grep` and `git ls-files` read tracked files, so a new
story file that is not yet staged does not exist as far as they are concerned.
```bash
git grep -l "Domein/Registratie/Dashboard" -- apps | wc -l # is 3 -> MUST be 0
git grep -h "title: 'Domein" -- '*.stories.ts' | grep -c "Domein/[^/]*/[^/]*/" # is 3 -> MUST be 0
git ls-files '*.stories.ts' | wc -l # is 69 -> MUST be 71
```
The second command counts title lines with a fourth path segment. It is the general form of
the rule, so it also catches a retitle that invents a different extra segment.
The two new stories exist, with the exact titles from decisions 2, 4 and 6:
```bash
git grep -c "title: 'Domein/Registratie/Wat Moet Ik Regelen'" -- apps/ssp/src/app/registratie/ui/dashboard/wat-moet-ik-regelen.section.stories.ts # MUST be 1
git grep -c "title: 'Domein/Overzicht/Wat Wilt U Doen'" -- apps/ssp/src/app/overzicht/ui/wat-wilt-u-doen.section.stories.ts # MUST be 1
```
`beheer-links` still has no story (decision 3):
```bash
git ls-files 'apps/ssp/src/app/overzicht/ui/beheer-links.section.stories.ts' | wc -l # MUST be 0
```
```bash
npm run ci --full # exits 0
```
## Verification
**`--full` is required.** This ticket adds two story files, and `npm run ci` does not build
Storybook. A story that fails to compile, or a decorator with a missing provider, is invisible
until the storybook-a11y job runs. Run `npm run ci --full`, not `npm run ci`.
Verified for you: `layers.mdx` deep-links exactly two story ids —
`design-system-molecules-application-link--navigatie` and
`domein-registratie-aanvraag-block--concept`. Neither is a dashboard section, so the three
retitles break no link. Do not add a new deep link.
## Out of scope
- Moving any story file. The four data sections stay in `registratie/ui/dashboard/`
(RD-03 decision 3).
- A story for `beheer-links.section.ts` (decision 3).
- `libs/beheer`'s `Domein/Beheer/…` title (decision 7, RD-28 owns it).
- The dashboard's 8 imports. PLAN settled this: accept, do not fix.
- Renaming the `dashboard/` folder. The name is stale now that the page lives in `overzicht`,
but no rule requires the folder to match a title, and the rename would touch every import.
## Risks
- **A story title is a URL.** Storybook derives the story id from the title, so a retitle
changes the id. Verified above that nothing links to these three; do not extend the retitle
to a story outside the table without re-checking.
- **`success(...)` needs the decisions shape, not a boolean.** `store.decisions()` is a
`RemoteData<Err, HerregistratieDecisions>`. The stub returns
`success({ eligibleForHerregistratie: true })`, not `success(true)`.
- **The stub must cover every member the class reads, not only the template.**
`WatMoetIkRegelenSection` reads `decisions()` in a `computed`, which the template never
names. A stub missing it throws at render time, and only `--full` catches that.
- **Do not import a fixture across story files** (decision 5). Copy it.