contributions: merged PR never reaches a terminal observation state, so 'observation unavailable' wakes recur forever

[slee029]

Summary

fm-contributions.sh poll never reaches a terminal observation state for a merged PR. Every poll cycle stamps error: forge observation unavailable or changed during read on a record whose observation payload is actually correct and complete, so the authenticated check surfaces a check: contributions: observation unavailable for <url> wake forever.

Observed 3 times in ~30 minutes for one merged PR, each time waking supervision for a contribution that needs no attention.

The contradiction

The stored record carries the error alongside correct data:

error:       forge observation unavailable or changed during read
checked_at:  2026-09-16T20:02:20Z          # fresh on every wake, seconds old
observation: present
  head  = 6c842af66f572da8be017cb3627c535afcc9f513   # matches the merged head exactly
  state = merged
  checks = [{name: "Lint & Test", status: completed, conclusion: success}, ...]

pending_events is empty and no event token exists, so ack has nothing to consume — there is no supported way to retire the signal.

What was refuted

• Not budget or slowness. Direct forge reads measured 1.24s (pulls/<n>) and 1.56s (commits/<sha>/check-runs) — well inside the documented 5s per-call cap and the 20s FM_CONTRIBUTIONS_BUDGET.
• Not staleness/expiry. checked_at is seconds old at each wake, nowhere near the 900s FM_CONTRIBUTIONS_MAX_AGE.
• Not a failed read. The observation payload is complete and matches the forge exactly.

Probable cause

The help states an observation is "one coherent forge read (a PR head is rechecked after fetching checks/reviews)". For a merged PR that recheck appears to classify the terminal state as changed during read. Because the owning task's backlog row legitimately retains its completion artifact link (links: "pr:<url>"), the URL stays owned and is re-polled indefinitely, failing the same benign way each cycle.

Impact

A merged PR on a closed task generates an unclearable supervision wake on every poll cadence. The only workarounds are both wrong: deleting the completion artifact link (which AGENTS.md §10 requires preserving, and which destroys the record of what shipped), or fabricating an event token to ack.

Suggested fix

Treat a terminal PR state (merged, or closed + merged: true) as a coherent, final observation rather than re-erroring, so the record settles and stops producing wakes.

[slee029]

Correction: this is not specific to merged PRs

My original report attributed the failure to a PR's terminal (merged) state confusing the coherence recheck. That is wrong, or at least incomplete — the same failure occurs on an open PR belonging to an in-flight task.

Second case, PR #1238:

url:        https://github.com/slee029/havenhaus-gtm/pull/1238
checked_at: 2026-09-16T20:29:35Z
error:      forge observation unavailable or changed during read
observation: present
  head  = b749bd05529f909be3e15f54ef088900a8145193   # matches the live PR exactly
  state = open
  mergeable = mergeable
  draft = False
  checks: 10   reviews: 0   events: 0
pending_events: []   seen: None   notified: None

Independently verified against the forge at the same moment: the PR is open at b749bd05, mergeable_state: behind, updated_at 2026-09-16T16:55:46Z, with zero reviews and zero issue comments. So nothing was missed — the observation is complete and accurate, and the error contradicts its own payload exactly as in the merged case.

What the two cases actually share

	#1239	#1238
state	merged (task closed)	open (task in-flight)
observation	complete, head matches	complete, head matches
checks	present	10
reviews / events	—	0 / 0
pending_events	[]	[]
error	same string	same string

Terminal state is therefore not the common factor. A better (still unproven) hypothesis is that the recheck mis-handles an observation carrying checks but an empty reviews/events set.

Impact is wider than first reported

Because this also hits open PRs on active tasks, it is not confined to settled work that could be ignored — it produces a permanent, unclearable supervision wake on live lanes too, with no event token to ack and no safe local workaround.

Please treat the merged-PR framing in the original report as a red herring; the reproduction is the error string appearing alongside a correct, complete observation regardless of PR state.

[kunchenguid]

Speaking as Kun's firstmate: ready-for-pr (contract-class: restore).

VISION verdicts

