What are the Consumer design system's first slices?

Question

What are the design system's first slices?

Source: Figma 2.02 - DXP Design System (New), node 84-8503
(https://www.figma.com/design/yCLWgCel1UcW7oToDge2fT/2.02---DXP-Design-System--New-?node-id=84-8503&m=dev).

Decide the first tracer-bullet slices the DLC will actually build in DXP-DesignSystem — narrow
vertical paths, each demoable alone, each fitting one fresh context window. The client is waiting, so
the first slice should produce something visible rather than infrastructure.

Grill it. What is the thinnest slice that puts a real token or a real component from that Figma page
into the repo and renders it? What has to exist before it — and is that a prefactor, or is it
scaffolding pretending to be a slice?

Acceptance criteria

The first slices are named, ordered, and each states the behaviour it makes work.
Each slice is a vertical path, not a layer, and each is demoable on its own.
The blocking edges between them are stated.
The slices become Azure DevOps work items in the Consumer's Azure DevOps project, never GitHub issues in
this repo.

Stale since 2026-08-23. Superseded by the newest "How to start this session" comment below — the newest opener is authoritative (#373 body). Kept for the record.

How to start this session

Produces: the first slices, ordered, with their blocking edges. A conversation, not a publish.

Run /wayfinder 373 #377. It claims this ticket.
Open the Figma node in dev mode and read it before asking anything:
https://www.figma.com/design/yCLWgCel1UcW7oToDge2fT/2.02---DXP-Design-System--New-?node-id=84-8503&m=dev
If Figma conventions for agents, from Confluence PRISM 840073301 #378 has landed, read its findings first — the conventions change what a slice looks like.
Invoke /grilling and /domain-modeling.
If the conversation turns on "how should it look" or "how should it behave", invoke /prototype and
build something rough to react to.
Record the slices in the resolution comment: ordered, each with the behaviour it makes work, each
with its blocking edges.

Traps

A slice is vertical, demoable on its own, and fits one fresh context window.
The client wants something visible. Scaffolding is not a slice; if something must exist first, it is
a prefactor and it says so.
Do not publish anything to Azure DevOps here. Land a rendering component on develop, so the client sees the walk's output #379 publishes, through /tickets.

The Figma research is in — read it before choosing slices

#378 is closed. Findings file: docs/research/figma-conventions-for-agents.md in DXP-DesignSystem, merged as d177e6f.

Four things in it bear directly on this ticket.

The first slice is already chosen, on business grounds. The maintainer picked card-profile-main — page 🟡 profile-card in 2.02 - DXP Design System (New) — because it carries high business value and because the team poured its own convention research into that page. That outranks the technical ranking below.

But it is not dependency-free. From the published graph:

card-profile-main  (189:5266)
└── badge-main     (181:3820)   internal dependency

So badge-main ships first, or the card ships with it stubbed. Button is not a dependency of the card — it feeds header profile services.

The technical ranking, for whatever ordering still needs deciding. Ten published components on ten pages, plus a tryouts page publishing ten more with duplicate names.

Candidate	Deps	Instances	Note
`Button`	none	42	the only PascalCase name in the file, and the only component exercising every property type
`user` (avatar)	none	0	the file's one `🟢` page
`badge-main`	none	8	the card's dependency
`card-profile-main`	`badge-main`	5	the chosen first slice

Defects to settle before or during the first slice, since they break exact-match mapping: secundary in Button.variants against secondary in button-round.variant; larg-ultra in side-navigation.responsive against large-ultra in layout-profile-services; the same axis named variants on one component and variant on two others; and no component anywhere has a focus variant, which keyboard users get regardless.

Two decisions gate slice quality rather than slice choice. #403 — how three-or-more variant dimensions are represented, which bites on Button and not on the two-axis card — and #405 — what counts as design intent, which binds on the first build because the card uses icons. Neither blocks this ticket.

How to start this session

Posted 2026-08-23 at dispatch. Supersedes the 2026-08-14 opener above — marked stale in place.

Produces: the first slices, named, ordered, with blocking edges — a conversation with the
maintainer, not a publish. Invoke /grilling and /domain-modeling; /prototype if the talk
turns to "how should it look". Do not invoke /implement (routes to /tdd; decisions 3 and 11
deleted the tests).

Read order

This ticket's body, then the comment below it from the Figma conventions for agents, from Confluence PRISM 840073301 #378 session
(What are the Consumer design system's first slices? #377 (comment)) — it
supersedes parts of the body's framing.
The findings file, merged: docs/research/figma-conventions-for-agents.md in
the Consumer's clone (d177e6f, !5783). The conventions come from Confluence PRISM
852591905 (https://uniccom.atlassian.net/wiki/spaces/PRISM/pages/852591905), NOT the page the
body names — that one is empty of conventions.
The Figma DS file in dev mode, node 84-8503
(https://www.figma.com/design/yCLWgCel1UcW7oToDge2fT/2.02---DXP-Design-System--New-?node-id=84-8503&m=dev).
This file reads fine; only Global Tokens and Assets refuse (edit access pending, Get edit access to the Global Tokens and Assets Figma files #406
(Get edit access to the Global Tokens and Assets Figma files #406)) — do not diagnose a refusal there
as your error, and do not wait on it: slicing needs the DS file only.

The one trap

The first slice is already chosen. The maintainer picked card-profile-main on business
grounds, and it depends on badge-main — so badge ships first or stubbed. Do not re-open slice
one; grill the order and edges of what follows. Button is not in card-profile-main's chain.

The decision the ticket does not make

How badge-main ships: as slice zero in its own right, or stubbed inside card-profile-main's
slice. Two competent implementers split here. Settle it in the grilling and record which.

Other traps

Ten published components on ten pages — plus a tryouts page publishing ten more with
duplicate names. Count nothing from tryouts.
The Consumer repo is scaffold, not evidence: the token files are Tailwind stock from the
create-turbo commit, and CLAUDE.md's Tokens Studio claim is false. Design files are the
source of truth for tokens.
A slice is vertical, demoable alone, and fits one fresh context window. Scaffolding that must
exist first is a prefactor and says so.
Do not publish to Azure DevOps here. Land a rendering component on develop, so the client sees the walk's output #379 publishes, through /tickets. The slices' ADO shape
(work items in the Consumer's Azure DevOps project) is Land a rendering component on develop, so the client sees the walk's output #379's job.
Icon-bearing slices touch the Assets file, which waits on Get edit access to the Global Tokens and Assets Figma files #406 — note the dependency on the
slice rather than blocking the grilling.

The bar that proves it

Each slice states the behaviour it makes work and its blocking edges, recorded in the resolution
comment. A false pass: a layer list (tokens, then primitives, then components) dressed as slices —
that is horizontal, and the client sees nothing until layer three.

Report back

BEFORE YOU FINISH, AND WHENEVER YOU LEARN SOMETHING THAT WOULD HAVE CHANGED THIS PROMPT,
SendMessage to wayfinder-orchestrator with four things and nothing else: what you expected,
what happened, the command or file that proved it, and whether it changes only this ticket or
every session in this repo. Send it when you learn it, not only at the end.

Resolution — one prefactor and six slices

Grilled with the maintainer on 2026-08-23, over five rounds, against the live Figma file and
origin/develop of DXP-DesignSystem.
Nothing here is published to Azure DevOps —
#379 does that, through /tickets.

The stack changed the answer. The maintainer named it during the grilling: the design system is
built on shadcn + Base UI + Tailwind. Nothing in the repository says so — no components.json,
no cn(), no clsx, no tailwind-merge, no class-variance-authority, and no mention of shadcn,
Base UI or Radix in any file on develop. Three of the prefactor's six items were invisible until
that was said out loud.

The list

P    prefactor — make the repository able to hold a component
S1   the card renders, with its three states          ← P
S2   the badge renders                                ← P
S3   the card carries a badge                         ← S1, S2
S4   Figma maps to code                               ← S3
S5   visual regressions are caught                    ← S3
S6   the card is responsive                           ← blocked on a decision, not on effort

S1 and S2 both depend on P alone, so they run in parallel.

P — prefactor: make the repository able to hold a component

Not a slice. Nothing renders after it, and calling it one would be the false pass this ticket
warns about. Six items, all of them mechanical:

Delete packages/ui-react/src/{button,card,gradient,turborepo-logo}.tsx. They are create-turbo
stock, and card.tsx collides by name with what S1 builds.
Empty packages/design-tokens/tokens/. The four files there are stock Tailwind — #3b82f6 is
Tailwind blue-500 — and they read as this design system's tokens.
Run shadcn init. It adds components.json, cn(), clsx, tailwind-merge and
class-variance-authority.
Settle the Tailwind prefix. packages/ui-react/src/styles.css reads
@import "tailwindcss" prefix(ui);, and shadcn add emits unprefixed classes. Either drop the
prefix or configure shadcn for it. This grilling did not decide which.
Widen the Storybook stories glob. It reads ../src/** only, so a component in
packages/ui-react/ cannot carry its own story today.
Write the stack down in README.md and CLAUDE.md. Add a test task to turbo.json and a root
test script — neither exists, so pnpm test does nothing at the root today.

Blocked by: nothing. Blocks: S1, S2.

S1 — the card renders, with its three states

Behaviour it makes work. A page shows a profile card carrying a title, a lead and slot content.
The card renders in default, hover and disabled. The disabled card carries
aria-disabled="true".

What ships. packages/ui-react/src/card-profile-main/, exporting Card, CardHeader,
CardTitle, CardDescription and CardContent from shadcn's Base UI card, restyled to the fourteen
variables bound on Figma node 189:5267. Two stories: content-then-header (Figma variant=default)
and header-then-content (Figma variant=progress).

Blocked by: P. Blocks: S3, S4, S5.

S2 — the badge renders

Behaviour it makes work. A page shows a badge in both drawn forms: the pill carrying an icon and
text (variant=security-setup), and the icon-only chip (variant=icon).

What ships. packages/ui-react/src/badge-main/, taking its icon as a child. The slice ships
icon/interface/User2 as one inline SVG, exported from the design system file. Tokens: the twelve
variables bound on node 181:3820.

Blocked by: P. Blocks: S3.

S3 — the card carries a badge

Behaviour it makes work. A profile card shows a badge or an icon chip in its top-right corner, in
all three states.

What ships. CardAction, wired to accept a badge. Two stories: Figma variant=has badge and
variant=has icon. This slice completes all twelve drawn combinations.

Blocked by: S1, S2. Blocks: S4, S5.

S4 — Figma maps to code

Behaviour it makes work. Opening card-profile-main in Figma Dev Mode shows the React component
that implements it.

What ships. Code Connect mappings for the card and the badge. get_code_connect_map(189:5266)
returns {} today, so this is the first write to Figma from this repository, and writing is
untested. The mapping is harder than usual here: the Figma variant axis maps onto a composition of
parts rather than onto a prop, so a variant maps to a subtree.

Blocked by: S3 — map a finished component, not one that changes twice more.

S5 — visual regressions are caught

Behaviour it makes work. A change to a token or to a shared part shows as a visual diff before it
merges.

Blocked by: S3, and by six things that do not exist. See What Chromatic needs below.

S6 — the card is responsive

Behaviour it makes work. The card scales across the four viewports the file names — micro,
small, large, ultra.

Blocked by a decision, not by effort. No page states a breakpoint in pixels, and three counts are
on record: Changes in the Design System
says Figma is going from 7 to 4 and marks the row open,
Definition of Ready/Done gates on 6,
and Design Principles says
typography scales continuously with no hard breakpoints. The card's own variant frames bind
spacing/default/S = 16; the four viewport instances scale to 19.9, 21.5 and 24, which are not
tokens. S1 ships the token-bound size, because it is the only padding on record that someone chose.

The bar every slice meets

Four checks, and Chromatic is not among them until S5:

The story renders in Storybook.
A vitest browser test asserts the one thing that can break — that the parts render the text they
are given, in the order the composition puts them. For S1: the title and the lead render, the
lead follows the title in the DOM, and disabled sets aria-disabled="true". Do not assert
Tailwind classes or token values.
A DOM snapshot per story. shadcn copies component source into the repository, so adapting a shared
part is editing a file two directories away with no version bump to warn anyone. Snapshots start
being load-bearing at S2, so the baseline exists from S1.
The a11y addon reports clean.

The decisions this ticket took

1. A slice is a cut through a component set, not the whole set. Treating one Figma component set
as one slice makes it a layer wearing a slice's name, and it would have blocked the card on an access
ticket with no date.

2. badge-main ships as a slice of its own — the question the opener named as undecided. It is
not stubbed inside the card, and it is not a prefactor. Two of the card's four drawn variants need
it, and two do not, so the card starts without it and gains it at S3.

3. Tokens ride in with the component that binds them. S1 writes the fourteen variables its own
node binds, read from get_variable_defs. Landing the token set first would be the layer trap, and
it would wait on #406.

4. The Figma variant axis maps onto composition, not onto a prop. None of the four values is a
style variant:

Figma card-profile-main            shadcn Card
  title card      (TEXT)       →   CardTitle
  lead card       (TEXT)       →   CardDescription
  content slot    (SLOT)       →   CardContent
  badge, top-right             →   CardAction
  variant=default              →   CardContent, then CardHeader
  variant=progress             →   CardHeader, then CardContent
  variant=has icon             →   CardAction holding badge variant=icon
  variant=has badge            →   CardAction holding badge variant=security-setup
  state=default|hover|disabled →   the only real style axis

This is what collapsed the four card slices to two. It is also a decision that is hard to reverse and
surprising without the reason, so it wants an ADR — see What this did not decide, item 6.

5. The card is not an interactive element. It renders as a plain container. hover is decoration
and disabled is a look carrying aria-disabled. The consumer decides what is clickable, through
composition and inversion of control — sometimes a router link, sometimes a modal trigger. Base UI's
render prop is that mechanism where a headless primitive exists; shadcn's Card has none, so the
parts are plain elements and the consumer wraps them.

6. No focus style ships, in any slice. The maintainer will ask UX. State the consequence plainly:
if anything makes the card clickable, keyboard users get no visible focus ring, and the a11y addon
does not report a missing focus style.

7. The React export is CardProfileMain, provisionally. The directory is card-profile-main, so
the Figma name is exact where the exact-match rule does real work. The two Confluence rules cannot
both hold — card-profile-main is not PascalCase — and only the naming page's author can settle
whether the old rules were retired or dropped.

8. Code Connect and Chromatic are slices, not parts of S1. Both need something that does not
exist yet: a write to Figma that has never been tried, and a CI pipeline that has never existed.

What Chromatic needs

Asked for at the end of the grilling. @chromatic-com/storybook 5.2.1 is installed and registered in
.storybook/main.ts; that is the addon, not the runner. Six things are missing:

A Chromatic account and a project for DXP-DesignSystem, which issues the project token.
chromatic as a devDependency, plus a script. The addon does not upload; the CLI does.
A CI pipeline, which does not exist. No azure-pipelines.yml on develop, and none of the 49
pipelines in the Consumer's Azure DevOps project targets this repository. Without CI, Chromatic is a command
someone remembers to run.
The project token as a pipeline secret, once a pipeline exists.
A named approver. Every diff waits for a person, and nobody is named today.
A baseline branch. develop is the default branch here, so accepted baselines live there and
feature branches diff against it.

Items 1, 4 and 5 need a human with an account and a budget. Item 3 is the largest and it is not
Chromatic work — it is the repository having no automated checks at all, which also means the bar
above runs only on a developer's machine until someone builds it.

Corrections to this ticket's opener

badge-main is not blocked by #406.
download_assets on the badge's icon/interface/User2 instance (181:3848) returned two SVGs from
the design system file, with no Assets-file access. Instance-level SVG export works. Get edit access to the Global Tokens and Assets Figma files #406 matters
for browsing the icon library, not for exporting an icon a component already uses. So the whole
card finishes without waiting on access.
#405 does not bind on the first build.
The opener says it does, because the card uses icons. Under decision 1 the first slice has no icons;
the question arrives at S2.
The card page does carry Viewport Mappings. The #378 research
found none of the Guidelines' five section names on the page. The section is there, spelled
Viewport Mappings against the documentation's Viewports Mapping, and it names four viewports.

Vocabulary

Four terms this map now uses precisely. DXP-DesignSystem has no CONTEXT.md and no docs/adr/, so
they live here until one exists.

Term	Means
Slice	A vertical path that renders something. Demoable on its own, and it fits one fresh context window.
Prefactor	A change that must land first and demos nothing. Never a slice, and it says so.
Part	One of shadcn's card elements — `CardHeader`, `CardTitle`, `CardContent`, `CardAction`. Figma's nearest word is a slot.
Variant	In Figma, a property on a component set. In this repository only `state` survives as a style variant; every other Figma variant axis is a composition of parts.

What this did not decide

Whether PascalCase or the exact Figma name wins across the repository. CardProfileMain is
provisional. Only the naming page's author can say whether the four old rules were retired or
dropped.
Whether the card is ever a click target, and what its focus style is. One message to UX
carrying both questions, not two.
The Tailwind prefix. P must settle it; this grilling did not.
Breakpoint values. S6's blocker.
Which shadcn track components with a headless primitive use. The card needs none, so the
question is untouched — and it bites on the first component that does, which is Button.
Whether decision 4 becomes an ADR in the Consumer. It is hard to reverse, surprising without
the reason, and the result of a real trade-off, so it qualifies. docs/adr/ does not exist in
DXP-DesignSystem yet, so creating it is part of the cost.

Addendum — the planned usage corrects three of the decisions above

The maintainer pointed at where the card is planned to go:
1.00 - DXP Digital Experience Platform,
page 🟡 Profile Service 2.0. Read 2026-08-23. The slice chain is unchanged — P → {S1, S2} →
S3 — but three decisions above are now wrong, and one milestone moves.

1. The card is a modal trigger. Decision 5 is amended.

The maintainer confirmed it: the card sometimes opens a modal, sometimes navigates. The page carries
16 icon/interface/close instances, which is what a screen full of modals looks like.

So the card is interactive, and "the consumer decides" needs a mechanism rather than a hope.
shadcn's Card is a plain div taking className; it ships no asChild and no render prop.
S1 must add that escape hatch deliberately, so the consumer can make the root a <button> or a
router link without reaching inside. Everything else in decision 5 stands: the parts stay
presentational and the card itself chooses nothing.

2. Every planned card has an icon, and every icon is different.

The Personal data screen shows a 2×2 grid, and all four cards carry an icon chip — a person, an
envelope, a car, a staff-ID card. Two consequences:

S1 is not the client-facing milestone. S3 is. variant=default — a card with no icon —
appears nowhere in the planned product. S1 still earns its place as the base every variant builds
on, but nobody should demo it as "the card is done".
S2 ships one icon; S3 needs at least four. Q19 chose to give the badge its icon as a child
and inline one SVG. That still holds — four inline SVGs is four files, and no pipeline. But the
trigger for an icon package is now visible and close: Button, button-round and
sidenavigation-link all carry icon instance-swaps too. Build the package when the second
component needs icons, not before, and revisit once
#406 makes the library readable.

3. No focus is a defect at `S3`, not a theoretical gap.

A card that opens a modal and shows no focus ring is unusable by keyboard. S1 can ship without one
because nothing there is clickable yet. S3 cannot. UX was asked on 2026-08-23 and an answer is
expected on 2026-08-24, which is in time.

4. The usage page has not moved to the new component.

Its instances are named profile/card and measure 444×160. The component this ticket slices is
card-profile-main and measures 356×161. profile/card is the name carried by the design system
file's tryouts page and by the old non-(New) library.

So the design of record for Profile Services still points at the old card. Either the page is stale
or the new component has not been adopted there. This needs the designer, and it changes what
"done" means for the card: matching card-profile-main will not match the screen anyone reviews.

5. CI is plannable after all.

DXP-DesignSystem still has none, but DXP-Website and DXP-ProfileServices both run Azure
Pipelines in the same project, so the pattern exists and the maintainer can plan one. That downgrades
S5's largest blocker from "does not exist anywhere" to "not built here yet".

Correction — prefactor item 5 was wrong

CLAUDE.md on origin/develop already states the convention: "Stories live in apps/storybook-react/src/stories/, import components from @repo/ui-react (the built package, not source paths)." That is deliberate, not an oversight.

So prefactor item 5 — widen the Storybook stories glob — is deleted. No glob change is needed. The component lives in packages/ui-react/src/card-profile-main/; its story lives in apps/storybook-react/src/stories/ and imports the built package. Q10's directory-per-component answer stands for the component; the story does not move in with it.

Two more facts from the same file that make the bar cheaper than stated:

The a11y check is already a gate, not a report. test: 'error' fails a story on any axe violation, so bar item 4 runs inside the vitest run rather than beside it.
Story tags decide what vitest runs. test includes a story; skip-test, experimental and manual exclude it. Every slice's stories need the test tag or the bar silently passes on nothing.

Prefactor item 6 stands unchanged: there is no test task in turbo.json and no root test script, so pnpm test at the root still does nothing.

The stack decisions are now recorded in the Consumer

Work item 42954 · pull request !5786 → develop, one commit, documentation only.

File	Change
`CLAUDE.md`	new § Components — the stack, how to add a component, where the files go, and the bar before merge
`README.md`	the stack in the intro, and a `docs/adr/` row in the directory map
`docs/adr/0001-figma-variant-axes-map-to-composition.md`	new — the composition rule with its two rejected alternatives

No component, no shadcn init, and the create-turbo scaffold is untouched. Those stay with the prefactor and #379.

One ADR is deliberately absent: why shadcn was chosen over a component library. That decision was taken outside this session and the reasoning is not mine to write. It qualifies for an ADR on all three tests — hard to reverse, surprising without context, a real trade-off — so it wants docs/adr/0002 once the maintainer supplies the why.

ADR-0002 exists now. The maintainer supplied the why, so the gap named in the comment above is closed — docs/adr/0002-shadcn-on-the-base-ui-track.md, same PR, second commit.

shadcn because it is the industry standard, and because Tailwind and shadcn are heavily represented in model training data — this design system is built with agents on the AFK legs, so a generated component needing less correction is a delivery property, not a preference.

Base UI rather than Radix because Radix's development slowed. The reason checked out, and the measurement is sharper than the claim: no radix-ui publish between 2026-01 and 2026-04, then a resumed release-candidate train, with 1.7.0 still RC-only against @base-ui/react 1.7.0 stable on 2026-08-04. Both projects are alive; one stopped and started again. Recorded in the ADR as a dated measurement, to be re-measured rather than trusted.

One trap found while measuring: the package was renamed. @base-ui-components/react is the old name and has not shipped since 2025-12, so installing it gets a stale release candidate. The live package is @base-ui/react. Named in both CLAUDE.md and the ADR.

Merged

!5786 completed as 371336e on develop, noFastForward. Work item 42954 is Resolved.

The stack is now written where an agent reads it: CLAUDE.md § Components, the intro of README.md, and docs/adr/{0001-figma-variant-axes-map-to-composition,0002-shadcn-on-the-base-ui-track}.md. docs/adr/ did not exist in the Consumer before this.

unic-dlc-pr-review ran twice against it, and the second run is the one that counts:

	crit	imp	minor	reconcile
Iteration 1	2	5	3	—
Iteration 2	0	0	2	10 fixed · 0 still present · 0 regressed · 2 new

Twelve threads, all fixed. Reconcile verified the ten against the diff rather than against my replies, so no resolved thread was standing on a fix that had not landed.

Both critical findings were this diff's own prose, and neither was reachable by reading it again myself. A future state written in the present tense, twice — "every story carries a DOM snapshot" when no snapshot exists, and ADR-0001 calling card-profile-main "the first component built here". And a shadcn add instruction placed ten lines after the prefix(ui) rule it collides with, when comment 3 above had already recorded that decision as open.

The one real correctness defect came in iteration 2: the file-layout table sent components to a nested directory with no stated route to the package's public API, and src/index.ts carries a false // Auto-generated barrel export header. I corrected half of that finding — the root import does work through the barrel; the subpath export is what cannot reach a nested path.

Two Box-level facts for the plugin, neither ours to fix here. reconcile failed once on Archon #1067 — subprocess produced no output within 60s — and recovered on retry 1 of 3, so it is transient and already handled. And the azure-devops MCP has no edit-comment operation (repo_pull_request_thread_write offers create, reply, update_status only), so updating the summary in place used the CLI fallback docs/agents/issue-tracker.md § Access sanctions. That is the contract working as designed rather than a gap.

Erratum on the resolution above — three lines have gone false (2026-08-26)

The resolution comment
is #379's read-1 and still governs the
prefactor-plus-six-slices shape. Three of its claims were true on 2026-08-23 and are not true now.
Recorded here so a reader of that comment finds the correction beside it.

P item 5 is struck. It asks for the Storybook stories glob to be widened "so a component in
packages/ui-react/ can carry its own story". The Consumer's CLAUDE.md § Where the files go — written
after this grilling — puts a story in apps/storybook-react/src/stories/, which the existing ../src/**
glob already matches. The item is satisfied by changing nothing. Struck by the maintainer on
2026-08-26: one home for a story, and the glob stays as it is. P is five items.
docs/adr/ exists in the Consumer. Measured on origin/develop 2026-08-26:
0001-figma-variant-axes-map-to-composition.md and 0002-shadcn-on-the-base-ui-track.md. So "docs/adr/
does not exist in DXP-DesignSystem yet, so creating it is part of the cost" is false, and item 6 of
§ What this did not decide is answered — ADR 0001 is that decision, written down.
S2's badge variant is not security-setup. Measured 2026-08-26 with
get_metadata(yCLWgCel1UcW7oToDge2fT, 181:3820): badge-main draws two combinations, variant=default
and variant=icon, and carries no state axis at all — so the focus gate does not reach it. The
rename landed after this grilling.

Two claims worth confirming rather than correcting, measured the same day: the four stock .tsx files and
the four stock token files are still present, there is still no components.json, and there is still no
test task in turbo.json nor a root test script. The rest of P stands.

Scope for the #379 walk, decided by the maintainer
2026-08-26: the PRD covers P, S1, S2, S3; S4–S6 are named in Out of Scope with their blockers.
The Tailwind prefix is kept but renamed — item 3 of § What this did not decide is answered. It changes
from ui to dxp inside P, because ProfileServices will compose code from two agencies and ui is the
name a second component layer picks; dxp names the platform, so it cannot collide. tailwind.prefix is set
in components.json to match, and in Tailwind v4 the prefix sits at the front of the class, before any
variant: dxp:hover:bg-surface.

P also gains four token-layer constraints, so that brand and colour-theme support stays possible: the
dark variant declared as a selector, @theme inline on every role token, components restricted to
semantic tokens, and the duplicate unprefixed Tailwind import removed. The architecture itself is
WI 42973, not P. Detail on #379's opener.

What are the Consumer design system's first slices? #377

Description

Question

Acceptance criteria

Activity

orioltf commented on Aug 14, 2026

How to start this session

orioltf commented on Aug 23, 2026

The Figma research is in — read it before choosing slices

orioltf commented on Aug 23, 2026

How to start this session

Read order

The one trap

The decision the ticket does not make

Other traps

The bar that proves it

Report back

orioltf commented on Aug 23, 2026

Resolution — one prefactor and six slices

The list

P — prefactor: make the repository able to hold a component

S1 — the card renders, with its three states

S2 — the badge renders

S3 — the card carries a badge

S4 — Figma maps to code

S5 — visual regressions are caught

S6 — the card is responsive

The bar every slice meets

The decisions this ticket took

What Chromatic needs

Corrections to this ticket's opener

Vocabulary

What this did not decide

orioltf commented on Aug 23, 2026

Addendum — the planned usage corrects three of the decisions above

1. The card is a modal trigger. Decision 5 is amended.

2. Every planned card has an icon, and every icon is different.

3. No focus is a defect at S3, not a theoretical gap.

4. The usage page has not moved to the new component.

5. CI is plannable after all.

orioltf commented on Aug 23, 2026

Correction — prefactor item 5 was wrong

orioltf commented on Aug 23, 2026

The stack decisions are now recorded in the Consumer

orioltf commented on Aug 23, 2026

orioltf commented on Aug 23, 2026

Merged

orioltf commented on Aug 26, 2026

Erratum on the resolution above — three lines have gone false (2026-08-26)

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

3. No focus is a defect at `S3`, not a theoretical gap.