Dispatch run 3, read both legs against sealed predictions, and write it up

Question

Dispatch run 3, read both legs against predictions sealed beforehand, and write the answer up. Nothing here is a decision — it is the run this map exists for, and it is the last ticket to move.

Blocked by, and one edge GitHub cannot express

Native blocked by: #430, #438 (closed 2026-09-03, edge kept as record).

#439 no longer blocks this ticket (edge removed 2026-09-04 by the orchestrator on the maintainer's ruling, "ok, espera a run 3"). Its grilling changed the fix from a readability change to three behaviour changes: evidence writes always, a red build opens no pull request, /tickets guarantees a parent ticket. All three are active under the Consumer's gates.build: afk, so it is a second variable under #456's class rule and joins run 4's set. Run 3's product is discarded by design; its measurement does not depend on #439.

Also blocked by ADO 43028 — the sixth mechanism check, which walks component directories for a story the vitest run renders. GitHub and Azure DevOps cannot be linked, so this edge is prose and vanishes if nobody reads this paragraph. It is New, its predecessor 43020 is Resolved, and it is dispatchable now.

The steps, in order, and why each is here

Land the blockers. The three GitHub tickets above and ADO 43028.
Re-park run 2's isolation directories. ~/Desktop/run2-parked/ holds dxp-memory and three remember* directories, restored live on 2026-09-01. Run 2 measured with them absent; a run 3 that can read them is measuring a different chain.
Delete run 2's artefacts, on the run's own branch, at dispatch. develop carries run 2's PRD, issues.json and three design contracts. Run 3 hits the same re-entry trap and needs the same deletion, exactly as run 2's two setup commits did. Doing this early destroys the baseline still being compared against, which is why it is deliberately not a work item of its own.
Seal the predictions, before dispatch, off the tracker. They must cover both legs: on the specs leg, does the grilling fire, do the halts halt, is there a Confirmations section the gate would refuse without; on the build leg, do the six checks reach the implementer.
Dispatch, then read both legs against the sealed predictions.
Write the answer up in the findings register, naming which mechanisms fired and which did not.

Preconditions already met

Precondition: the story organisation is decided. ADR-0006 on Consumer develop — COMPONENTS, ICONS, DEMOS, all plural.
Precondition: the Consumer runs the current plugin. Verified 2026-09-03: all four Boxes in DXP-DesignSystem/.archon/workflows/ are byte-identical to plugin develop apart from the provenance header /setup stamps, and fix(unic-archon-dlc): /specs skips the grilling its config requires and reports halts that never fired #441's criterion 9 is present in the Consumer's copy.

The confound to state rather than discover

The mechanism tickets introduced a node vitest project neither earlier run had. So the testing-seam question gets a different answer this time, and part of any run-2-versus-run-3 diff is new infrastructure rather than new knowledge. Say so in the write-up; do not let it be found afterwards.

Acceptance criteria

The predictions were sealed before dispatch and are quotable afterwards.
Both legs are read against them, and the score says which predictions held.
The findings register names which mechanisms fired, which did not, and which could not be judged.
The new-infrastructure confound above appears in the write-up.
The baseline run 3 was compared against is named as a commit, not as "develop was empty".

Azure DevOps

43033 — 13 points, Feature 42975, iteration 2026_08 - R 3.6.

A third change reached run 3's baseline, and nobody chose it for this run

Reported by the unic archon dlc reconfigure session at 17:36 on 2026-09-05; measured here before filing.

estimations in .archon/unic-dlc.config.yaml was 'off' from 83e8b67 (2026-08-17) through run 2. It is
'both' on develop today. The change landed at 1995549 (2026-09-05 16:17) and merged inside PR 5853, and
it is the only non-default key in that file with no comment saying why.

286034b  2026-09-05 16:53  estimations: 'both'
1995549  2026-09-05 16:17  estimations: 'both'   ← the change
6fa6a06  2026-09-03 12:59  estimations: 'off'
…
83e8b67  2026-08-17 12:43  estimations: 'off'

It was a maintainer edit already in the working tree when /setup reconfigure ran, so it rode in with the
install commit. The pre-PR review flagged it and nothing acted on it.

What it does, and what it costs

'both' turns on the provisional estimation wave in /specs and the definitive wave in /tickets. It touches
the two planning legs. It does not touch the build leg or any of the six checks.

So it is not a confound for the treatment. This map's rule is that a second change is a confound only when
its effect cannot be told apart from the first's, and estimation waves are separately observable from whether a
check fires.

It is a confound for two of the five numbers run 2 published, because run 2 measured them with estimations
off:

Run 2 number	Why it stops comparing
Cost — build 6, review round 1 3, round 2 2, in points of a week	two extra waves add planning cost that run 2 never paid
Unattended: no — four halts in `/specs` alone	an estimation wave can halt; the halt count is then measuring a different command

The ruling this needs, before dispatch

Recommended: set it back to 'off' for run 3, in the same commit as the other pre-run steps. Run 3 already
carries two changes chosen for it — the mechanisms and #441's
/specs work. A third that nobody chose for this run buys the question nothing and costs two comparisons.
Turn estimations on afterwards, as its own observation.

The case against, stated so the choice is real: 'both' may be the production setting the maintainer wants,
and a run under observation is the cheapest place to watch estimation waves behave. If that is the call, keep
'both' and this comment becomes the record that says the cost and halt rows do not compare to run 2.

Either way the key gets a comment saying why, like every other non-default key in that file.

Second item from the same report, smaller

PR 5853's description accounts for four changed files. Nine merged: the config, four Box YAMLs, .gitignore,
README.md, apps/storybook-react/vitest.config.ts and docs/agents/unic-archon-dlc.md. The description never
mentions the vitest config or the README section, so the merge commit's PR is an incomplete account of what
landed on the Consumer's develop. Fixable after the fact with az repos pr update; the maintainer's call
whether it is worth it.

Ruled: `estimations` stays `'both'` for run 3

Maintainer's call, 2026-09-05 17:46, against the recommendation in the comment above. Recorded here because the
comment above is now the record of what that choice costs, and because nothing else in either repository says it.

What this settles. Run 3 dispatches with estimations: 'both'. The provisional wave in /specs and the
definitive wave in /tickets both run, and run 3 is the first observation of either.

What it costs, and this is the whole reason to write it down. Run 2 measured with estimations: 'off'. Two of
its five published numbers therefore stop comparing to run 3's:

Cost — build 6, review round 1 3, review round 2 2, in points of a week. Two extra planning waves add cost
run 2 never paid.
Unattended: no — four halts in /specs alone. An estimation wave can halt. A halt count from run 3 is
counting a different command.

So when run 3 is read against the seal, those two rows are marked not-comparable rather than scored. The three
that still compare are dedup, reconcile and praise. Whoever writes the seal carries this sentence into it.

Third comparison already lost, for a different reason (from #463):
lint, format and coverage in the Consumer cannot report a failure, so any prediction sealed about those three
is unfalsifiable. Do not score them either. test and check-types are the two that mean something.

The one thing still outstanding from this

The key needs a comment saying why it is 'both', like every other non-default key in
.archon/unic-dlc.config.yaml. Text to use verbatim, so nobody re-derives it:

# 'both' runs the provisional estimation wave in /specs and the definitive one in /tickets. Turned on
# 2026-09-05 (1995549) and kept for run 3 by the maintainer's ruling, so run 3 is the first observation of
# either wave. Run 2 measured with this 'off': its cost figures and its four-halt count do not compare to
# anything measured from here on. See unic/unic-agents-plugins#457.
estimations: 'both'

It lands on the Consumer's develop, not on run 3's branch — a run branch gets abandoned, and both previous ones
were. It is a two-line diff and needs a branch and a PR like everything else there, so it rides the next Consumer
PR that is already going to develop rather than earning one of its own.

A mechanism can read green by construction too, and run 3 cannot currently tell that apart from a mechanism working

From WI 43028's pr-review iteration 1, 2026-09-05 18:01. Verified here at 5a8ec55 on
feature/43028_component-story-check, not taken from the report.

What happened

43028's check shipped with 12 passing tests, four of which fire the check on fixtures designed to fail. The Box's
one important finding was a hole none of them reached:

import { BadgeMain } from './badge-main/BadgeMain.js'
export { BadgeMain }          // no module specifier

That clause hit the skip written for export {}, so the check returned [] directories and [] gaps and the run
went green. Fixed in 5a8ec55 by turning the skip on the name count rather than on the specifier: export {}
still skips, a named export with no module now throws.

The barrel shape that triggers it is the one develop gets the day the first component lands, if whoever adds
it writes a local re-export. So the check would have been silently inert exactly when it first mattered.

Why this is a measurement problem for run 3 and not just a bug

The six checks are run 3's treatment. If a check can pass vacuously, then in the run's output "the mechanism
fired and found nothing" and "the mechanism was inert" look identical. Every conclusion run 3 draws about whether
mechanisms carry knowledge rests on telling those two apart.

It is the third instance of one shape measured today, and the three together are the argument:

Where	The green that proves nothing
Consumer commands	`lint`, `format`, `coverage` cannot report a failure (#463)
Box bootstrap	`sdlc_needs.install` is a two-command chain and the summary reports one `ok`, so a fetched chromium and a warm-cache no-op are the same line
A mechanism itself	a check returning `[]` on the barrel shape it will actually meet

The first two were already known when run 3 was planned. The third was not, and it is the one that touches the
treatment.

What this asks the seal to carry

Every check gets a positive control on the run's own output, and the control is run before the result is read.
Not a fixture — fixtures are what missed this. The technique is the one DS-43028 used to prove its own caller:

add an export to packages/ui-react/src/index.ts that should fail the check, run it, watch it fail naming the
right directory, revert.

A check that cannot be made to fail against the run's actual tree scores as inert, never as a pass. Inert is a
finding about the mechanism, and it is a different finding from "the implementer produced no defect" — which is the
whole thing run 3 exists to distinguish.

This is an addendum to the seal-shape question, still unanswered. It does not depend on which shape is chosen:
whichever way the seal is scored, an unscored check is worth less than a check proved able to fail.

Not proposed as a ticket

The chained-install line is a Consumer authoring choice (one key holding two commands) as much as a Box reporting
choice, and it costs nothing today. Recorded here so run 3 does not read ran the declared install command: ok as
evidence about chromium. No issue filed.

Correction: the positive control is per-check, not one technique for all six

The comment above named one
technique — add a failing export to packages/ui-react/src/index.ts, watch the check fail naming the right
directory, revert — and wrote it as though it proved any of the six checks. It does not. Caught by DS-43028
on 2026-09-05 19:38.

43020 is the counter-example. Its caller reads stylesheets, not the barrel: uiReactStyleSheets() throws on
empty rather than returning [], so it already reads real files and passes for want of a @theme block. A barrel
append does nothing to it, and would have produced a green that I would have scored as a proved control.

I generalised from the one check in front of me to a rule about all six. That is the error this map has a memory
for — a bar written from the instances that prompted it detects only those instances.

The rule, restated

Each check gets its own positive control, written against the input that check actually reads, and a check with
no working control scores inert. The technique is per-check; only the obligation is universal. Whoever writes the
seal names the control for each of the six and runs it. Two are already known:

Check	Reads	Control
43028	the barrel `packages/ui-react/src/index.ts`	append a failing export, watch it fail naming the directory, revert
43020	stylesheets, via `uiReactStyleSheets()` (throws on empty)	not a barrel append — needs a `@theme` scale `cn()` does not know
43021, 43022, 43023, 43024	stories	unwritten; each needs one before run 3's result is read

Four of the six have no control written yet. That is work before dispatch, not after.

The second finding underneath it, which is the interesting one

DS-43028 over-claimed inside the very paragraph it added to stop over-claims: checks/README.md's new text said
"every real-tree call here passes on an empty set", which is false of 43020 for the reason above. Fixed in
12aa37d.

So both of us made the same move within an hour, in prose whose subject was that move. A statement about a set of
mechanisms is a claim about each member, and it needs checking against each member. Reading it as one sentence is
what lets it through.

Last GitHub-and-ADO precondition closed: 43028 merged

PR 5854 merged 2026-09-06 as f77ee51 on DXP-DesignSystem's develop. Verified here: 12aa37d is an ancestor of
origin/develop, checks/component-stories.ts and its test are present on develop, and WI 43028 is Resolved.
Six checks now ship — ADO 43020–43024 and 43028.

The register's F1 row and F4's count are updated in
PR #466, which also adds § F5 for what building the check
taught. Nothing on this ticket waits on that PR.

What is actually left before run 3 dispatches

The ticket's four non-ticket steps are unchanged. Two things sit in front of them and neither is on the list yet.

1. Four positive controls are owed

Per the correction above, each
check needs a control written against the input that check actually reads, and a check with no working control
scores inert rather than pass. Two are settled, four are not:

Check	Control
43028	written and re-run after the `gapReason` rewrite — append a failing export to the barrel, watch it fail naming the directory, revert
43020	known not to be a barrel append; needs a `@theme` scale `cn()` does not know. Not written
43021	not written
43022	not written
43023	not written
43024	not written

This is pre-dispatch work, and it is small — each is a one-line edit, a run, and a revert. It is not a ticket unless
the maintainer wants one; it is a step in whoever prepares the run.

2. The seal's shape is still undecided, and it is now the only open design question on this ticket

#456 § Not yet specified says who scores, against what, and
where the score lives is unsettled. The proposal on the table, unanswered since 2026-09-05 17:45:

One arm per mechanism, predicting two things separately — whether the implementer produces the defect that
check guards, and whether the check fires. The interesting cell is defect present, check silent.
A second arm of defects no mechanism guards, as the control.
Scored by the orchestrator against the run's diff and the check output, never against the run's own report —
run 2 already showed a self-report is the author grading their own homework.
Written into the register, in the shape of § "The sealed prediction, scored". The seal itself lives off the
tracker in ~/Desktop/run3-sealed-predictions-<date>.md until the run ends.

What the seal must mark not-comparable rather than score, whichever shape is chosen: run 2's cost figures and its
four-halt count (estimations moved off → both between the runs), and any prediction about lint, format or
coverage (those three commands cannot report a failure). Dedup, reconcile and praise still compare.

Not blocking

#465 — /pr-review losing a whole review and exiting 0 —
is p1 but does not gate dispatch. It gates reading: /pr-review is one of the mechanisms run 3 is read through,
and it failed the inert-versus-pass bar on its first observation. Run 3's report says so rather than treating a green
/pr-review run as a clean review.

Ruled: the seal takes the proposed shape

The maintainer approved it on 2026-09-15 17:30 CEST, unchanged from
the proposal, which was first put
to him on 2026-09-05 17:45. This closes the last open design question on this ticket.

The shape, restated so nothing has to be re-derived at dispatch

One arm per mechanism. Each arm predicts two things separately: whether the implementer produces the defect
that check guards, and whether the check fires. The cell that carries the information is defect present, check
silent.
A second arm of defects no mechanism guards. That arm is the control.
Scored by the orchestrator, against the run's diff and the check output. Never against the run's own report.
Written into the register in the shape of section "The sealed prediction, scored". The seal itself lives off
the tracker in ~/Desktop/run3-sealed-predictions-<date>.md until the run ends.

Marked not-comparable, never scored

Two because estimations moved 'off' to 'both' between the runs: run 2's cost figures, and its four-halt count.
Three because the command cannot report a failure in the Consumer: lint, format, coverage. Dedup, reconcile
and praise still compare. test and check-types are the two commands that mean something.

What this does not close

The four positive controls for 43021 to 43024 are still owed, and they are owed whichever shape won. Each is a
one-line edit, a run, and a revert, written against the input that check actually reads. A check with no working
control scores inert, never pass, because otherwise "the mechanism fired and found nothing" and "the mechanism
was dead" read the same. 43020 is not a barrel append: it needs a @theme scale that cn() does not know.

Run 3 dispatches once those four controls exist and the seal is written. No ticket blocks it.

Register precondition cleared: PR #466 merged

Merged 2026-09-15 17:47 UTC as ee4c892. Plugin develop moves f3c5118 → ee4c892.

Verified on develop rather than on the PR: F1's sixth-check row reads SHIPPED and names PR 5854 / f77ee51,
§ F5 exists, and the not-comparable list sits in the same file. The seal now has a committed source to read that
list from, which was the reason this PR gated anything.

What is left before run 3 dispatches

One item, and it is not a ticket: the four positive controls for 43021 to 43024. Each is a one-line edit against
the input that check actually reads, a run, and a revert. A check with no working control scores inert, never pass.
43020 already has its control written and is not a barrel append — it needs a @theme scale that cn() does not
know. 43028's was written and re-run after the gapReason rewrite.

Re-measured today, against Azure DevOps and both remotes

Consumer origin/develop = f77ee51, fetched from the remote. Nothing has landed since 2026-09-06.
43033 is Active, 13 points. It is no longer in Ready for Test; that reverted on 2026-09-09.
The six checks 43020 to 43024 and 43028 are all Resolved. 43025 is New and is the last open Task under 43037.
readyForImplementation is a tag, not a field. 43025 and 43028 carry it; 43020 to 43024 do not.
43038 is not missing its Vertec value. It reads Design System // 05. Workflows where every live sibling reads
DS // 04. Library implementation in Frontend.

Session opener — design the four missing positive controls (43021–43024)

What this session produces: one comment on this ticket holding four control designs, one per check. Nothing
else. Invoke no skill. This is a read-and-write task, not an implementation: /implement routes to /tdd, and
a test is the wrong instrument here — a fixture is what missed the defect this whole exercise exists to catch.

Do not run the checks. Do not edit any file. Do not commit, push, or open a PR. You are designing an
instrument, not using it. The controls execute later, against the tree run 3 leaves, by whoever reads run 3's
result.

1. Read order

This ticket's comment 5553607035
— the correction that says the obligation is universal and the technique is per-check. It supersedes
5553046121, which generalised
one check's technique to all six. Read the correction first.
docs/research/2026-08-31-dlc-run-2-findings.md on unic-agents-plugins develop (ee4c892), § F5. It states
what building the six checks taught, including the barrel shape that returned [] and read green.
In the Consumer's clone at origin/develop = f77ee51: checks/ — the four files behind 43021 to
43024, and their callers. You need, per check, the input the check actually reads at run time, not the input
its tests feed it.

2. What a positive control is, and what it is not

A positive control is a deliberate defect of the exact kind one check guards, introduced into the real tree, used
to prove that check can still fail. Three steps: edit, watch it fail naming the right place, revert. It lands
in no commit.

It is not a test and does not replace one. A fixture proves the function; a control proves the real-tree call.
43028 shipped with 12 tests, four of them failure fixtures, and still had a barrel shape (import { X } then a
bare export { X }) that returned [] and read green. Fixed in 5a8ec55. Fixtures are what missed it.

A check with no working control scores inert, never pass. That is the point of the whole exercise: a
silent check is otherwise indistinguishable from a dead one, and telling those two apart is what run 3 measures.

3. The one trap that costs an hour

The technique does not transfer between checks, and it reads as if it does. 43020 is the counterexample:
uiReactStyleSheets() throws on empty input, so its real-tree caller already reads real files, and appending to
the barrel proves nothing about it. Its control needs a @theme scale that cn() does not know.

Two people made the same move inside ninety minutes on 2026-09-05, each while writing about that very move. The
rule that came out of it: a quantifier over a set of mechanisms is an unverified claim per member until each
member is named. "All four" and "each real-tree caller" cost less to write than the enumeration and read as
though the enumeration had happened. So write four designs. Never one design and three references to it.

4. The decision this task does not make

How far a control must reach before it counts. Two competent people diverge here. One introduces the defect at
the outermost real input, the tree the check walks, which is what caught 43028. The other introduces it at the
check's own entry point, which is quicker and proves less. Pick the outermost real input every time, and when a
check's outermost input cannot be reached by a one-line edit, say so in the design rather than falling back to
the entry point. An unreachable control is itself a finding about the mechanism, and it is worth more than a
control that passes by being shallow.

5. Other traps

The Consumer workspace is not tidy and must stay that way. 28 worktree registrations, several dirty, several
carrying commits that are not on develop. Do not run /cleanup --apply. Do not run archon complete on
anything. Do not remove a worktree. Those branches are runs 1 and 2's only addressable output.
Four of the Consumer's declared commands cannot fail: lint, format, coverage, test (today). Do not
use any of them as evidence that anything works.
origin/develop is f77ee51 and has not moved since 2026-09-06. If you see something newer, stop and report it.

6. The bar

For each of 43021, 43022, 43023 and 43024, the design states four things:

The input the check reads at run time, named as a path.
The exact one-line edit that introduces the defect that check guards.
What the check must print when it fails — including the place it must name. "It fails" is not a bar; a check
that fails naming the wrong directory is a finding.
How to revert, in one line.

A design that cannot name item 1 from reading the code is not finished. Say which check it is and what blocked
you; do not infer it from the check's tests.

7. Stop rule and reporting

The weekly token budget is near its cap. Report what you have and stop rather than running long: partial
designs for two checks, clearly labelled, beat four guesses. Under no circumstance run a check to find out.

Post the designs as a comment on this ticket. Then report to the orchestrator session — get its live address from
ListAgents and message the one named wayfinder-orchestrator-*; do not hardcode a seat number. Report: which of
the four are designed, which are blocked and on what, and anything you measured that contradicts this opener.

Positive controls for 43021, 43022, 43023 and 43024

Designed against DXP-DesignSystem at origin/develop = f77ee51, which matches the opener. Nothing was
run, nothing was edited. Four designs, written separately; no design references another for its technique.

The finding that applies to all four, stated once and then per check

apps/storybook-react/src/ does not exist at f77ee51, so none of these four controls is a one-line
edit. findFiles in apps/storybook-react/checks/repo.ts:31 returns [] for a missing directory as
well as an empty one, and .storybook/main.ts globs ../src/**/*.stories.@(js|jsx|mjs|ts|tsx), so the
browser project's test list is empty too. Every one of the four checks reads stories. Reaching the
outermost real input therefore means creating a file, not changing a line in one.

Per § 4 of the opener, that is the finding rather than a reason to fall back to each check's entry point.
The control still goes in at the outermost real input: the file the check's caller walks. The designs below
each create one file, except 43021, which needs two. Each design also names the one-line form the control
takes once the first real component and story land, because that form is what run 4 should use.

packages/ui-react/src/ carries no .tsx either. It holds three design contracts, three screenshots,
index.ts, lib/utils.ts and styles.css.

43021 — every component prop has an `argTypes` entry

1. Input at run time. Two file sets, both read by realTreeGaps() in
apps/storybook-react/checks/arg-types.test.ts:179-182:

packages/ui-react/src/**/*.tsx — the component sources, matched by /\.tsx$/.
apps/storybook-react/src/**/*.stories.{ts,tsx} — the stories.

Both are empty today: the first directory exists and holds no .tsx, the second does not exist. The check
reads source text through the TypeScript AST and executes nothing, so the story's import does not have to
resolve for this control to work.

2. The edit. Two files, because one alone leaves the other set empty and the loop still runs zero times.

packages/ui-react/src/control-probe/ControlProbe.tsx:

export type ControlProbeProps = { label: string }

export function ControlProbe({ label }: ControlProbeProps) {
	return <span className="dxp:font-body">{label}</span>
}

apps/storybook-react/src/stories/ControlProbe.stories.tsx:

import { ControlProbe } from '@repo/ui-react'

export default { title: 'COMPONENTS/control-probe', component: ControlProbe, argTypes: {} }
export const Probe = {}

Give this story no tags. realTreeGaps() reads every story file regardless of tags, and leaving
test off keeps 43022 from firing on the same file — runsInVitest returns false, so the story owes no
snapshot. 43028 stays green for a different reason: it keys on the re-exports in
packages/ui-react/src/index.ts, not on the directories on disk, and this control adds no barrel line.
So the run fails on exactly one assertion.

3. What it must print. checks project, arg-types.test.ts › holds for every story this repository ships, with formatArgTypeGaps as the message:

1 prop has no usable argTypes entry:

  ControlProbe.label has no argTypes entry in apps/storybook-react/src/stories/ControlProbe.stories.tsx

The place it must name is the repo-relative story path, produced by repoPath() in
checks/repo.ts:22. A message that names the component file, or an absolute path, or a path relative to
apps/storybook-react, is a finding about the check.

Two nearby variants are worth one run each, because they exercise different branches of
findArgTypeGaps: argTypes: { label: {} } must print has an argTypes entry that declares no control,
and argTypes: { label: { control: false } } must print is control: false with no description.

4. Revert. git clean -fd packages/ui-react/src/control-probe apps/storybook-react/src

One-line form after S1. Delete one argTypes entry from the first real story's meta.

43022 — every `test`-tagged story takes a snapshot

1. Input at run time. Two, read at apps/storybook-react/checks/story-snapshots.test.ts:142-143:

apps/storybook-react/src/**/*.stories.{ts,tsx} — missing, so findFiles returns [].
apps/storybook-react/.storybook/preview.ts, through previewTags() in checks/repo.ts:101. This one
exists and yields ['autodocs']. It throws rather than returning [] when it cannot read the preview
object, so it is not the vacuous half.

2. The edit. One file, apps/storybook-react/src/stories/SnapshotProbe.stories.tsx:

export default { title: 'DEMOS/snapshot-probe', tags: ['test'], render: () => <div className="dxp:font-body" /> }
export const Probe = {}

combineStoryTags folds ['autodocs'] from the preview with ['test'] from the meta, runsInVitest
returns true, and no play function means takesSnapshot is false. The story names no component, so
43021 skips it — componentName is null.

Pin the run to --project=checks. Without the pin the browser project renders this story too, and 43023
and 43024 then have an opinion about it.

3. What it must print. checks project, story-snapshots.test.ts › holds for every story this repository ships, with formatMissingSnapshots as the message:

1 story runs in vitest and 0 of them takes a DOM snapshot. 1 story renders and snapshots nothing:

  Probe in apps/storybook-react/src/stories/SnapshotProbe.stories.tsx

It must name the exported story name and the repo-relative file, and the counts must read 1 and 0. A
message that reports the file but not Probe is a finding: the check's own unit is the story, not the
file, and a file with four stories and one gap has to say which.

4. Revert. git clean -fd apps/storybook-react/src

One-line form after S1. Delete the snapshot helper call from one real story's play function.

43023 — every component root carries `dxp:font-body`

1. Input at run time. Not a file set. The input is the canvasElement of every story the
storybook vitest project renders, handed to assertFontBodyOnRoots by the afterEach in
apps/storybook-react/checks/story-annotations.ts:17, which .storybook/vitest.setup.ts composes into
the project annotations. Which stories render is decided in two steps: .storybook/main.ts globs
apps/storybook-react/src/**/*.stories.@(js|jsx|mjs|ts|tsx), then storybookTest filters that list by
storyTagFilter from checks/story-tags.ts. The directory is missing, so the list is empty and the
afterEach never runs.

The assertion reads canvasElement.children — the element children of the canvas, one check per root.

2. The edit. One file, apps/storybook-react/src/stories/FontProbe.stories.tsx:

export default { title: 'DEMOS/font-probe', tags: ['test'] }
export const Probe = { render: () => <div>probe</div> }

The root <div> carries no class at all. Run with --project=storybook; the checks project would
otherwise fail 43022 on the same file and bury the signal.

3. What it must print. The storybook project fails the story DEMOS/font-probe with:

Story <story id>: the component root <div> does not carry dxp:font-body.

Every component root carries it, so the component renders the brand typeface wherever it lands, slot
content included, and the library never claims the host page's body. See
docs/adr/0005-page-default-typeface-is-a-brand-value.md.

class=""

Two places must be named and they are named by different mechanisms. The message itself names the story
id Storybook derives from the title, plus the tag of the offending root and its class attribute. The
file comes from vitest's own reporter, not from the message. Check both: a message that names the story but
prints the wrong tag, or that prints a non-empty class=, is a finding about which element
componentRoots() selected.

Add <div><span>probe</span></div> as a second run. The assertion must still name <div> — the root,
not the descendant. If it names <span>, componentRoots() is walking deeper than the canvas children.

4. Revert. git clean -fd apps/storybook-react/src

One-line form after S1. Delete dxp:font-body from the first real component's root className.

43024 — every interactive element has an accessible name

1. Input at run time. The same canvasElement, through the same afterEach in
checks/story-annotations.ts:17, reaching assertInteractiveElementsNamed. The two assertions differ in
what they walk: 43023 takes canvasElement.children, 43024 takes canvasElement.querySelectorAll('*') —
every descendant. Same empty-story-list reason for being vacuous today.

2. The edit. One file, apps/storybook-react/src/stories/NameProbe.stories.tsx:

export default { title: 'DEMOS/name-probe', tags: ['test'] }
export const Probe = {
	render: () => (
		<div className="dxp:font-body">
			<span tabIndex={0} />
		</div>
	),
}

Three things in that snippet are load-bearing, and dropping any of them gives a green or a wrong failure.

The root keeps dxp:font-body. assertComponentRoots calls assertFontBodyOnRoots first
(checks/component-root.ts:139-141) and it throws, so a root without the utility fails 43023 and you
learn nothing about 43024.
The span carries tabIndex, not role="button". A role="button" with no name is flagged by axe's
own rule, and preview.ts runs a11y with test: 'error', so the story would fail and the message might
be axe's. An unnamed focusable span with no role is the case axe stays silent on — which is run 2's
actual defect and the reason this check exists.
The span is empty. computeAccessibleName runs the real accname algorithm, so any text content,
aria-label or aria-labelledby satisfies it.

Run with --project=storybook, same reason as 43023.

3. What it must print.

Story <story id>: <span> is declared interactive and has no accessible name.

Give it an aria-label, an aria-labelledby pointing at visible text, or text content of its own. axe does
not flag this — it reported nothing for run 2's unnamed icon-only badge — so the a11y gate passing is not
evidence here.

<span tabindex="0">

The place is the story id plus the element description from describe() in
checks/component-root.ts:163, which prints every attribute except class. The tabindex="0" must
appear: it is what identifies which of the four interactivity signals fired.

declaresInteractive has four independent branches and one control exercises one of them. Three more
one-line variants, each worth its own run:

<a href="#" /> — the native branch. <a /> with no href must not fail; that is the negative half.
<span role="button" /> — the ARIA-role branch. Expect axe to fail this story as well; the control
passes if 43024's message is among the failures.
<span onClick={() => {}} /> — the React-handler branch, which reads the __reactProps$ internal
property. This is the one to run first after any React upgrade. If it goes green, the internal was
renamed and the branch is dead, and that is a finding worth more than the control.

4. Revert. git clean -fd apps/storybook-react/src

One-line form after S1. Delete the aria-label from the first real icon-only element.

What none of these four controls proves

They prove the four callers reach a real defect and name it. They do not prove the callers read the whole
tree. findFiles skips node_modules and dist, and a component placed outside
packages/ui-react/src/ or a story outside apps/storybook-react/src/ is invisible to 43021, 43022 and
43028 alike, silently. Testing that needs a different control, and it is not one of these four.

The four positive controls are designed — last pre-dispatch item closed

ds-positive-controls posted all four at
comment 5685412588. None blocked.
Nothing was run, edited or committed, which was the scope.

Three claims re-measured here against f77ee51, not read from the report:

apps/storybook-react/src/ does not exist. git ls-tree returns nothing for that path.
packages/ui-react/src/ holds no .tsx: index.ts, lib/utils.ts, styles.css, and generated contracts and
screenshots.
43023 is evaluated before 43024. checks/component-root.ts:140-141 — assertComponentRoots calls
assertFontBodyOnRoots and then assertInteractiveElementsNamed, and story-annotations.ts puts the combined
caller on every rendered story. A control root without dxp:font-body aborts before 43024 is reached.

The opener was wrong on one point and the session was right to say so. Its bar asked for "the exact one-line
edit". No control can be one line at f77ee51, because the tree is empty: there is no component and no story to
break. Each control creates a file; 43021 creates two. Every design now carries both forms, the create-a-file one
for today and the one-line one for after the first component and story land. This is the same fact the register
records from the other direction — on develop every real-tree caller in checks/ reads an empty set twice over.

What the four controls do not prove, reported by the session and worth more than any of them: they prove each
caller reaches a defect and names it, not that it reads the whole tree. A component outside
packages/ui-react/src/ or a story outside apps/storybook-react/src/ is invisible to 43021, 43022 and 43028
alike, and silently. No control covers that. It belongs in run 3's write-up as a known blind spot of the
instrument, not as a finding about the run.

Run 3 has no open preconditions

The seal's shape is ruled, PR #466 is merged, and the four controls are designed. What remains is the dispatch
itself: the four non-ticket steps in this ticket's body, the seal written to
~/Desktop/run3-sealed-predictions-<date>.md, and a session rooted in the Consumer at f77ee51 or later.

Environment rebuilt, Consumer baseline moves to `ddefc51`, run 3 has no open precondition

The host was replaced by a virtual machine, so every environment fact was re-measured rather than inherited.

Consumer PR 5876 merged 2026-09-16 as ddefc51, under new Task 43094 (parent 43033, Resolved). Five changes:
.nvmrc = 24.20.0; useNodeVersion: 24.15.0 → nodeVersion: 24.20.0; engines.pnpm = >=11.1.1; the
estimations comment verbatim; and README.md / CLAUDE.md stop naming versions at all.

Why that PR existed. useNodeVersion is not a key pnpm 11 reads — it warned and was ignored — so the Node pin
had no reader, and its value was wrong as well: runs 1 and 2 ran on 24.20.0, not the 24.15.0 the file declared.
engineStrict: true was already on and enforcing nothing about pnpm, because engines named only Node. Both are
the shape this stream keeps finding: a key that reads as governing something and governs nothing.

Two measurements worth keeping. .nvmrc now drives the whole chain — mise installs 24.20.0 and the shell,
pnpm exec and scripts all report v24.20.0. And engines.pnpm was proved able to fail before it was trusted:
set to >=99.0.0 it exits 1 with ERR_PNPM_UNSUPPORTED_ENGINE naming the version, and passes again at >=11.1.1.
A third edit was dropped for the right reason: managePackageManagerVersions does not exist in pnpm 11 and
would have written a second dead key into the file the PR exists to clean.

What the seal must record about the toolchain. Node is "24.20.0, the host's nvm default, measured on the host
2026-09-15" — not "the version the repo asked for". The pnpm that runs 1 and 2 used is unknowable:
lockfileVersion 9.0 is identical on develop, run 1's branch and run 2's branch, and that format spans pnpm 9,
10 and 11. Note both; compare neither.

Environment state for dispatch, all re-measured:

archon v0.8.0, pinned deliberately — v0.9.0 is gated on Archon 0.9.0 stops workflow nodes inheriting MCP servers — every Box loses its tracker/docs/design access on upgrade #425 (OPEN, p1), latest is v0.10.1.
unic-archon-dlc 0.28.0, scope project, enabled. Do NOT run /unic-archon-dlc:setup: .archon/ is 27 tracked
files whose Boxes are byte-identical to the 0.28.0 cache apart from one header line, so setup already ran and its
output travelled with the repo.
Playwright warm: chromium-1223, chromium_headless_shell-1223, ffmpeg-1011.
MCP figma and atlassian work in a fresh non-interactive session. claude mcp list reporting
⏸ Pending approval is a health-check artefact, not a block.
Runs 1 and 2's evidence survives on origin only, not on disk: archon/task-unic-dlc-build-1787780831333
(b8bb033, +23), feature/43004_build-profile-card (5e683a7, +16, the five unmerged fixes),
feature/42999_run2-profile-card (d09feff, +1). The old warning about 28 dirty worktrees no longer applies —
there is one worktree — but a remote deletion is now unrecoverable where a local one used to be survivable.

What remains is the seal and this ticket's opener. No ticket blocks either.

Correction to the ruling comment: a positive control is not a one-line edit

Comment 5683363982 says each of
the four owed controls "is a one-line edit, a run, and a revert". That is wrong on this tree and was already wrong
when it was written. The sentence is mine, not the maintainer's: he ruled the seal's shape, not that phrasing.

Comment 5685412588 measured it the
same day. apps/storybook-react/src/ does not exist at f77ee51 and packages/ui-react/src/ holds no .tsx, so
no control is a one-line edit today: each creates a file, and 43021 creates two. The one-line form is what a
control becomes once the first component and story land, which is the tree run 3 leaves. Every design carries both
forms for that reason.

Raised by wayfinder-orchestrator-9, which reached the ruling comment before the correction and would have
inherited the wrong instruction. Two other sentences in that comment stand unchanged: a check with no working
control scores inert, never pass; and 43020 is not a barrel append, because uiReactStyleSheets() throws on
empty input.

Which set "one arm per mechanism" means. The ruled shape never enumerated it, and this stream's own rule says a
quantifier over a set of mechanisms is an unverified claim per member until each member is named. So: the six
shipped checks — 43020, 43021, 43022, 43023, 43024 and 43028 — one arm each. Each has a named run-time input, a
named expected failure message and a designed control, which is what makes the cell defect present, check silent
decidable by observation.

Register § F1 lists eight rows, not six. The seventh is 43022's second half, which is part of that check. The
eighth is 43025, New and never built, so it takes no arm: a defect it would have guarded belongs in the second
arm, the defects no mechanism guards. Prose rules belong there too, because a prose rule has no firing event and
the whole point of an arm is to predict the firing separately from the defect.

How to start this session — run 3 dispatch

Written 2026-09-16 by wayfinder-orchestrator-9. Edited in place 2026-09-16 15:30 CEST by
wayfinder-orchestrator-10, before any session read it: the report address in § 9 (seat 9 is gone), and one
measured line added to § 5 B. Nothing else changed. Superseded in part by comments 5698892549 (§ 5 C: the six generated files
are deleted too) and 5698999496 (the specs leg restarted in a fresh session; inherited state, fork point 5e39db6).
Read both after this. This is the newest opener on this ticket; if an older one exists above, this one governs.

1. What this session produces, and what to invoke

It produces a run, not a merge. Run 3's build is measured and then abandoned, the way runs 1 and 2
were. Nothing here ends in a merged pull request, so do not optimise the product.

Work from a session rooted in the Consumer's clone. The plugin is installed at project
scope, so the DLC commands exist only there. Dispatch /specs → /tickets → /build, in that order.

Three things not to invoke, each for its own reason:

Do not run /unic-archon-dlc:setup. Measured 2026-09-16: .archon/ is 27 tracked files, clean,
and all four Box YAMLs begin # Generated by unic-archon-dlc 0.28.0 — /unic-archon-dlc:setup replaces this file on every run. Setup already ran and its output is committed. Running it rewrites the four
Boxes and dirties the baseline this run is scored against.
Do not enter with /wayfinder. That is the plugin repository's map entry. This ticket's work
happens in the Consumer.
Do not upgrade Archon. It is v0.8.0, linux-arm64. 0.9.0 stops workflow nodes inheriting
ambient MCP servers and no Box declares mcp:, which is filed as Archon 0.9.0 stops workflow nodes inheriting MCP servers — every Box loses its tracker/docs/design access on upgrade #425 — OPEN, p1, untouched since
2026-08-25. Upgrading mid-run swaps the binary under a live run.

2. Read these, in this order

The sealed predictions, ~/Desktop/run3-sealed-predictions-2026-09-16.md. Sealed 2026-09-16
14:55 CEST. Read it first because it tells you what this run is for and what it may not measure. Do
not edit it. A wrong prediction is scored wrong, never rewritten.
This ticket's body, for the six steps and the confound it names.
docs/research/2026-08-31-dlc-run-2-findings.md in the plugin repository, § F1 and § F5. F1 maps
each run-2 defect to the mechanism that now guards it. F5 is what building the sixth check taught.
Comment 5685412588
— the four positive-control designs, and
comment 5697666755,
which corrects the ruling comment above it. Read the correction before the ruling.
docs/agents/unic-archon-dlc.md in the Consumer, § Three Archon defects that land here →
§ Recovering a killed run. Cited, not restated.

3. The one trap that costs an hour

artifacts_dir is workflows, and two files under it are tracked on develop.

.archon/unic-dlc.config.yaml:165 sets artifacts_dir: workflows. The standing cleanup rule says:
harvest <artifacts_dir>/<slug>/ out of a worktree before removing it, because every Box writes outward
last and a terminal run is usually complete-and-unconsumed. Here that rule reads as an instruction to
rescue workflows/profile-card/PRD.md and workflows/profile-card/issues.json, and step 3 of this
ticket tells you to delete those same two paths.

Both are right. They name the same path and mean opposite things:

Tracked on develop — run 2's committed leftovers. Delete them, on the run's branch. They
exist to be deleted: leaving them makes /specs and /tickets re-enter instead of deriving.
Inside an archon/task-* worktree — this run's own artefacts. Harvest them. Never complete a
run whose output was never consumed. Status: failed says nothing about what is on disk.

Only the second kind is an artefact. Getting this backwards either destroys the run's product or leaves
the re-entry trap armed.

4. The decision this ticket does not make

Where the four positive controls' files land.

The controls are designed and none has been run. Two facts collide, and this ticket settles neither:

No control is a one-line edit today. apps/storybook-react/src/ does not exist and
packages/ui-react/src/ holds no .tsx, so every control creates a file, and 43021 creates two.
The seal is scored against the run's diff. Control files in that diff are not the run's work, and
a scorer reading the diff afterwards cannot tell them apart from what the implementer produced.

Two competent implementers would split here: one commits the controls on the run's branch because that
is the tree the controls must execute against, the other keeps them off it to protect the measurement.

Recommendation: run each control on a scratch branch forked from the run's tip, never on the run's
branch. Create the file, run the check, capture the output, delete the branch. The control still
executes against the tree run 3 leaves, which is the requirement, and the run's diff stays clean. Record
each control's output in the run record verbatim.

A check whose control does not make it fail scores inert, never pass. Otherwise "the mechanism
fired and found nothing" and "the mechanism was dead" read identically. That distinction is what run 3
is for.

5. Before dispatch, in order

A. Park the live memory. .remember/ exists in the Consumer, untracked, holding now.md,
recent.md, archive.md and today-2026-09-15.done.md. Run 2 measured with those directories absent;
a run 3 that can read them measures a different chain. Move it, do not delete it:

mv .remember ~/Desktop/run3-parked/remember-2026-09-16

~/Desktop/run2-parked/ already holds dxp-memory, remember, remember-attempt2 and
remember-attempt3 from the previous run. Keep run 3's parking separate from run 2's.

B. Verify Node, and stop if it is wrong. This is the step most likely to be skipped and it decides
whether the run is comparable at all. Measured 2026-09-16, inside the Consumer:

node --version                    → v24.15.0
pnpm exec node --version          → v24.15.0
bash -lc 'cd <consumer> && node --version'  → v24.15.0
mise exec -- node --version       → v24.20.0

The repository declares 24.20.0 in .nvmrc and in pnpm-workspace.yaml's nodeVersion. mise is not
activated in any shell rc file, so PATH carries a static install directory that never re-resolves per
directory. pnpm self-switches correctly because package.json carries
"packageManager": "pnpm@11.1.1"; Node has no equivalent self-switch.

nodeVersion governs lifecycle scripts, and pnpm exec is not one, so the question is still open.
~/.local/share/pnpm/nodejs does not exist, which means no pnpm run on this machine has ever fetched
24.20.0.

Measured 2026-09-16 15:25 CEST by wayfinder-orchestrator-10, inside the Consumer: pnpm node --version reads
v24.15.0, and ~/.local/share/pnpm/nodejs is still absent afterwards. pnpm 11.0's release notes list the Node
version execution setting among the removed features; nodeVersion in pnpm-workspace.yaml is the version pnpm
uses for the engines check, not the Node that runs. Run steps 1 and 2 anyway and quote what they print.

So, before dispatch:

Run one lifecycle script through pnpm and capture the Node it executed under.
Check whether ~/.local/share/pnpm/nodejs now exists and which version it holds.
Paste both outputs into the run record. Quote the runner's output. Never assert the version.
If the checks execute under 24.15.0, stop and say so. Do not dispatch. Run 3 would be measuring a
repository that declares one version in three places and runs another.

C. Make the run's branch and delete run 2's artefacts on it. Consumer convention is
feature/<WI#>_<slug>, and the work item exists: 43033, Active, 13 points, Feature 42975.
Baseline: ddefc51 on origin/develop, or later. Re-measure it and record what you get.

Delete workflows/profile-card/PRD.md and workflows/profile-card/issues.json on that branch, in
separate commits, as run 2 did — d09feff on its setup branch, then 86bda53 and ec6abb9 again on
its build branch. Run 2 deleted them twice. Read that as the requirement: whichever branch the build
actually forks from must carry the deletion. Verify it on the fork point, not on the branch you typed.

The three contract.generated.md stay. They are at
packages/ui-react/src/{badge-main,card-profile-main,icon/interface/User2}/contract.generated.md, and
/specs overwrites them. Deleting them removes the baseline still being compared against.

D. Confirm the seal. ~/Desktop/run3-sealed-predictions-2026-09-16.md must read
Status: SEALED before anything is dispatched.

6. Other traps

--branch does not reuse a branch. Archon always creates archon/task-*. --from sets the fork
point. Getting this wrong produces a run that reviews an empty diff and looks fine.
Invoke Archon from the registered clone, never from a sibling worktree. It pins one source symlink
per repository and refuses a second path with exit 0.
A run executes the Box from the invocation directory's working tree, not from the branch. --from
checks the branch out, then overwrites the worktree's tracked .archon/ from the invocation
directory.
Dispatch detached or harness-tracked, never as a shell & child. An interactive interrupt kills
the process group, and a paused run that should wait indefinitely dies instead.
Never reject a gate. /pr-review's review-gate has no on_reject and a reject destroys every
finding with no record. /qa's uat-gate on_reject files work items on the Consumer's tracker.
Approve from the terminal — archon workflow approve <id> approves and resumes; approving in the
UI records approved and leaves the run paused forever.
Never force-delete a remote branch here. Runs 1 and 2 survive only on origin now, so a remote
deletion is unrecoverable where a local one used to be survivable.
Poll archon workflow get <run-id>, never workflow status, when more than one run can be live.
running in Archon's database is not evidence a run is alive. Liveness is: the working path
exists and is a git repository.
archon --help hides approve, reject, resume and abandon. Absence from help is not
absence from the tool.
A crashed-at-gate run is abandoned, never resumed. resume walks through an unresolved approval
gate and has posted a whole review with no approval accepted.
Figma is not optional. /specs writes contract.generated.md with a provenance block naming the
Figma file key, page id, node id and asset key. Those do not come from reading code. claude mcp list
reporting ⏸ Pending approval for figma and atlassian is a health-check artefact, not a block —
both work in a fresh non-interactive session. Do not "fix" it via enabledMcpjsonServers.

7. The bar, and what a false pass looks like

DXP-DesignSystem has no CI of any kind and no branch policies. Nothing runs on a push. Every green
claim about this repository came from a person running the checks by hand in a real clone.

Four of the eight commands sdlc_needs declares cannot report a failure: lint
(eslint-plugin-only-warn downgrades every rule), format (prettier --write rewrites and exits 0),
coverage (Unknown% (0/0)), and test while the suite is empty (passWithNoTests: true). Evidence
on #463.

test and check-types are the two that mean something — test only once this run's own tests
exist, which is the reading that reconciles the two statements above; flag it if you find it wrong.

So: a session reporting "lint, format and coverage all green" has measured nothing. That is the
false pass. Capture exit codes separately from output, and quote the runner rather than asserting what
it said. A number written from memory is not evidence, whether or not it was ever true. On PR 5843 a
description claimed 12 tests while the file ran 16, because a later commit falsified the author's own
evidence row and two re-reads missed it. With no CI here, the pull request description is the only
record that a check ran, so a description patched rather than rewritten is an unversioned test report
nobody re-runs.

8. On landing

Run 3's product is discarded by design. So "landing" means the measurement is complete, not that
anything merged.

Harvest before you complete anything. Copy workflows/<slug>/ out of the worktree before
archon complete <branch> --force. Every Box writes outward last, so a killed run is
complete-and-unconsumed with high probability.
Abandon the pull request, keep the branch. PR 5807 and PR 5835 were both abandoned with their
branches kept. That is the pattern.
Do not fix what the run produced. Runs 1 and 2 are measured artefacts and five real fixes sit
unmerged on run 2's branch deliberately.
Name the baseline as a commit, never as "develop was empty". That is an acceptance criterion on
this ticket.
Leave scoring to the orchestrator. It is scored against the run's diff and the check output, never
against the run's own report.

9. Report back

Report to wayfinder-orchestrator-10 when each leg finishes, and immediately if any of these happens:

A check fires that the seal predicted silent, or stays silent where the seal predicted it fires.
A positive control fails to make its check fail.
Node resolves to 24.15.0 at step 5B.
A run reaches a gate, or dies at one.

Say what command produced each claim. When you are told something, ask the same. A peer's
correct-sounding report has been wrong here before.

Two findings this run may surface that are properties of the instrument, not of the run, and the
write-up must say so either way: a component outside packages/ui-react/src/ or a story outside
apps/storybook-react/src/ is invisible to 43021, 43022 and 43028 at once, silently; and
assertComponentRoots calls 43023 before 43024, so a root missing dxp:font-body aborts before 43024
is reached — on that story 43024 is unobserved, not silent.

Run 3 dispatched — 2026-09-16 15:29 CEST

The maintainer authorised the dispatch. ds-run-3-1, a session rooted in the Consumer, proceeds from § 5 C of the
opener above: branch from ddefc51 under WI 43033, delete run 2's two tracked files on that branch, then /specs
→ /tickets → /build. It reports to wayfinder-orchestrator-10.

§ 5 B, the Node stop condition, did not trigger. Measured by ds-run-3-1 with a throwaway node-probe script,
reverted afterwards, tree clean at ddefc51:

$ pnpm run node-probe
v24.20.0 @ /home/otf/.local/share/mise/installs/node/24.20.0/bin/node
exit=0
$ pnpm --filter @repo/storybook-react run node-probe
v24.20.0 @ /home/otf/.local/share/mise/installs/node/24.20.0/bin/node
exit=0
$ ls -la ~/.local/share/pnpm/nodejs
ls: cannot access '/home/otf/.local/share/pnpm/nodejs': No such file or directory

What supplies 24.20.0 is mise's shim reading .nvmrc, not the repository. pnpm downloaded nothing. pnpm 11.0's
release notes list the Node version execution setting (useNodeVersion) among the removed features, and
nodeVersion is the version pnpm uses for the engines check. So nodeVersion: 24.20.0 in pnpm-workspace.yaml
is a pin with no reader, and its comment is wrong. Consumer PR 5876 replaced one dead pin with another.

The seal's 15:05 amendment predicted the stop condition would come back 24.15.0. It came back 24.20.0 because the
session was launched from inside the Consumer, where mise's PATH entry already resolves .nvmrc. A session
launched elsewhere carries a static installs/node/24.15.0/bin entry ahead of the shims and reads 24.15.0. Both
readings were correct for their own sessions.

Ruled: not fixed before dispatch. The run executes under the declared version, which is what comparability
needs, and moving the baseline would buy no measurement. The dead pin becomes a register row after run 3 and rides
a later Consumer PR: devEngines.runtime with onFail: download in package.json is the pnpm ≥ 10.14 mechanism.

.remember parked at ~/Desktop/run3-parked/remember-2026-09-16.

Correction to the opener's § 5 C: the three design contracts do NOT stay

The opener (comment 5697784039)
says "The three contract.generated.md stay … /specs overwrites them. Deleting them removes the baseline still
being compared against." Both halves are wrong, and the maintainer caught it at halt 1 of the specs leg.

Run 2 deleted them. Its setup commit removed eight files, not two:

$ git show --stat d09feff
d09feff 2026-08-29 chore(42999): delete run 1 generated artefacts before run 2
 .../ui-react/src/badge-main/contract.generated.md  | 127 --------------
 .../src/badge-main/screenshot.generated.png        | Bin 2645 -> 0 bytes
 .../src/card-profile-main/contract.generated.md    | 193 ---------------------
 .../src/card-profile-main/screenshot.generated.png | Bin 174424 -> 0 bytes
 .../src/icon/interface/User2/contract.generated.md | 119 -------------
 .../icon/interface/User2/screenshot.generated.png  | Bin 2132 -> 0 bytes
 workflows/profile-card/PRD.md                      | 147 ----------------
 workflows/profile-card/issues.json                 |  66 -------

86bda53 and ec6abb9 on the build branch repeated only the PRD and issues.json deletions, which is where the
"two files" reading came from. The chain run 2 measured started with no generated file in the tree.

Deleting them loses no baseline. Run 1's contracts are addressable at a71e19f, run 2's at 5e683a7 and on
develop at ddefc51. Git history is the comparison surface; the working tree is the instrument's input.

Why it matters for run 3. /specs Step 2 keys re-entry on PRD.md only, and the Consumer's CLAUDE.md:303 says
the contract is "replaced whole on every run", so the contracts do not trigger a re-entry. They still sit in the
tree /specs reads, and a session that lists or opens them is measuring a different chain from run 2's. That is the
contamination the maintainer named.

Ruling. Delete all six generated files on feature/43033_dlc-run-3 in one commit, as d09feff did, before
/specs writes anything. The correct § 5 C reads: delete workflows/profile-card/PRD.md,
workflows/profile-card/issues.json, and every *.generated.* under packages/ui-react/src/. Verify with
git ls-tree -r --name-only <branch> | grep -E '\.generated\.|^workflows/' printing nothing.

The specs leg was at halt 1 when this was caught. Whether it restarts in the same session or a fresh one is the
maintainer's call and is recorded in the next comment.

Raised by the maintainer, measured and posted by wayfinder-orchestrator-10, 2026-09-16 16:15 CEST. The opener's
§ 5 C is stale on this point and this comment governs.

Specs leg restarts in a fresh session — ruled 2026-09-16 16:17 CEST

The first Consumer session, ds-run-3-1, read packages/ui-react/src/card-profile-main/contract.generated.md in
full at 15:35 to ground the interview, before the correction above landed. Deleting the file does not remove what
the session loaded, so a /specs restart there would run with run 2's output in context. The maintainer closes
that session and opens a fresh one, DS-Run-3-2, for the specs leg.

State the fresh session inherits, all verified on origin:

$ git ls-remote --heads origin 'refs/heads/feature/43033*'
5e39db69db2bf96f35b0085f246487ecc2f78d86	refs/heads/feature/43033_dlc-run-3-01
$ git ls-tree -r --name-only feature/43033_dlc-run-3-01 | grep -E '\.generated\.|^workflows/'
(no output)

Branch feature/43033_dlc-run-3-01 at 5e39db6: ddefc51 plus three deletion commits (c78cb8e PRD,
f2ed42a issues.json, 5e39db6 the six generated files). The build forks from 5e39db6. The maintainer
renamed the branch from feature/43033_dlc-run-3 and deleted the old name from origin himself; the § 6 rule
protects run 1 and run 2 artefacts, and none was touched.
.remember parked at ~/Desktop/run3-parked/remember-2026-09-16.
Run record at ~/Desktop/run3-parked/run-record-2026-09-16.md, carried over from the first session. It holds the
§ 5 B Node probe, the contracts correction and the context note. The fresh session appends to it.
pre-push installed in the clone at .git/hooks/pre-push.
No /specs output exists: no PRD, no contract, no screenshot.

Scoring note for later: the run's diff against develop will show the three setup deletions beside the run's own
work. They are preparation, not product, and the scorer reads them out.

Specs leg done; the build forks from `develop` at `404f5ba`, not from `5e39db6`

/specs profile-card finished in ds-run-3-2 at 17:48 CEST. Its summary, quoted:

  halts:     Halt 1 answered · Halt 2 answered (answered twice; both recorded)
  gate:      open-pr → PR 5879
  contracts: 3 written
  ADRs:      0007-card-parts-carry-shadcns-generic-names.md
             0008-a-presentational-component-still-owns-its-accessible-state.md
             0009-an-icon-is-a-react-component-not-a-sprite.md
  blocked:   none

The maintainer merged PR 5879 at 17:56. Verified on origin:

$ git rev-parse --short origin/develop
404f5ba   Merged PR 5879: plan(43033): PRD and ADRs
$ git merge-base --is-ancestor 2817fe1 origin/develop && echo yes   # yes
$ git merge-base --is-ancestor 5e39db6 origin/develop && echo yes   # yes
$ az repos pr show --id 5879 --query status   # completed

Why merge, when the run is discarded by design. Run 2 did the same: its plan commits b970178, 675e70f and
a0105b5 are in develop, and its build forked from develop after them (merge-base 5b568bc). Only the
setup deletion d09feff never merged, as 5e39db6 now sits unmerged on feature/43033_dlc-run-3-01. "Discarded"
names the build.

Consequences for the rest of the run, superseding comment 5698999496 on this point:

/tickets and /build run from develop at 404f5ba. The baseline named in the write-up stays ddefc51.
workflows/profile-card/PRD.md on develop is run 3's product now. The opener's § 3 rule about deleting
tracked files under artifacts_dir applied to run 2's leftovers and is spent.
Halt 2 was answered twice: the maintainer approved a first seam set, then had the session widen it with a
document-order and a comparative geometry assertion (the WI 43025 form, no number named) so that the
arrangement the contracts record has a criterion. Recorded in the PRD's ## Confirmations with both answers,
and in the seal's amendments as a human intervention that alters no prediction.
Two facts for the register: the azure-devops MCP rejects a pull-request description over 4000 characters as
too_big; and Confluence page 973276506 had no children before this run, so its three component pages were
created, not overwritten. Publishing ran, four pages; the PRD landed in a DS-PRDS folder the maintainer
created mid-run because nothing in the repository says where a PRD goes. That gap is open.

wayfinder-orchestrator-10, 2026-09-16 18:00 CEST.

How to start the build-leg session — run 3, third Consumer session

Written 2026-09-16 18:50 CEST by wayfinder-orchestrator-10. The specs and tickets legs ran in ds-run-3-2,
whose context is spent; the build leg starts in a fresh session. This comment is that session's opener. It
supplements comment 5697784039
and overrides it where the two disagree.

1. What this session produces, and what to invoke

A build run, four positive controls, and a run record. Nothing merges. The build's pull request is abandoned
with its branch kept, the way PR 5807 and PR 5835 were.

Work from a session rooted in the Consumer's clone, on develop. Dispatch the Box directly:

archon workflow run unic-dlc-build "profile-card"

gates.build is afk in .archon/unic-dlc.config.yaml:91, so build-pr-gate does not pause. Dispatch it
harness-tracked (run_in_background), never as a shell & child. Do not run /unic-archon-dlc:setup, do not
upgrade Archon (v0.8.0 stays; the CLI offers 0.10.1 and #425 gates any move), do not enter with /wayfinder.

2. Read these, in this order

~/Desktop/run3-parked/run-record-2026-09-16.md — the record of the two earlier sessions. Append to it;
never rewrite a line. Your scratchpad dies with you, so nothing may live only there.
Comment 5697784039, sections 3, 6, 7 and 8. Skip its § 5: done.
Comments 5698892549, 5698999496, 5700490037 and the one after it — what changed since the opener was written.
Comment 5685412588, the
four positive-control designs for 43021 to 43024, and comment 5697666755 which corrects the ruling above it.
docs/agents/unic-archon-dlc.md § Recovering a killed run, in the Consumer.

Do not read: the seal (~/Desktop/run3-sealed-predictions-2026-09-16.md; it is for scoring), any output of
run 1 or run 2 at any commit (a71e19f, 5e683a7, run 2's branch), or run 3's own PRD, contracts and
issues.json beyond confirming they exist. The Box reads them; you watch the Box.

3. The state you inherit, verify it before dispatch

git fetch origin && git checkout develop && git pull --ff-only
git rev-parse HEAD            # 7f8fedd5d43f63e62a1a686f47be9a629b1769c1  (Merged PR 5880)
git status --porcelain        # empty
git ls-tree -r --name-only HEAD | grep -E '^workflows/'
                              # workflows/profile-card/PRD.md
                              # workflows/profile-card/issues.json
ls -d .remember               # record whether it exists; see § 6

Baseline for the write-up: ddefc51. Fork point of the build: develop at 7f8fedd. Run 3's plan is on
develop by the maintainer's merges of PR 5879 (404f5ba) and PR 5880 (7f8fedd), the shape run 2 used.
feature/43033_dlc-run-3-01 at 5e39db6 holds the setup deletions and is left alone.

4. The one trap that costs an hour

workflows/profile-card/PRD.md and issues.json are tracked on develop and they are run 3's product. The
first opener's § 3 told the dispatcher to delete two tracked files under artifacts_dir; those were run 2's and
they are gone. Today the same paths are the build's input. Delete nothing under workflows/. Inside the
archon/task-* worktree, workflows/profile-card/<box>/ is this run's artefact: harvest it out before
archon complete <branch> --force, because every Box writes outward last and a terminal run is usually
complete-and-unconsumed. Status: failed says nothing about what is on disk.

5. Two decisions the tickets did not make

Where the four positive controls' files land. Run them on a scratch branch forked from the build's tip,
never on the build's branch. Each control creates a file (the tree had no .tsx and no
apps/storybook-react/src/ at ddefc51; after the build it may have both, and the designs carry both forms).
Create, run the check, capture the output verbatim, delete the branch. A check whose control does not make it
fail scores inert, never pass. A 43024 control root must carry dxp:font-body, or 43023 throws first and
43024 is never reached.

Where each slice's check output lives. All four slices run pnpm --filter @repo/storybook-react test --run,
the full three-project suite, so 43020 to 43028 fire on every slice. The scorer reads defect present off the
check output and the slice commits, not off the final diff. So before the run is complete, find where the
per-slice test output is kept (Archon run events, the verification node's node_output in
~/.archon/archon.db, the PR description) and write the exact location into the run record. Do not summarise
it. If it exists only in the database, extract it to ~/Desktop/run3-parked/ before archon complete.

6. Other traps

.remember/ reappears. The Remember plugin is enabled at user scope and recreates the directory minutes
after it is parked. Four sightings so far, each naming only run 3's own progress. Record each sighting with its
time and whether the content names run 1 or run 2 output; park it to ~/Desktop/run3-parked/remember-2026-09-16-<letter>
(next letter e). Do not change any settings during the run.
Registration. remote_agent_codebases in ~/.archon/archon.db had no row at 15:30. After dispatch, quote
sqlite3 ~/.archon/archon.db "select name, default_cwd, default_branch from remote_agent_codebases;".
default_branch should read develop, from the committed .archon/config.yaml.
Invoke from the registered clone, never a sibling worktree. A run executes the Box from the invocation
directory's working tree.
Poll archon workflow get <run-id>, never workflow status. running in the database is not liveness;
liveness is the working path existing and being a git repository.
Never reject a gate; approve from the terminal. A crashed-at-gate run is abandoned, never resumed.
Never force-delete a remote branch. Runs 1 and 2 survive only on origin.
lint, format, coverage cannot fail in this repository, and test cannot while the suite is empty.
test once this run's tests exist, and check-types, are the two that mean something. Capture exit codes
separately from output; quote the runner, never assert a count.

7. On landing

Harvest workflows/profile-card/ and the per-slice check output out of the worktree.
Run the four positive controls against the build's tip, on a scratch branch, and record each output.
Abandon the pull request, keep the branch. Fix nothing the run produced.
archon complete <branch> --force only after 1 and 2.
Name the baseline as ddefc51 and the fork point as 7f8fedd in the run record.
Leave scoring to the orchestrator.

8. Report back

Report to wayfinder-orchestrator-10 when the run dispatches (run id, fork sha, the codebase row), when it
reaches or dies at any node, when a control fails to make its check fail, and when the leg ends: expected,
observed, the command or file that proved it, and whether it changes this ticket only or every session here.
Say what command produced each claim.

How to start the review-leg session — run 3, fourth Consumer session

Written 2026-09-16 19:55 CEST by wayfinder-orchestrator-10. The build leg ran in ds-run-3-3; its run completed,
PR 5881 is open, everything is harvested, and the four positive controls passed. This comment is the review
session's opener. It supplements comment 5701100966
and the first opener, and overrides both where they disagree.

1. What this session produces, and what to invoke

One unic-dlc-pr-review iteration on PR 5881, harvested, and then the run's close-out. Nothing merges.

Work from a session rooted in the Consumer's clone, clone on develop at 7f8fedd. Dispatch
harness-tracked, from the clone root, the way runs 2 and 43028 did:

archon workflow run unic-dlc-pr-review "profile-card" --from archon/task-unic-dlc-build-1789577744739

gates.pr-review is afk (.archon/unic-dlc.config.yaml:93), so review-gate is skipped and post writes
threads to PR 5881 without a pause. The maintainer gave that go at 19:48. One iteration; a second is his call
after the first is read.

Do not run /unic-archon-dlc:setup, do not upgrade Archon (v0.8.0; the CLI offers 0.10.1 and #425 gates it),
do not archon complete anything, do not touch PR 5881 by hand, do not fix anything the run produced.

2. Read these, in this order

~/Desktop/run3-parked/run-record-2026-09-16.md — three sessions' record. Append; never rewrite a line.
This ticket's comments from 5701100966 down: the build dispatch, its failure and re-dispatch, and the
controls are recorded there and in the run record's ds-run-3-3 sections.
docs/agents/unic-archon-dlc.md in the Consumer, § Recovering a killed run, and its lines on the
 marker.

Do not read: the seal, report.md's § 5 findings, the precheck output, or any run 1 or run 2 artefact. The Box
reviews; you watch the Box. If you read the precheck's eleven findings you cannot report the review's dedup
against them without bias, and that number is one of the three the seal says compare with run 2.

3. The state you inherit, verify before dispatch

git -C ~/Sites/<customer>/DXP-DesignSystem rev-parse HEAD --abbrev-ref HEAD   # 7f8fedd…, develop
git -C ~/Sites/<customer>/DXP-DesignSystem status --porcelain                  # empty
git worktree list        # the clone, and the build worktree at 08e2523 on archon/task-unic-dlc-build-1789577744739
az repos pr show --id 5881 --query '{status:status,source:sourceRefName,merge:mergeStatus}' -o json
                         # active, refs/heads/archon/task-unic-dlc-build-1789577744739, succeeded
sqlite3 -line ~/.archon/archon.db "select name, default_cwd, kind, default_branch from remote_agent_codebases;"
                         # one row, kind repo, default_cwd the clone, default_branch develop
ls -d ~/Sites/<customer>/DXP-DesignSystem/.remember   # record the sighting, park to ~/Desktop/run3-parked/remember-2026-09-16-h

4. The one trap that costs an hour

prep finds the pull request by the current branch of the worktree Archon gives it. If the run's worktree is
not on archon/task-unic-dlc-build-1789577744739, prep finds no PR and the review reads an empty diff and looks
fine. So within the first minute after dispatch, quote the new run's working_path from
remote_agent_workflow_runs, git -C <working_path> rev-parse --abbrev-ref HEAD, and prep's output PR number.
If it is not 5881, abandon at once (archon workflow abandon <id>) and report.

The dispatch header must say a worktree is being created. "Folder project — running in place" means the codebase
registration regressed: abandon and report.

5. The decision this ticket does not make

Whether iteration 1 is enough. Run 2 had two review rounds; the seal marks dedup, reconcile and praise as
comparable. After post completes, report the summary thread's counts and the iteration marker, and stop. The
maintainer decides on a second iteration after reading the first. A second iteration would need the findings
addressed on the branch, and nothing the run produced is being fixed, so the default is one.

6. Other traps

Every Box writes outward last. post is node 8 of 8. Before any archon complete, harvest
<working_path>/workflows/profile-card/pr-review/ and the run's events and transcripts, exactly as
ds-run-3-3 did (see the run record for the paths and the ~/.claude/projects/ transcript directory keyed by
the worktree path). The database holds tool inputs, not output.
bug(unic-archon-dlc): /pr-review produced eight findings, wrote none, and exited 0 #465 shape: a review node can produce findings and write none, exiting 0; post then refuses with nothing
to say. Read synthesize's counts and reconcile's verdicts against the review node's own node_output
length. A zero-finding review on a nine-commit diff is a finding about the Box.
Never resolve the Box's summary thread on the PR. Never reject a gate (none is reached at afk).
.remember/ reappears minutes after parking, and the Box's own nodes write to it. Record each sighting.
Poll archon workflow get <run-id>, never workflow status.

7. On landing

Harvest, as above. Quote the inventory under ~/Desktop/run3-parked/.
Report the summary thread: findings per axis, confidence, iteration marker, and how many threads posted.
Do not abandon PR 5881 and do not archon complete until the orchestrator relays the maintainer's word on a
second iteration. Both worktrees stay.

8. Report back

Report to wayfinder-orchestrator-10 at dispatch (run id, working_path, branch, prep's PR number), at any failure,
and at the leg's end: expected, observed, the command or file that proved it, and whether it changes this ticket
only or every session here. Say what command produced each claim.

Run 3 is scored and written up — this ticket is done

The write-up landed on develop at bcf688a (PR #481): docs/research/2026-08-31-dlc-run-2-findings.md § "The sealed prediction, scored — run 3 (2026-09-16)" and § "G. What run 3 taught about the instrument".

Against the acceptance criteria:

Sealed before dispatch and quotable afterwards. ~/Desktop/run3-sealed-predictions-2026-09-16.md, Status: SEALED 14:55 CEST, arms 1 and 2 before any dispatch; arm 3 written after /specs was dispatched and before it reported, flagged as a weakened seal where it is scored.
Both legs read against them. Arm 1: 43020, 43024, 43028 held; 43021, 43022, 43023 wrong, every "defect present" prediction was absent. Arm 2: 12b, 25, 26 wrong (absent, absent, implemented-and-wrong on AC-22); the invented User2 glyph is the unguarded defect the list missed. Arm 3: five of five, weakened.
Which mechanisms fired, which did not, which could not be judged. None fired on GREEN; 43021 fired three times on RED for the story-before-component path; all six proved able to fail by positive control, so none scores inert. 43022's adjacent defect (a snapshot of the inner <span>) is present and outside what the check sees.
The new-infrastructure confound is stated, and a second one with it: the checks ran on every slice and the implementer read their source, so being run and being read are not separable in this run.
Baseline named as a commit: ddefc51; plan merged as 404f5ba and 7f8fedd; build branch archon/task-unic-dlc-build-1789577744739 at 08e2523, kept on origin; PR 5881 abandoned with six false fixed threads left as evidence.

The answer to F4: mechanisms reach the implementer where documents did not. The finding run 2 could not make: on a byte-identical commit the review Box marked six real findings fixed and resolved their threads. Table G lists eighteen instrument findings with their evidence and destination; each gets its own ticket.

Dispatch record: comments 5698289748 to 5701996755 above. Evidence: ~/Desktop/run3-parked/ (44 MB, run record 2323 lines). ADO 43033 stays the maintainer's to resolve.

Dispatch run 3, read both legs against sealed predictions, and write it up #457

Description

Question

Blocked by, and one edge GitHub cannot express

The steps, in order, and why each is here

Preconditions already met

The confound to state rather than discover

Acceptance criteria

Azure DevOps

Activity

orioltf commented on Sep 5, 2026

A third change reached run 3's baseline, and nobody chose it for this run

What it does, and what it costs

The ruling this needs, before dispatch

Second item from the same report, smaller

orioltf commented on Sep 5, 2026

Ruled: estimations stays 'both' for run 3

The one thing still outstanding from this

orioltf commented on Sep 5, 2026

A mechanism can read green by construction too, and run 3 cannot currently tell that apart from a mechanism working

What happened

Why this is a measurement problem for run 3 and not just a bug

What this asks the seal to carry

Not proposed as a ticket

orioltf commented on Sep 5, 2026

Correction: the positive control is per-check, not one technique for all six

The rule, restated

The second finding underneath it, which is the interesting one

orioltf commented on Sep 6, 2026

Last GitHub-and-ADO precondition closed: 43028 merged

What is actually left before run 3 dispatches

1. Four positive controls are owed

2. The seal's shape is still undecided, and it is now the only open design question on this ticket

Not blocking

orioltf commented on Sep 15, 2026

Ruled: the seal takes the proposed shape

The shape, restated so nothing has to be re-derived at dispatch

Marked not-comparable, never scored

What this does not close

orioltf commented on Sep 15, 2026

Register precondition cleared: PR #466 merged

What is left before run 3 dispatches

Re-measured today, against Azure DevOps and both remotes

orioltf commented on Sep 15, 2026

Session opener — design the four missing positive controls (43021–43024)

1. Read order

2. What a positive control is, and what it is not

3. The one trap that costs an hour

4. The decision this task does not make

5. Other traps

6. The bar

7. Stop rule and reporting

orioltf commented on Sep 15, 2026

Positive controls for 43021, 43022, 43023 and 43024

The finding that applies to all four, stated once and then per check

43021 — every component prop has an argTypes entry

43022 — every test-tagged story takes a snapshot

43023 — every component root carries dxp:font-body

43024 — every interactive element has an accessible name

What none of these four controls proves

orioltf commented on Sep 15, 2026

The four positive controls are designed — last pre-dispatch item closed

Run 3 has no open preconditions

orioltf commented on Sep 16, 2026

Environment rebuilt, Consumer baseline moves to ddefc51, run 3 has no open precondition

orioltf commented on Sep 16, 2026

Correction to the ruling comment: a positive control is not a one-line edit

orioltf commented on Sep 16, 2026

How to start this session — run 3 dispatch

1. What this session produces, and what to invoke

2. Read these, in this order

3. The one trap that costs an hour

4. The decision this ticket does not make

5. Before dispatch, in order

6. Other traps

7. The bar, and what a false pass looks like

8. On landing

9. Report back

orioltf commented on Sep 16, 2026

Run 3 dispatched — 2026-09-16 15:29 CEST

Ruled: `estimations` stays `'both'` for run 3

43021 — every component prop has an `argTypes` entry

43022 — every `test`-tagged story takes a snapshot

43023 — every component root carries `dxp:font-body`

Environment rebuilt, Consumer baseline moves to `ddefc51`, run 3 has no open precondition

Specs leg done; the build forks from `develop` at `404f5ba`, not from `5e39db6`