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)

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