Skip to content

triage-friction-log's forge-finalize operation log has no slot for a review-fix round that moves the head #695

Description

@topij

forge-finalize declares its operation log as "a prefix of branch-create, commit,
push, pull-request, pr-watch, and merge-read-back; every earlier logical
operation is verified and at most the last is not."

A review round that produces a fix breaks that shape.

Reproduction

On PR #694 (2026-09-06) the fallback panel's adversarial lens found a real defect at head
539ad9ff203b911bb03d2565889d44b2fc69fdd2. Fixing it required another commit and
push after pr-watch had already been recorded unsettled for that head. A
conforming implementation's own predecessor guard rejects that append.

Mechanism

The declaration permits appending another pr-watch attempt after an unsettled
observation, and permits a retry of a failed action after authoritative no-effect. It
describes no further commit, push, or pull-request read-back once pr-watch has
been reached — yet that is exactly what acting on a review finding requires, because the
fix moves the head the receipt must bind to.

This is #305's shape reaching a
different component: #305 is about the panel having no stopping rule, this is about the
triage state machine having no representation for the round at all.

Note the two available states are both bad. Before reviewed_head is persisted there is
no slot for the round; after it is persisted, any later head movement "invalidates the
receipt and remains terminally operator-held in this run", and the schema "never
replaces reviewed_head or invents a second review cycle from a later head". So a
finding that arrives late is unfixable within the run.

Proposed direction

Model a review round explicitly — either let the ordered log repeat the
commitpr-watch cycle carrying a round index, or declare a review-fix re-entry
that returns the phase to a pre-pull-request cutpoint while retaining the verified
tracker and repository evidence already gathered.

Severity M. Found while running the workflow on PR #694; the run recorded the
deviation in its own state rather than silently relaxing the model.

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

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions