fm-crew-state reports an open, red PR as merged/closed from the pipeline outcome alone, and supersedes the blocker that disproves it

[Lykhoyda]

What happens

bin/fm-crew-state.sh can report a ship task as terminally finished — "PR merged/closed" — for a pull request that is open, red, and carrying an unresolved blocker. The same read then marks that still-open blocker superseded.

Observed in the field: a supervisor received a terminal monitoring result claiming a pull request was merged/closed and its history superseded. The forge disagreed on every count — the PR was open, not merged, mergeable_state: unstable, with a required check in conclusion: failure, and the preserved blocker still open. Cleanup was refused by the operator, which is the only reason the unlanded work survived.

Mechanism

Two adjacent paths compose into the false result.

1. The terminal PR claim is inferred, never verified (bin/fm-crew-state.sh:502):

passed)  RUN_STATE="done"; RUN_DETAIL="run passed: PR merged/closed" ;;

The reader takes the validation pipeline's own outcome field and, on passed, emits a factual claim about the pull request — that it is merged or closed. No forge read happens on this path. When that outcome is wrong, stale, or sourced from a superseded run, the supervisor is told the PR reached a terminal state it never reached.

Contrast bin/fm-pr-poll.sh, which is correctly conservative: it emits merged only on an exact MERGED/merged state read from the forge and stays silent otherwise. The poll cannot produce this claim. The terminal language originates in the state reader, which infers where the poll verifies.

2. The contradicting blocker is invalidated by that same wrong state (bin/fm-crew-state.sh:575-577):

case "$LOG_VERB" in
  needs-decision|blocked)
    if [ "$RUN_STATE" != parked ]; then
      ... RUN_DETAIL="$RUN_DETAIL${SEP}status-log superseded (run $RUN_STATE)"

A preserved blocked record is treated as deterministically stale whenever the run is not parked — sound reasoning, but only when RUN_STATE is itself trustworthy.

3. Why this is one defect rather than two

Step 1 sets RUN_STATE=done from a wrong outcome. Step 2 reads that same wrong value and, because it is not parked, marks the open blocker superseded. A single bad outcome value produces both halves of the false terminal result, and the second half destroys the very record that would have contradicted the first.

That is the discard-risk shape: a false terminal state plus an auto-invalidated blocker is precisely the combination that authorizes teardown of unlanded work.

Why it matters

This fails in the dangerous direction. A reader that overstates trouble costs attention; a reader that reports "finished, nothing blocking" over work that is open, red, and blocked invites destruction of that work.

Relationship to existing issues

Same family — both are fm-crew-state.sh misreads — but neither covers this:

Issue	Claim	Why it does not cover this
#3216	zero CI checks reported as checks green	Different field and path (nm_ci_checks_state, CI log marker)
#3215	superseded cancelled run surfaced, reporting a parked task as failed	Fails toward alarm; harmless direction, and no blocker-supersession coupling

The distinguishing property is direction of failure: #3215 and #3216 make a task look worse or busier than it is. This one makes unlanded, red, blocked work look finished and safe to discard.

Reproduction shape

1. A ship task reaches a validation run whose outcome field reads passed while its pull request is still open with a failing required check.
2. The task's status log carries an unresolved blocked record.
3. Read current state with bin/fm-crew-state.sh <id>.

Expected: the reader does not assert a terminal PR state it has not verified against the forge, and does not supersede an open blocker on the strength of an uncorroborated run state.

Actual: run passed: PR merged/closed plus status-log superseded (run done).

Notes

• Evidence is described by shape and field values; the originating pull request is in a private repository, so its identifiers are withheld. Everything needed to locate the defect is in the two code paths above.
• Filed as a report only. No fix design is proposed here — two directions worth weighing are verifying the terminal claim against the forge before stating it (or not phrasing it as a claim about the PR at all), and not driving blocker supersession from a RUN_STATE no forge read has corroborated.

[kunchenguid]

Speaking as Kun's firstmate:

Triage: Defect still present on main 1fbc7bb1fba262ef38a4dedf321d18c54669b129 (2026-08-29T22:53:01Z). Open PR already targets the false forge claim — help that PR, do not open a competing one.

VISION (per-rule):

Rule	Verdict
One captain / honest interface	aligns — PR merged/closed plus a superseded blocker hides an open, red, blocked PR
Authority / evidence≠authorization	aligns — a pipeline outcome must not authorize a forge-landing claim or teardown
Scripts own exact mechanics	aligns — script must not invent forge state from an unverified outcome field
Restart / durability	aligns — a preserved blocked record must not be wiped by a stale/wrong run state
Unlanded work never torn down	aligns — false terminal + auto-invalidated blocker is the discard-risk shape
Fleet / vendor	cannot tell whether no-mistakes emits passed early or firstmate attributed a superseded run; the dangerous mapping is in firstmate
Scope	aligns — crew-state honesty is command-layer instrumentation; field incident → regression

Closing align/resist: aligns — restores an honest interface and strengthens the refusal path against tearing down unlanded work.

contract-class: restore — unconfigured reads must stop inventing forge landing the product never verified; neutralizing the claim restores promised honesty (VISION interface + unlanded-work rule). Not new-default.

Main evidence (inspected, not claimed):

• bin/fm-crew-state.sh:502 on main: passed) RUN_STATE="done"; RUN_DETAIL="run passed: PR merged/closed" — no forge read on this path.
• bin/fm-crew-state.sh:573-577: needs-decision|blocked superseded whenever RUN_STATE != parked, including when that state came only from the outcome mapping above.
• Contrast bin/fm-pr-poll.sh: emits merged only on exact forge MERGED/merged.
• Same file’s own comment (~L322) says no-mistakes reaches outcome=passed only once the PR is actually merged — the field case (open + red required check + outcome=passed) is exactly where that assumption and the detail string both fail.

Related: #2421 (ready-for-pr, same false claim), #3060 (already stamped existing-pr → #2778). Distinguishing half here is the blocker-supersession coupling; #3215/#3216 are different paths/directions.

Existing help: PR #2778 — fix(crew-state): stop passed runs from implying PR landing (detail → run passed: pipeline complete, regression for #2421). It keeps RUN_STATE=done, so supersession-on-done remains; the authorization language that would justify teardown is what that PR removes. Any forge-corroboration before superseding can ride #2778 or follow it — do not open a competing PR.

Decision: existing-pr — #2778. No ready-for-pr label in isolation. No close.

[devin-ai-integration]

Fixed on main: commit 7111081 (PR #4624) replaced the unconditional 'run passed: PR merged/closed' with passed_pr_detail, which verifies the PR through a retirement receipt or a bounded forge read and now reports the real state (open/closed/merged/unknown), so a passed run can no longer invent a landing that authorizes teardown of unlanded work. Verified at ac2ed3b. — Kun's Firstmate