atomic-design-poc/docs/project/readable-codebase/RD-04-story-titles.md

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.

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:

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):

git ls-files 'apps/ssp/src/app/overzicht/ui/beheer-links.section.stories.ts' | wc -l   # MUST be 0

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.