Land a rendering component on develop, so the client sees the walk's output

Rewritten 2026-09-03 by the #373 orchestrator. Four of this ticket's five original criteria
were met, twice, by runs 1 and 2; the fifth was not, and it is the one the client can see. The
original body — "Walk /specs → /tickets → /build once in DXP-DesignSystem and deliver the first
slices" — is in this issue's revision history. What follows is the remainder.

Question

Two full walks of the main line have run in DXP-DesignSystem. Neither left a component on
develop. Does a measurement run's output ever get merged, or does delivery need a pass of its own?

What is already done, and what is not

Original criterion
`/specs` produces a PRD for the first slice set	met, runs 1 and 2
`/tickets` publishes the slices to Azure DevOps with their blocking edges	met, runs 1 and 2
`/build` completes at least one slice AFK and opens a pull request	met — PR 5807, PR 5835
The client can see something from the Figma page rendering in the repo	not met
Every failure is written up naming Box, node, and cause	met — `docs/research/2026-08-31-dlc-run-2-findings.md`, 63 findings

origin/develop carries three contract.generated.md / screenshot.generated.png pairs,
index.ts, lib/utils.ts and styles.css. No component source and no story. Both builds live
on branches abandoned on purpose — 5e683a7 and a71e19f — because a run's output is a measured
artefact, and fixing it would destroy the baseline the next run is compared against.

That reasoning is sound and it has now held for two runs. The consequence is that the deliverable and
the measurement are the same task, and only the measurement happens.

The decision this ticket makes

Whether a run's output is ever merged, and if not, what delivers instead. Two shapes, and this ticket
picks one:

The run delivers. A run's branch is reviewed and merged like any other, and the baseline for
the next comparison is a tag or a commit rather than the absence of code. Cheapest in effort;
changes what every future run means.
Delivery is its own pass. A separate slice, built from the run's output by hand or by a fresh
/build, lands on develop. Keeps the runs clean; costs a build that the client already paid for
once.

Acceptance criteria

The decision above is recorded — which shape, and why the other was refused.
origin/develop in DXP-DesignSystem carries at least one component source file and at least one
story that the Storybook vitest project renders.
The component is one the Figma profile-card page names, so the client recognises it.
The five mechanism checks 43020–43024 act on it rather than passing vacuously: each check has
something in the tree to inspect.
Whatever baseline run 3 is compared against is named as a commit, not as "develop is empty".

Why this is still p0

It is the only criterion of the original ticket that a client can see, and after two runs it is the
oldest unmet promise on this map.

STALE — superseded 2026-08-26. Do not follow this opener. It was written at filing on
2026-08-14, before #398, #402, #403, #404, #405, #414 and #416, and every read order, blocker
and command version in it is wrong. The authoritative opener is
issuecomment-5417415983.

The 2026-08-19 notice this marker replaced, kept as record: "Blocked — do not start yet. As of
2026-08-19, #381 gates this ticket: all seven installed commands stop at Step 1 in
DXP-DesignSystem until the lib/ deletion lands. This opener was written at filing (2026-08-14)
and will be rewritten at dispatch." #381 closed on 2026-08-20.

How to start this session

Produces: the ten-day goal — /specs → /tickets → /build all run in DXP-DesignSystem, first
slices delivered, and a written list of what broke.

Run /wayfinder 373 #379 here to claim. The work happens in the Consumer's clone.
In that repo, in order: /unic-archon-dlc:specs <slug>, then /unic-archon-dlc:tickets <slug>,
then archon workflow run unic-dlc-build "<slug>".
Run the commands as they stand. Decision 16 defers their rewrites; nobody rewrites a command
mid-sprint.
When something breaks, write the finding — Box, node, and whether the tracker, the Harness or the
Method caused it — then work around it and continue.

Traps

Archon forks from main by default and ignores baseBranch in config. Pass --from <branch> and
verify the fork point before trusting the run.
Archon rewrites the pull request's base after opening it. Re-check the base and revert it once the
run ends.
Judge a run by what is pushed, never by worktree state. TaskStop does not kill an Archon run.
/build is the priority. If the ten days run short, one completed /build slice is what must
survive.

How to run the rest of the walk — the Consumer session (2026-08-26 17:35)

P is merged: PR 5798 landed on
develop as dda788a, target never retargeted, merge commit rather than squash.
WI 42974 is Ready for Test — and its real test is
S1, which is the honest state for a prefactor.

