Summary

• Refines RunIncident provider transport diagnostics when streaming interrupts after tool execution has started.
• Tracks attempt-level tool execution completion so transport disconnects after a tool result derive after_tool_result and post_tool instead of a pre-execution phase.
• Adds regression coverage for post-materialization transport failures without changing recovery UX/API behavior.

Why

Issue #803 requires provider/transport streaming interruptions to distinguish tool-call generation from tool execution. The landed Run Incident Framework already fixed partial tool-input disconnects; this follow-up closes the remaining phase gap where a transport failure after tool execution could still look like after_tool_call_before_execution.

Related Issue

Closes #803.
Part of #808.

Human Review Status

Pending

Review Focus

• Whether transport failures after tool_execution_started no longer report a pre-execution provider phase.
• Whether tool_execution_completed is tracked at attempt scope and only upgrades completed-tool transport failures to after_tool_result / post_tool.
• Whether the change remains diagnostic-only and does not alter [Feature] Add safe recovery for interrupted streaming runs #804 recovery UX/API/idempotency behavior.

Risk Notes

Latest review fix: terminal phase derivation now ignores same-attempt evidence recorded after the terminal event, and processor stream/tool execution diagnostics stay bound to the stream event or tool-call attempt instead of a later current attempt.

Latest follow-up review fix: halt/interrupt transport failures now record against the process-local failing attempt instead of mutable currentAttemptID, and same-monotonic phase truncation uses evidence order as a tie-breaker.

Latest tie-break review fix: terminal phase ordering now treats monotonic time as primary, uses evidence order only when monotonic times are equal, and transport cause facts are derived at the failure timestamp.

Latest lifecycle terminal review fix: terminal phase derivation now applies terminal-time evidence truncation even when the terminal event has no attempt_id, so lifecycle closes cannot be upgraded by later tool completion evidence.

• Diagnostic-only change: no recovery card, Continue/Resume API, auto-retry, provider SDK behavior, or user-visible recovery copy changed.
• Privacy posture is unchanged: no raw prompt, raw tool input, raw provider payload, local paths, or secrets are added to incidents or exports.
• No visible UI changed, so no snap/manual UI check was run.
• Platform impact is limited to diagnostic classification data in opencode session observability.

How To Verify

Red/green TDD:
- New regression for transport failure after tool execution start failed first because it was classified as after_tool_call_before_execution, then passed after the fix.
- New regression for transport failure after tool execution completion failed first because it was classified as unknown_stream_phase, then passed after the fix.

Final targeted checks:
- bun test test/session/run-observability.test.ts test/session/processor-effect.test.ts --timeout 30000 → 68 pass, 0 fail
- bun run typecheck from packages/opencode → passed
- git diff --check → passed

Screenshots or Recordings

Not applicable — no visible UI change.

Checklist

How to use this checklist:

• Tick a box by replacing [ ] with [x]. Do not edit, add, or remove items.
• The bot-applied label items can only be honestly ticked AFTER the PR is opened and the labeler / priority-triage bots have run — return to the PR description and tick them then.
• Most items are required. The few that are conditional are explicitly marked (conditional); for those, leave unticked if they truly do not apply and explain why in Risk Notes. All other items must be ticked before requesting human review.

• Type label — this PR carries exactly one of bug, enhancement, task, documentation. Type labels are author-added; the labeler bot does NOT assign them. Add the label in the GitHub UI, then tick this.
• Routing labels — this PR carries at least one of app, ui, platform, harness, ci. The labeler bot assigns these on PR open based on changed paths. Confirm the bot's choice (or override if wrong), then tick this.
• Priority label — this PR carries exactly one of P0, P1, P2, P3. The priority-triage bot suggests one on PR open. Confirm or override, then tick this.
• Human Review Status above is set to Pending, Approved by @<reviewer>, or Not required: <reason> (default is Pending; "not required" is restricted to bot-authored low-risk PRs).
• I linked the related issue, or stated in Summary why there is no issue.
• I described the review focus and any meaningful risks.
• I replaced the example block in How To Verify with the real verification steps and the key result for each.
• I did not introduce unrelated refactors, dependencies, generated files, or file changes beyond the stated scope.
• (conditional) I manually checked visible UI or copy changes when needed, with screenshots or recordings. Leave unticked only if no visible UI or copy changed.
• (conditional) I considered macOS and Windows impact for platform, packaging, updater, signing, paths, shell, or permissions changes. Leave unticked only if no platform/packaging surface was touched.
• (conditional) I called out docs, release notes, dependencies, permissions, credentials, deletion behavior, generated content, or local file changes when relevant. Leave unticked only if none of those surfaces was touched.
• I reviewed the final diff for unrelated changes and suspicious dependency changes.
• I am targeting dev, and my PR title and commit messages use Conventional Commits in English.