Which Box changes does v1 need, and in what order do they land? #542

Activity

1. orioltf

   added

   app:unic-archon-dlc

   wayfinder:grillingWayfinder ticket: decide it by grillingWayfinder ticket: decide it by grilling

   on Sep 23, 2026
2. orioltf

   added a parent issue on Sep 23, 2026

   • wayfinder: e2e specs from acceptance criteria, at a second Consumer #538
3. orioltf

   marked this as blocked by 5 issues on Sep 23, 2026

   • Can the DLC's own line, adapted by context, produce a reviewed e2e suite? #539
   • What replaces RED in /build when an e2e test for an existing feature should pass first time? #540
   • Does an e2e test become an outer loop around /build's unit TDD loop for a new feature? #541
   • bug(unic-archon-dlc): open-pr precedes its gate, and a config-value gate has no safe middle #439
   • No Box can target a base branch that is not the trunk, so run 4 cannot merge to integration/dlc #505
4. orioltf commented on Sep 30, 2026

   

   orioltf

   on Sep 30, 2026

   Last edited by orioltf

   MemberAuthor

   More actions

   Constraint from What replaces RED in /build when an e2e test for an existing feature should pass first time?, 2026-09-30

   The resolution adds these changes to v1's list:

   • unic-dlc-build.yaml:
     • run-build changes from a loop: node to a loop_group, with one body node per phase.
     • It gains the Characterisation Slice's phase pair and the three-run sabotage proof.
     • bootstrap reports a Characterisation Slice that has no sabotage technique, and guard-not-ready cancels.
     • goals-check counts a deferred criterion as covered with a gap.
     • verification does not count a skip marker that links a tracker item as a stub, and it reports deferred tests by count rather than calling a zero-test e2e run "suspicious".
   • commands/specs.md: each criterion is marked existing or new, and the developer confirms the mark at Halt 1.
   • commands/tickets.md: a criterion that is both e2e-testable and existing becomes a Characterisation Slice. Characterisation Slices are ordered before every other slice of the feature.

   Two ordering facts:

   • The goals-check and verification edits also serve #541's item 8, which defers a minor failure with a skipped test. So they land with the first of the two decisions to ship, not with the Characterisation Slice alone.

   • The implementation ticket starts with three measurements on the target Archon version:

     • that scoped denied_tools entries and sandbox.filesystem.denyRead are enforced in a loop_group body node;
     • that a resumed loop_group continues from build-state.json;
     • that a body node accepts when:.

     If the first measurement fails, the test writer may read the source and the gap is recorded. The rest of the design does not change.
5. orioltf commented on Sep 30, 2026

   

   orioltf

   on Sep 30, 2026

   MemberAuthor

   More actions

   Ordering against the other map, 2026-09-30

   Decided by the maintainer and agreed with the orchestrator of #498's seat. /to-tickets writes these edges when it creates the implementation tickets out of #540 and #541.

   1. #483 decides first

   #483 and #540 both change what goals-check counts as covered. So the goals-check ticket gets blocked_by #483. #483 was waiting for #551, which closed on 2026-09-24, so #483 can be grilled now. If #483 puts its rule in evidence_policy and leaves goals-check alone, drop the edge.

   2. Every Box ticket goes after run 4 (#502)

   Run 4's predictions are sealed against today's /build. A Box change that lands first means run 4 measures a /build the seal never predicted. So every ticket out of #540 and #541 that edits a Box file gets blocked_by #502.

   #502 must carry no edge onto a #540 or #541 ticket, or the edges form a cycle.

   The only exception is #540's three measurements:

   • whether Archon enforces scoped denied_tools entries and sandbox.filesystem.denyRead in a loop_group body node;
   • whether a loop_group resumed after a failure continues from build-state.json;
   • whether a body node accepts when:.

   They run before #502 as spikes on a scratch workflow. They change no Box file and no plugin version. Run 4 sets three conditions on them:

   1. No machine-level change survives a spike. A node loads user-scope settings and plugins by default (#628). So a spike leaves ~/.claude/settings.json, user-scope plugin installs and enables, ~/.archon/config.yaml and the Archon binary as it found them. A plugin install goes to project scope in the scratch repository only. Whatever a spike cannot leave untouched, it reverts and records on Dispatch run 4, end it in a merge, and score the seal #502 before run 4 starts.
   2. Each spike records the Archon and Claude Code versions its nodes ran on. The Archon version for run 4 is still open. If run 4 moves to another version, the three results are re-run on it before they count. A spike never upgrades Archon.
   3. The scratch workflow lives outside every clone, with its own Archon codebase row, a dummy remote unique to the run, and --no-worktree. spike(unic-archon-dlc): can an Archon node reach a plugin agent, command or skill? #628's probe used this pattern.