Files
rune/tests
Nick 0835918601 feat(seal): the MiMo production entry asks the lifecycle WHAT IS NEXT
The production route for a construction request already existed —
send_task → route → _construction_activation (canonical classifier →
contract) — but nothing asked the lifecycle what to do next, nothing
invoked the runner through it, and the contract reference lived only in
process memory, so a fresh session could not find the contract governing
the task it had just recovered.

Minimum seam, no new subsystem:

1. DURABLE TASK ↔ CONTRACT LINKAGE at activation. IssueLink (the existing
   linkage owner) records the reference via link_contract(); no issue is
   fabricated — the preserve-first convention stays operator-created, and
   issue_number remains unset until a real one is attached. This is the
   reference the lifecycle and a fresh session read.

2. THE PRODUCTION ENTRY: RuneOperator.advance_construction() asks the
   lifecycle for the next action and executes the authorised one. It never
   chooses research/build/CI itself and NEVER calls the canonical waiter
   directly — qualify_candidate is executed THROUGH the lifecycle, which
   owns the exact-SHA operation resolution, the waiter and the durable
   result projection. Actions owned by other canonical surfaces are
   reported verbatim with their owner (one switch, not a second one).

3. CONTRACT-SCOPED, DELIBERATELY: measured during this work — the
   conversational path completes the TASK on the model route while its
   contract still governs construction. Construction lives on the contract,
   so the question is asked at that scope (the link supplies the reference).

4. ONE OWNER for the candidate-stage sequencing rule: extracted as
   BuildLifecycle.candidate_stage_action(), used by both the task-scoped
   next_action() and the production entry — the rule is never duplicated.

Tests (6): production request creates the task AND links the contract; the
lifecycle answers WHAT IS NEXT; the runner leg is executed through the
lifecycle with the EXACT candidate SHA; the operator source contains no
direct ci_event_wait call; runner failure sequences repair_candidate and
does not change the task's status (no false completion); a fresh operator
process recovers task+contract+candidate+CI state and sequences
complete_gates.
2026-09-26 19:20:48 +01:00
..