Skip to content

Write run 4's seal: three arms, both legs, both the green and the red branch #500

Closed as not planned

Description

@orioltf

Question

What does run 4's seal predict?

What resolving this produces

A sealed prediction document, written before the first dispatch of run 4 and stored off the tracker,
the way run 3's was (~/Desktop/run3-sealed-predictions-2026-09-16.md). Scored afterwards by someone who
did not run it, against the diff, the posted threads and the node artefacts — never against a leg's own
report.

Three arms, decided while charting:

  1. Per fix, does the symptom leave the bench? Six precondition tickets, six rows: for each, predict
    whether its symptom is still observable in run 4. A fix that changes nothing observable was fixing
    prose.
  2. Which claims are still not derived? Read against the list this ticket is blocked by.
    #487 and
    #488 are the candidates, because both are
    satisfied by "read another file", which is easy to satisfy halfway.
  3. What turns up that nobody predicted. Run 3's arm 2 was incomplete and its real finding —
    User2.tsx inventing its own glyph — was on nobody's list. An open arm, scored as "the seal was
    incomplete" if it fills.

Two rules the seal must honour, both broken once already

  • It is written before the first dispatch and it covers both legs. Run 3's arm 3 was written at 16:30
    with /specs already dispatched, and the register marks it a weakened seal for exactly that reason.
  • It predicts the red branch as well as the green one. #439
    criterion 4 makes a red build open no pull request and end the run cancelled. A seal that predicts
    only green cannot score the outcome that would teach the most.

Not decided

  • Whether the per-fix arm predicts a binary (symptom present or absent) or the specific counter value
    (reconcile's fixed, still_present, new). The counters are known by construction on a
    byte-identical commit, so predicting them is arithmetic rather than prediction — but predicting the
    binary loses the case where the counter is right for the wrong reason.
  • Where the seal is stored, and how the scorer proves it was sealed before dispatch. Run 3 used a file on
    the maintainer's machine and a timestamp in the register. Nothing verified it.

Activity

  1. orioltf commented on Oct 30, 2026

    @orioltf
    MemberAuthor

    Closed as superseded by #678's resolution, approved by the maintainer on 2026-10-30: run 4 is dropped and unic-archon-dlc is frozen. Reason for this ticket: no run, so no seal (rule C).

    — unic-sdlc-orchestrator-9

  2. added
    rejectedWill not be actioned
    and removed
    needs-specsEnough info from reporter; ready to write a spec
    on Oct 30, 2026
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