This note governs how the remaining steps are started. The opener above still governs everything else —
the three contracts, the icon trap, the design-file re-measure, the bar. Read it; this replaces only its
"claim it here" instruction, which no longer works.

Where it runs

/specs onward runs in a session rooted at the Consumer's clone.
~/.claude/plugins/installed_plugins.json holds one entry for unic-archon-dlc, project-scoped to that
repository, so a session rooted in the plugin repo has no DLC commands at all. That is the only
constraint on where the remaining steps run.

Nothing needs claiming first. Earlier revisions of this note made /wayfinder a condition on starting —
it is not one, and treating it as one cost two sessions three exchanges over a step that changes no outcome.
The ticket is already claimed, this note and the opener carry the orientation, and /specs is the work.
/wayfinder 373 #379 remains useful only to give a cold agent the map's framing; skip it otherwise.

Two checks before `/specs`, both cheap and both de-risking everything after

Meet the branch the way a new developer does. Clone develop fresh, pnpm install from the
lockfile, then pnpm build, pnpm lint, pnpm check-types, pnpm test, and start Storybook. Every
green on this branch so far was measured in a worktree edited across eleven commits with node_modules
from earlier states, and the lockfile itself moved by 42 lines. Judge by exit code, not by reading
output for the word "error".
Prove scripts/add-dependency.sh on a real add. Its fix was verified with an idempotent add — a
package already in the catalog, manifest unchanged — which may never reach the pnpm add line where the
bug was. The failing arms were dep, dev and peer, each appending a second flag.
@base-ui/react is the honest test and S1/S2 need it anyway: shadcn add emits an import for it
and installs nothing. Add it with the script, to packages/ui-react, and keep the result if it is
correct. One command proves the fix and does the work.

Then `/specs`

/unic-archon-dlc:specs profile-card <the Figma and Confluence sources>

The slug is worth one thought before you type it, because it names workflows/<slug>/PRD.md, the
/specs branch, and the arguments to /tickets and /build afterwards. profile-card names the feature's
visible outcome rather than one of its three components. Change it if you prefer; changing it later means
three paths move.

