Skip to content

wayfinder: run 3 — do mechanisms carry the knowledge where documents did not? #456

Description

@orioltf

Destination

Run 3 of the /specs/tickets/build chain has been dispatched against sealed predictions, read on both legs, and written up. Run 2 showed that documents do not reach the implementer. Run 3 asks whether mechanisms do. The map is done when the answer is on record — not when the run finishes.

Notes

Domain. The plugin is unic-archon-dlc in this repository; the Consumer is DXP-DesignSystem on Azure DevOps. The parent effort is #373 — read its body for the destination this one serves.

This map carries execution, deliberately. /wayfinder plans by default and its tickets are decisions; an effort overrides that in these Notes, and this one does. Most of what gates run 3 is work — an install fix, a Box refresh, a deletion, a parking move — and splitting the doing from the deciding would leave the map unable to say what is left.

The class rule, which is why this map exists at all. Every change queued before a run is one of three things:

Class What it is Lands before the run?
Treatment the thing under test — the mechanism checks yes, it is the run
Instrument makes a result readable without changing what is produced yes
Second variable changes what the chain produces only if separately observable

A second change is a confound only when its effect cannot be told apart from the first's. That is why #441 landed before run 3 while looking like a confound: the checks test properties a PRD cannot mask, so both legs are separately observable in one run.

Half the treatment is on Azure DevOps, and no GitHub edge can reach it. ADO 43028 gates this map and cannot be a child or a blocked by here. It is named in the dispatch ticket's body and in the table below. A wayfinder group shrinks the prose residue; it never removes it. Two other cross-tracker edges already survive only as prose (#446 ← ADO 43018, #449 ← ADO 42998).

The Azure DevOps mirror, so the client sees this work. The client has no GitHub access, the daily runs off ADO, and only User Stories carry Story Points there. So each ticket on this map that is real work has an ADO User Story under Feature 42975, carrying title, a link to its GitHub issue, points and state — never a copy of the body. Nothing is duplicated, so nothing can drift.

This map Azure DevOps
Dispatch run 3 43033 · 13 pts
#430 43034 · 13 pts (raised from 5 on 2026-09-03 after the grilling)
#438 43035 · 1 pt, Resolved (lowered from 5 when #438 closed as not a defect)
#439 43036 · 13 pts (raised from 8 on 2026-09-04 when the grilling closed) — run 4, see § Out of scope
(no ticket — ADO only) 43028 the sixth check

Standing constraint. No dependency upgrade until phase 1 ships its first stable release. Archon is held at 0.7.0 on purpose. Nothing here proposes an upgrade as a fix.

Ticket shape, decided 2026-09-04 by the maintainer, applies from the next grilling on. A grilling closes its decision ticket, the /wayfinder way: the decision ticket gets the Decisions-so-far line and closes when the criteria are approved, and a separate implementation ticket carries the build, linking to the decision ticket's criteria rather than copying them. Each gets its own ADO User Story: the decision ticket's points are the grilling, the implementation ticket's are the build, both estimated when their shape is known. #430 and #439 predate this and stay single tickets with one mirror each.

Skills. /grill-with-docs for a ticket whose criteria are not settled — typed by the maintainer, never /grilling alone, which has nowhere for a decision to land. /writing-for-agents for anything an agent reads. /code-review before any pull request, and its four reads run twice: once on the criteria, once on the diff.

Decisions so far

(what was decided before this map was charted is in #373 § Decisions so far)

  • A review node produced thirteen findings and recorded them nowhere
    closed as not a defect, 2026-09-03. The premise did not survive a direct read: unic-dlc-build.yaml's
    report node folds the precheck findings in verbatim, and run 2's open-pr committed them in
    workflows/profile-card/report.md § 4 on the PR branch (c66eac9). An empty $ARTIFACTS_DIR — empty by
    design, evidence withheld — was read as "no file carried the output". What the grilling found instead,
    three /qa nodes whose prose nothing reads or keeps, is #458,
    ruled outside run 3. Register row 35 corrected. Dispatch run 3, read both legs against sealed predictions, and write it up #457 loses one blocker.
  • The config maps commands to nodes and the Boxes name tools, so a check runs by luck or not at all
    merged 2026-09-05 as f9886f6 (PR #461), unic-archon-dlc 0.28.0.
    The config gains sdlc_needs, nine nullable keys naming needs and never tools; every Box installs once at bootstrap
    and says whether it did; every command outcome is pass | fail | unresolved, unresolved is never green, test is the
    floor at /build's evidence and /qa's merge; the unresolved needs land in a durable block (report.md, the posted
    review summary, a new qa-checks.md); /qa gains a test node it never had. Proven by one /qa run in
    DXP-DesignSystem on a config with no block: nine nulls, nothing fabricated, and qa-checks.md naming run 2's false
    pass unprompted. The positive path (install, test, pass, certify) has not run yet; it needs the maintainer's Consumer
    steps after the 0.28.0 tag. Instrument, so Dispatch run 3, read both legs against sealed predictions, and write it up #457 loses its last blocker and run 3 is dispatchable. ADR-0037.

Not yet specified

  • How the result gets read. Sealed predictions exist as a practice, not as an artefact with a shape. Who scores them, against what, and where the score lives is unsettled.
  • What run 4 asks. It depends entirely on run 3's answer, and the interesting branch is the one nobody has planned for: mechanisms fail too, and the problem is upstream of both documents and mechanisms.
  • Whether a run's output is ever merged. Two runs have been abandoned on purpose, so the client has seen nothing render. That decision belongs to #379 on the parent map, and it is not this map's to make — but run 3 produces a third abandoned branch if it stays open.

Out of scope

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions