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

[orioltf]

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

1. Land the blockers. The three GitHub tickets above and ADO 43028.
2. 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.
3. 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.
4. 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.
5. Dispatch, then read both legs against the sealed predictions.
6. 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.

[orioltf]

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.

[orioltf]

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.

[orioltf]

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.

[orioltf]

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.

[orioltf]

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.