Sources to hand it, so it ingests rather than interviews from nothing: the card set (189:5266) and the
badge set (181:3820) in yCLWgCel1UcW7oToDge2fT, the icon set in the Assets file
(8jt7EUEGVwqyJswqLPk2sr — and read the opener's § one trap before that one), plus
Design System Components
as the parent the contracts publish under. docs.publish is true on develop, so the three pages get
created; the PRD publishes nothing and says so, which is correct.

One collision to decide before the `/specs` gate

commands/specs.md hardcodes the branch feature/specs/<SLUG>. The Consumer's convention is
feature/<WI#>_<slug>, work item first. So the PRD's pull request will carry no work-item number in its
branch name and will not auto-link to one. Two ways out, and the operator picks at the gate:

Let the command name the branch, and link the PR to WI 42975
by hand.
Rename the branch to the Consumer's convention before opening the PR, and record that the command's
hardcoded name does not fit a work-item-first tracker.

Either is fine. Which one you choose is a finding either way — the command names a branch shape without
asking the tracker contract, and that belongs in the walk's write-up.

At `/tickets`: three criteria for `S1` that no command will remember

commands/tickets.md does not know design contracts exist and sets no parent, so the Step 10 gate is a
by-hand pass. Four things to eyeball, three of them specific to S1:

Every slice's body carries its contract path.
passWithNoTests comes out of apps/storybook-react/vitest.config.ts — thread 65283, kept by design
in P because P ships no tests; S1 writes the first one, so S1 is where it expires.
The packages/ui-react/tsconfig.json paths mapping — thread 65287, serves the add-then-reshape
window. Name the slice that closes that window, or declare it permanent.
The design-tokens edge is restored as four things together, or it fails with a type error and no
obvious cause: the @repo/design-tokens dependency in apps/storybook-react/package.json, its two
paths entries in apps/storybook-react/tsconfig.json, a .storybook/design-tokens-css.d.ts declaring
the two extensionless export keys, and the two imports in .storybook/preview.ts. CLAUDE.md
§ Build graph states the set; criteria 3 and 4 touch different tsconfig files, so neither hides
the other.

Each slice's binding home is its ADO work item, parented to
WI 42975 by hand — /tickets sets no parent. This
comment only relays them across the session change.

Report back

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 repository. Send it when you learn it, not at the end.

Walk report — the `P` leg, 2026-08-26

This is the defect report the ticket asks for: what broke, where, and whether the tracker, the
Harness or the Method caused it. It covers the leg this session walked — P landed by hand as
PR 5798 (merged, dda788a
on develop), twice reviewed by the unic-dlc-pr-review Box. /specs → /tickets → /build
remain; the consolidated handover
is what the next session reads.

Harness (Archon engine)

abandon, resume, approve, reject are hidden from archon --help (0.7.0). Read verbs
from the binary. Already on #373's
Archon defect list.
resume on a run that crashed at a HITL gate posts without any approve. Run e56747e9 died
SIGTERM while paused at review-gate; resume replayed the DAG and the post node ran —
summary plus nine inline threads — with no approval ever accepted. Operational rule now on wayfinder: unic-archon-dlc is prose, and proven at a Consumer #373:
a crashed-at-gate run is abandoned, never resumed; dispatch detached or task-managed, never as a
shell & child.
Archon overwrites tracked .archon/ files in its own worktree from the invocation directory.
The review Box read docs.publish: false (the clone's develop) while the branch under review
committed true, and reported the drift as a contradiction in two consecutive iterations. Known
behaviour; it makes any .archon/ config change unreviewable by the Box that runs under it.

Harness (the Box, `unic-dlc-pr-review`)

The Box cannot verify a green claim — its worktree has no node_modules. Its summary said so
honestly, twice; both lines quoted verbatim on
#430, which owns the fix shapes.
The reconcile's "fixed" bucket mixes fixed, withdrawn and deliberately-kept — it counted two
byDesign threads as fixed in the same run that set them byDesign on the PR.
#431 owns it. Corrected count for the
record: iteration 2's severity sections carry nine findings (2 critical, 2 important, 5 minor),
eight new plus one carried-over.
Review quality was high. Iteration 1: 3 critical / 6 important / 4 minor, all real, including
collateral the author missed (Introduction.mdx documenting deleted scaffold). Iteration 2 caught
that fixing ADR-0003 had moved a disagreement onto the work item — cross-source fixes need all
sources. The one defect neither iteration caught — CLAUDE.md's build-graph diagram contradicting
a dependency the fix commit removed — was a set-level read the orchestrator made after the fixes;
fixed in 18a51c1.

Harness (the commands)

commands/specs.md hardcodes the PR branch as feature/specs/<SLUG> (lines 398, 402, 408 at
0.26.0) while this Consumer's convention is feature/<WI#>_<slug>, work item first — so the PRD's
pull request will carry no work-item number and will not auto-link. The command names a branch
shape without consulting the tracker contract. Surfaces at the very next gate.
/tickets does not know design contracts exist and sets no parent link — the operator
hand-verifies contract paths at the Step-10 gate and hand-parents the slices to Feature
42975. Known before the walk (Rewrite commands/tickets.md from scratch against the to-tickets Method #382 owns
the rewrite); the parent-link half was found during it.
Neither /wayfinder nor the DLC commands span both repositories. The DLC commands are
project-scoped to the Consumer; /wayfinder is a repo-local skill here. No single session can
claim the ticket where it lives and run the commands where they are installed. This walk bridged
it by hand; the handover comment is the seam.

Method / stack (Consumer-side facts the next slices need)

shadcn init refuses a plain library package ("We could not detect a supported framework");
the manual components.json route is the only one in packages/ui-react. What are the Consumer design system's first slices? #377's "Run shadcn
init" was unrunnable as written.
shadcn add on the Base UI track emits correct dxp:-prefixed v4 classes and does not install
@base-ui/react — the first slice needing a primitive adds it through the catalog.
scripts/add-dependency.sh failed every typed add (flags passed as one string). Fixed in the
PR; the fix itself was the review's proof case for re-dispatching rather than self-grading.
style-dictionary writes no dist/ at all from zero token sources, exit 0 — so the
design-tokens edge was removed whole and S1 restores four things together (criterion 3 in the
handover; CLAUDE.md § Build graph carries the list).

Tracker

No Azure DevOps defect surfaced on this leg. WI create/update, PR create/update, thread
reply/resolve all behaved. The az devops invoke two-call thread pattern held.

Standing down. P is merged, the ticket stays open and unassigned for the Consumer-rooted
session that runs /specs onward. What remains is the ticket's own acceptance list: the PRD, the
slices on Azure DevOps with edges, one slice through /build to a PR, and the card rendering.

Erratum on the walk report — one line of it is mine and it is wrong

The walk report is
otherwise the record; this corrects one claim in its § Harness (the commands), which it took from an
orchestrator message rather than measuring.

It says /wayfinder is a repo-local skill of this repository and that no single session can both claim the
ticket and run the DLC commands. The first half is unverified and the maintainer reports the opposite.
/wayfinder is installed globally for him (2026-08-26 17:38), so a Consumer-rooted session may well be able
to claim normally.

What is actually measured, and what is not:

Measured: it exists as a repo-local skill at .claude/skills/wayfinder in unic-agents-plugins; the
Consumer's own .claude/ holds only settings.json and settings.local.json; ~/.claude/skills/ carries
no wayfinder entry. The copy under ~/.claude/plugins/marketplaces/unic-agent-plugins/ is that
checkout's own repo-local skill, not a user-scope one.
Not measured: where the global install resolves from. Three directory listings do not exhaust the
places a skill can live, and a negative from a directory listing is as weak as a positive from memory —
which is the actual lesson, and it is the orchestrator's to carry.
Settled by one keystroke: type /wayfinder in a session rooted at the Consumer. If it is offered,
claim with /wayfinder 373 #379.

What survives unchanged, because it was measured independently: the DLC commands are project-scoped
to DXP-DesignSystem in ~/.claude/plugins/installed_plugins.json, so /specs onward must run in a
Consumer-rooted session. That is the load-bearing half of the finding and the reason the handover exists.
The branch-name collision in the same section — feature/specs/<SLUG> at lines 398, 402 and 408 of the
installed 0.26.0 copy against the Consumer's feature/<WI#>_<slug> — was verified by the worker and stands.

Body rewritten 2026-09-03 by the #373 orchestrator, on the maintainer's instruction. The original — "Walk /specs → /tickets → /build once in DXP-DesignSystem and deliver the first slices" — is in this issue's revision history.

Why, in one line: four of its five criteria were met twice, by runs 1 and 2, and the fifth was not. The ticket read as untouched work while being mostly done, and it sits p0 at the head of every frontier query.

The measurement that decided it, run today against origin/develop in DXP-DesignSystem:

packages/ui-react/src/badge-main/contract.generated.md
packages/ui-react/src/badge-main/screenshot.generated.png
packages/ui-react/src/card-profile-main/contract.generated.md
packages/ui-react/src/card-profile-main/screenshot.generated.png
packages/ui-react/src/icon/interface/User2/contract.generated.md
packages/ui-react/src/icon/interface/User2/screenshot.generated.png
packages/ui-react/src/index.ts
packages/ui-react/src/lib/utils.ts
packages/ui-react/src/styles.css

Contracts and screenshots. No component source, no story — one .tsx in the whole repository. Both builds live on branches abandoned on purpose (5e683a7, a71e19f).

The rewrite turns the remainder into the decision underneath it: does a measurement run's output ever get merged, or does delivery need a pass of its own? Left as a task rather than a decision, someone lands a component without settling it and the same gap reopens after run 4.

Amended 2026-09-17 while charting run 4's map, #498

This ticket moved from #373 to #498. GitHub
allows one parent, so the move is a replacement rather than an addition. The effort it serves has not
changed; the map that carries it has.

The decision this ticket asked for, taken

A run's output is merged, and the merge is split into two acts. The question was "does a measurement
run's output ever get merged, or does delivery need a pass of its own?" Both, in sequence:


Act 1, inside run 4	`/qa` merges the run's pull request to `integration/dlc`, a long-lived branch. `develop` stays as it is, the run stays comparable with runs 1 to 3, and the branch is resettable
Act 2, outside run 4	after a demo to Jessi, if she agrees, `integration/dlc` reaches `develop` through an ordinary pull request — #503

Why not merge straight to develop. Runs 2 and 3 each wiped the previous run's artefacts so the next
run started from an empty tree (d09feff, 5e39db6). A merge to develop would mean every later run
starts from a tree that carries a component, which is a different question from the one three runs have
asked. Splitting the act keeps the measurement comparable and puts the component in front of the
client, and it means develop receives it by a human decision rather than as a side effect of a
measurement.

Why not a pass of its own, as the original body proposed. Run 4 ends in a merge by design, because
#439 criterion 18 has /qa close the grouping
ticket when it merges the pull request. A separate delivery pass would pay for a second build the client
has already paid for once, to produce what run 4 produces anyway.

Criterion 2 is amended

It read:

origin/develop in DXP-DesignSystem carries at least one component source file and at least one
story that the Storybook vitest project renders.

It now reads:

Run 4's output reaches integration/dlc, carrying at least one component source file and at least one
story that the Storybook vitest project renders. It reaches origin/develop through
#503, a separate pull request conditional on
the demo.

Amended rather than quietly satisfied: an integration branch is not develop, and a run that satisfied a
different criterion while the written one said develop is the gap shape the root AGENTS.md four reads
exist to catch.

The other four criteria stand. The fifth — "whatever baseline run 4 is compared against is named as a
commit, not as develop is empty" — is now carried by
#502, which creates integration/dlc and names
the commit in the run record.

What the client actually sees

A locally-run Storybook on a shared screen, with the maintainer and Jessi. Jessi does not review code she
does not understand, and the Consumer has no CI to publish Storybook — giving it one stays out of scope,
on #373. So "the client sees something render" is satisfied by the demo, and develop is where it lands
afterwards.

Why this ticket stays open and blocked

Its decision is taken; its criteria are verified by run 4 and by act 2. It is blocked_by
#503 so the frontier cannot offer it before
there is anything to verify against.

Closed as superseded by #678's resolution, approved by the maintainer on 2026-10-30: run 4 is dropped and unic-archon-dlc is frozen. Reason for this ticket: "the client sees a rendered component" becomes the successor's first milestone in #687 (decision 2).

— unic-sdlc-orchestrator-9

Navigation Menu

Repository navigation

Land a rendering component on develop, so the client sees the walk's output #379

Question

What is already done, and what is not

The decision this ticket makes

Acceptance criteria

Why this is still p0

How to start this session

9 remaining items

How to run the rest of the walk — the Consumer session (2026-08-26 17:35)

Where it runs

Two checks before `/specs`, both cheap and both de-risking everything after

Then `/specs`

One collision to decide before the `/specs` gate

At `/tickets`: three criteria for `S1` that no command will remember

Report back

Walk report — the `P` leg, 2026-08-26

Harness (Archon engine)

Harness (the Box, `unic-dlc-pr-review`)

Harness (the commands)

Method / stack (Consumer-side facts the next slices need)

Tracker

Erratum on the walk report — one line of it is mine and it is wrong

Amended 2026-09-17 while charting run 4's map, #498

The decision this ticket asked for, taken

Criterion 2 is amended

What the client actually sees

Why this ticket stays open and blocked

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Land a rendering component on develop, so the client sees the walk's output #379

Description

Question

What is already done, and what is not

The decision this ticket makes

Acceptance criteria

Why this is still p0

Activity

orioltf commented on Aug 14, 2026

How to start this session

9 remaining items

orioltf commented on Aug 26, 2026

How to run the rest of the walk — the Consumer session (2026-08-26 17:35)

Where it runs

Two checks before /specs, both cheap and both de-risking everything after

Then /specs

One collision to decide before the /specs gate

At /tickets: three criteria for S1 that no command will remember

Report back

orioltf commented on Aug 26, 2026

Walk report — the P leg, 2026-08-26

Harness (Archon engine)

Harness (the Box, unic-dlc-pr-review)

Harness (the commands)

Method / stack (Consumer-side facts the next slices need)

Tracker

orioltf commented on Aug 26, 2026

Erratum on the walk report — one line of it is mine and it is wrong

orioltf commented on Sep 3, 2026

orioltf commented on Sep 17, 2026

Amended 2026-09-17 while charting run 4's map, #498

The decision this ticket asked for, taken

Criterion 2 is amended

What the client actually sees

Why this ticket stays open and blocked

orioltf commented on Oct 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Two checks before `/specs`, both cheap and both de-risking everything after

Then `/specs`

One collision to decide before the `/specs` gate

At `/tickets`: three criteria for `S1` that no command will remember

Walk report — the `P` leg, 2026-08-26

Harness (the Box, `unic-dlc-pr-review`)