feat(unic-archon-dlc): a red /build run reaches a human through a grouping ticket #658

Split out of bug(unic-archon-dlc): open-pr precedes its gate, and a config-value gate has no safe middle on 2026-10-26.
Not ready. It waits for the Consumer's tracker to be redefined, because every criterion here depends
on how the tracker contract expresses a group. Re-grill it then, against the contract's role and
never against one Consumer's values.

Question

After #439, a red /build run opens no pull request. It ends cancelled, and its work stays on the
remote branch. The operator who launched the run sees that. A human who did not launch it, as in an
afk run nobody watches, has no place to learn of it.

The 2026-09-04 grilling answered with a grouping ticket: /tickets creates one ticket per run that
groups the slice tickets, and on red /build appends a pointer to the branch and the report there.
The verdict belongs to the run, not to one slice, so neither one slice ticket nor every slice ticket
is the right place.

Criteria carried over from #439, not re-read

These are #439's old criteria 7 to 13, 16 and 18, and the grouping part of 17, as approved on
2026-09-04. They were not re-read on 2026-10-26. Re-read each one against the tree before this ticket
is dispatched. Drop the counts in old criterion 13, and write old criterion 16 for each Consumer,
naming none.

• Old 7. On a red verdict, the grouping ticket receives a pointer, not the report. A comment names the
  branch and the path of the report inside it. It does not carry the report body: a report is
  30 712 characters in the only run that has produced one, and the comment limits across hosts run
  from roughly 32 000 upward, so a larger run would not fit. The pointer is appended, never edited in
  place, so a slug built three times leaves three attempts on record. Amended 2026-09-04 21:40 by the
  orchestrator, four-reads pass: the node that appends the pointer is its own node, it depends on the
  commit-and-push node of criterion 6 (the pointer names a branch that must already be on the remote), and
  the cancel: node of criterion 4 depends on it. Criterion 4 says the cancel: node stops the DAG
  between layers so nothing downstream runs; a pointer node placed downstream of, or beside, cancel: never
  runs, and the red path then satisfies criteria 4 to 6 while criterion 7 fails silently. Same shape as the
  gate fix(unic-archon-dlc): /specs skips the grilling its config requires and reports halts that never fired #441 shipped that could not fire.

• Old 8. On a green verdict nothing is written to the grouping ticket, and the body says so. The pull
  request already links the report and the slices, so a second copy would be a surface to keep in
  sync. A reader of this ticket should not have to guess whether the omission was deliberate.

• Old 9. /tickets creates one grouping ticket per run and records it in the baton. It carries the
  type role feature and no state role. The tracker contract's own reasoning is why: every state
  role writes something, and none of them is true of a ticket nobody is meant to pick up; leaving all
  of them unwritten lands the ticket in whatever the host's creation default is, which is where a
  grouping ticket belongs.

• Old 10. The plugin names the grouping relationship and never its mechanism. /tickets asks the
  tracker contract how this repository expresses a relationship between a group and its members,
  and uses what it names — parenthood where the host has it, any other relation where it does not.
  No Box asks the tracker about hierarchy at run time: /build reads the grouping ticket's id from
  the baton.

• Old 11. /tickets stops when the contract names no grouping mechanism. Same shape as its existing
  contract check in Step 1: print a message naming what is missing, and stop. A grouping ticket that
  groups nothing is worse than none — /build would find it in the baton, publish the report there,
  and no one reading a slice would ever reach it.

• Old 12. A re-entering /tickets reuses the grouping ticket the baton names, and creates a second one
  for the same slug never. /tickets also accepts the grouping ticket as an optional argument — a
  number or a link. Given one it uses that ticket and creates nothing; given none it creates one. The
  argument exists because the work often already lives under a ticket a human made: this repository's
  own effort is four stories under one Azure DevOps feature, made by hand before any Box ran.

• Old 13. The baton becomes an object, and every surface that asserts its shape changes with it. The
  grouping ticket's id belongs to the run, not to a slice, so the file gains a top-level field
  beside the slice array. Nine sentences across six files assert the current shape — the build Box's
  header, its loop comment, its loop constants block, and the two loop instructions that call it an
  ordered array and walk it in order; /tickets' own overview, its write step and its summary line;
  and the build Box's operator doc. CONTEXT.md, README.md and /improve-architecture name the
  file without asserting its shape and are checked rather than assumed. A reader can confirm no
  surface still calls it an array.

• Old 16. The tracker contract template /setup writes gains the grouping section, and the delivery is
  named as ending inside each Consumer. The contract is tenant-owned: /setup writes it on the
  first run and thereafter only reports. So this change is inert until a human writes the section
  into an existing Consumer's contract by hand, in each Consumer. That hand step belongs to the
  dispatch that first needs it, not to this ticket. A criterion that ended at "the template gains a section" would be satisfied by a change
  no run ever sees.

• Old 18. /qa closes the grouping ticket when it merges the pull request, and reads the baton to find
  it. /qa reads no baton today — only /build does — so it gains that read in bootstrap, where
  /build already has it, rather than in merge, so the irreversible node never discovers a missing
  value halfway through. Merging is where a run ends, and a grouping ticket that outlives every run it
  grouped is a ticket nobody closes.

• Old 17, grouping part. The ADR that bug(unic-archon-dlc): open-pr precedes its gate, and a config-value gate has no safe middle #439 writes covers the verdict. This ticket adds to it, or writes its own: the grouping ticket as a named need with a tenant-owned mechanism.

What this did not decide

1. Whether /qa's close of the grouping ticket deserves its own gate. Old criterion 18 closes it at
   merge, unconditionally, inside a node that already runs behind gates.qa. Nobody has wanted a
   separate pause yet.
2. What a Consumer whose tracker expresses no relationship should do. Old criterion 11 stops
   /tickets when the contract names no grouping mechanism. That is untested: no such tracker has
   been met.