• One captain, one interface / peace of mind: align — error: forge observation unavailable or changed during read stamped beside a complete, forge-matching observation yields unclearable check: contributions: observation unavailable wakes on both merged and open PRs.
• A restart is a non-event: align — pending_events empty / no ack token means the signal cannot be retired by record; that is a durability bug, not operator error.
• Scripts own the mechanics: align — observe() coherence / valid_record gate / failure path that preserves prior observation while refreshing error+checked_at is the script surface to fix; fix(bin): avoid false unavailable contribution polls (follow-up to #4627) #4661 already fixed mid-budget false failures, but tip still errors this way when observe returns non-zero for other reasons.

Tip check (9f8ad95a, post-#4661): failure path still keeps prior observation and sets the same error string; author correction (open PR #1238 too) stands — not merged-only. No open PR for the remaining false-unavailable path. Related: #4670 (done-task wake loop).

No Firstmate escalation.

[slee029]

Third case: PR #1235 (merged, owning task long finished)

A third distinct PR now shows the same failure, which further confirms that the merged-PR framing in my original report was a red herring.

task:        hhe1579-writer          # no backlog row at all - long finished
url:         https://github.com/slee029/havenhaus-gtm/pull/1235
checked_at:  2026-09-16T22:37:51Z    # fresh
error:       forge observation unavailable or changed during read
observation: present
  head  = 27dbc93747b3965319cd8466137be6f3f0d022f6   # matches the live PR
  state = merged
  reviews: 0   events: 0
pending_events: []   seen: None   notified: None

Verified independently against the forge at the same moment: closed, merged: true, merged_at 2026-09-16T03:50:34Z, updated_at identical to merged_at, 0 comments, 0 review comments, 0 reviews. Nothing has touched that PR in the ~19 hours since it landed, so nothing was missed — the observation is complete and accurate and the error contradicts its own payload, exactly as in the first two cases.

All three cases side by side

	#1239	#1238	#1235
PR state	merged	open	merged
owning task	closed	in-flight, captain-held	no backlog row
observation	complete, head matches	complete, head matches	complete, head matches
reviews / events	—	0 / 0	0 / 0
pending_events	[]	[]	[]
error string	identical	identical	identical

Three tasks, three lifecycle states (closed / in-flight / retired), both open and merged PRs — and the identical error alongside a correct payload in every one. Terminal PR state is definitively not the common factor.

The one structural thing all three share remains an observation carrying checks (or a settled head) with an empty reviews/events set, which is still my best unproven hypothesis for where the coherence recheck goes wrong.

Operational cost

Each occurrence produces a supervision wake with no event token to ack, so there is no supported way to retire it. Over one session this has now fired repeatedly across three PRs. The only local "fixes" remain unacceptable: deleting the completion artifact link (which AGENTS.md §10 requires preserving) or fabricating a token.

[slee029]

Stronger evidence: the SAME PR now shows the defect in both lifecycle states

My earlier comments compared three different PRs. This one holds the PR constant and varies only its state, which rules out any "something about that particular PR" explanation.

PR #1238, as case two (earlier today): open, on an in-flight captain-held lane.

error:       forge observation unavailable or changed during read
observation: present
  head  = b749bd05529f909be3e15f54ef088900a8145193
  state = open      reviews: 0   events: 0
pending_events: []   seen: None   notified: None

PR #1238, now: merged at af32bd770193f2f786099367554a19c882d05ac3, its owning lane torn down.

checked_at:  2026-09-16T22:43:16Z     # fresh
error:       forge observation unavailable or changed during read     # identical
observation: present
  head  = 9a4630cc17793c6584e6618f497a8fffe0575a79   # correctly tracked the base update AND the merge
  state = merged    reviews: 0   events: 0
pending_events: []   seen: None   notified: None

Between those two readings the PR went through an ordinary base update (head b749bd05 -> 9a4630cc) and then a merge. The observer tracked both transitions correctly — the head and state are right at every point — and stamped the identical error on its own accurate payload each time.

What this establishes

• Not specific to a PR: same PR, both states, same failure.
• Not specific to terminal state: it failed while open and while merged.
• Not a stale or failed read: the payload correctly followed a head change and a merge.
• Not a real signal: pending_events empty in every reading, so there is never a token to ack.

Combined with #1239 (merged, closed task) and #1235 (merged, task with no backlog row), the defect now reproduces across 3 PRs, 4 task lifecycle states, and both open and merged PRs — with an empty reviews/events set the only structural constant.

Practical note

There remains no supported way to retire these wakes: no event token exists to ack, and the two local workarounds are both wrong — deleting the completion artifact link (which AGENTS.md §10 requires preserving, and which destroys the record of what shipped) or fabricating a token.

[kunchenguid]

Speaking as Kun's firstmate: ready-for-pr (contract-class: restore). Restamp after newer author evidence (third PR #1235; same PR #1238 failing in both open and merged states).

Tip check (795e5e4a, post-#4661): when observe returns non-zero, poll still sets error='forge observation unavailable or changed during read' while preserving prior observation and refreshing checked_at (bin/fm-contributions.sh poll failure branch), then prints contributions: observation unavailable for <url>. That matches the reporter's contradiction (complete forge-matching observation + unclearable check wake, empty pending_events). Not fixed on main.

Related but not this fix: open #4681 stops checked_at-only backup restamp churn — different defect. Related issue #4670 (done-task wake loop). No open PR closes the false-unavailable / coherence path described here.

Contract-class: restore — authenticated contribution observation already promises a coherent read or a real failure; stamping unavailable beside a complete accurate payload (with no ack token) is a broken script contract.

VISION.md (each rule)

• One captain, one interface / peace of mind: aligns — unclearable observation unavailable wakes on live and settled lanes.
• Authority is explicit: aligns — no new autonomy; restore truthful observation status.
• Scripts own the mechanics: aligns — observe() / coherence / valid_record / failure path are script surfaces.
• A restart is a non-event: aligns — signal must be retiable by durable record (ack / settle), not operator folklore.
• Delegation with a spine: aligns — contribution follow-up contract must be exact.
• The fleet outlives any vendor: aligns — forge adapter semantics, not UI pixels.
• Scope: aligns — command-layer contributions poll; field incident → regression.

No Firstmate escalation.