🤖 G4 goal advancement follow-ups from #5536

[ThomasK33]

Follow-ups from the G4 goal-advancement work in #5536 (one pending advancement, one wake-up path). None of them blocks #5536. Each needs an owner before it is picked up.

1. Concurrent error records consume two attempts (Codex on 🤖 fix: advance an active goal after a terminal stream error or abandoned automatic work (G4) #5536, thread). recordGoalAdvancementAfterStreamError awaits the retry-preference read after finishTurn. If a queued automatic successor starts and also fails during that await, both errors record and hand over an advancement. Two resume attempts are consumed for one resume, and the predecessor's options can race the successor's. Fix: bump a record generation at entry and drop the stale record after the await.
2. A failed hand-over loses the pending advancement (Codex on 🤖 fix: advance an active goal after a terminal stream error or abandoned automatic work (G4) #5536, thread). reevaluateGoalAdvancement clears the record before armGoalAdvancement resolves. If that rejects (for example a transient goal.json read error), only a log remains. requestContinuationAfterStreamEnd has the same exposure today. Fix: restore the record on rejection and schedule a bounded retry.
3. A retry that fails before any stream records no resume. A retry started by RetryManager that fails with a non-retryable send error before a stream exists never reaches handleStreamError.
4. No test for the preparing-manual-send blocker. userInputBlocksGoalAdvancement treats a dequeued manual send that is still preparing as a blocker. The session test harness leaves the queue undrained after a terminal error, so the test needs a harness that drains it.
5. Restart and the auto-retry opt-out. Restart recovery re-arms active goals even when the user opted out of automatic retries (this predates G4). Confirm that this is the intended reading of decision item 1 on 🤖 workspace goals: decide goal auto-resume after terminal errors (G4) + 3 suspected issues #5461, or fence it.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $52.67

[ThomasK33]

Picked up by the issue coordinator: workspace workspace-69, branch fix/goal-followups-5546-5506

Triage (A: single-backend defect, small fix; B: multi-backend; C: new persisted field or subsystem; D: low priority; E: already fixed):

Item	Class	Plan
1. Concurrent error records consume two attempts	A	Fix in this lane: a record generation, so a stale record is dropped after the preference read.
2. A failed hand-over loses the pending advancement	D	Not in this lane. It needs a transient goal.json read error. A backend restart re-arms the active goal. The stream-end path has the same exposure today. The fix adds a retry timer, which is new mechanism. Left open, labeled backlog.
3. A retry that fails before any stream records no resume	A	Fix in this lane: the RetryManager retry's pre-stream failure records the advancement when no retry is pending.
4. No test for the preparing-manual-send blocker	A	Test in this lane.
5. Restart and the auto-retry opt-out	D (decision)	No change. My reading of decision item 1 on #5461: resume after a restart is required, and the auto-retry opt-out is not in the decision's exception list. I asked the coordinator to confirm.

The PR will say "Refs #5546". Items 2 and 5 stay open here.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high

[ThomasK33]

Item 5 (restart and the auto-retry opt-out): by design, closed. No change.

The G4 decision on #5461 (#5461 (comment)) says an active goal resumes after a backend restart. Its only exceptions are: a human paused the goal in the UI, an agent paused or completed it, or a budget or turn limit was reached. The stream auto-retry opt-out is not on that list. A user who wants a goal to stop pauses the goal. If the opt-out must ever cover goals, that is a new product decision.

Confirmed by the issue coordinator. Item 2 stays open (low priority, backlog).

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high

[ThomasK33]

Status after #5585 (merge commit 033418c):

• Item 1 (concurrent error records): fixed in 🤖 fix: goal follow-ups yield to direct user sends; G4 follow-ups from #5536 #5585.
• Item 3 (pre-stream failure records no resume): fixed in 🤖 fix: goal follow-ups yield to direct user sends; G4 follow-ups from #5536 #5585. The real gap was the runtime_not_ready branch of handleStreamWithHistoryFailure.
• Item 4 (test for the preparing manual send blocker): added in 🤖 fix: goal follow-ups yield to direct user sends; G4 follow-ups from #5536 #5585. The preparingQueuedInput check cannot change the result today, because the PREPARING phase already blocks. The PR description explains this.
• Item 5: by design (see the comment above).
• Item 2 (a failed hand-over loses the pending advancement): still open. This issue now carries the backlog label for it.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high