[Task] Track upstream v2/core runtime maturity for future PawWork migration

[Astro-Han]

Goal

Track upstream anomalyco/opencode v2/core runtime maturity and define PawWork's go/no-go gates for any future migration.

This issue is a strategic tracking issue, not an implementation commitment. PawWork should not start a broad v2/core runtime migration until upstream has operated on this architecture long enough to prove the runtime, session, event, runner, compaction, and recovery paths are stable.

Scope

In scope:

• Track upstream v2/core runtime, event, message/session, and runner maturity.
• Re-check upstream after it has run this architecture on the default path for a meaningful stability window.
• Define PawWork-specific migration gates before any implementation work starts.
• Identify small, reversible evaluation steps such as a read-only shadow replay or compatibility spike.
• Keep this issue connected to related PawWork runtime work without merging their scopes.

Out of scope:

• No code migration from this issue.
• No new implementation branch or worktree from this issue alone.
• No packages/core import or subtree copy.
• No replacement of PawWork's current session runner, server, or SDK path.
• No UI/UX/product-surface redesign.
• No blocking of the current upstream-value A/B production queue.
• No direct upstream architecture alignment just to make rebasing easier.

Upstream maturity signals to watch

• v2/core is the default production runtime path upstream, not only an experimental or parallel path.
• Upstream has operated on the new path for at least 2-4 weeks or 2-3 releases.
• Runtime, event, session/message, runner, tool lifecycle, compaction, and recovery APIs are not still seeing high-churn breaking changes.
• Upstream has a concrete story for old sessions, crash recovery, interrupted tool calls, compaction continuation, and long-running sessions.
• There are no obvious disposable beta resets or schema rewrites still expected.

PawWork go/no-go gates

Before any migration PR sequence is proposed, verify:

• Current PawWork local sessions can still open, read, resume, and export without data loss.
• A read-only shadow replay can map PawWork's current MessageV2 / parts model to the upstream event model without losing subtask, skill, notice, tool, compaction, or recovery semantics.
• Desktop server, app, SDK, background run, and goal/subagent paths have a compatibility plan.
• The migration can be split into review-sized, reversible PRs instead of one broad runtime replacement.
• The expected user value is concrete: better recovery, clearer tool lifecycle, safer compaction continuation, or more durable long-running sessions.
• The expected code-debt value is concrete: fewer parallel session representations, clearer runtime ownership, or less fragile event reconstruction.

Relevant files or context

Related issues:

• [Task] Audit remaining Effect migration scope after upstream HttpApi rollout #936 tracks the remaining Effect / HttpApi migration audit and should remain separate.
• [Feature] Recover model runs after tool activity on transport disconnect #927 tracks transport disconnect recovery and may expose runtime requirements.
• [Feature] Add background subagent lifecycle v1.1 #341 tracks background subagent work and may eventually depend on durable runtime semantics.
• [Feature] goal tool: run back-to-back until a stop condition is verifiably met #1243 tracks goal tooling and may eventually depend on run/session durability.
• [Task] Core engine audit findings: edit replaceAll corruption, MCP isError ignored, per-tool-call history scans, silent-stream stall truncation #1223 tracks narrower core engine audit findings that should not be blocked by this umbrella tracker.

Recent audit context:

• Upstream v2/core work is a broad runtime architecture change, not a narrow cherry-pick.
• PawWork should learn from the model and evaluate it deliberately, but should not directly copy the architecture while upstream is still moving quickly.
• The first useful future step is likely a read-only compatibility or shadow replay spike after upstream stability signals are met.

Verification

For this tracker:

• Revisit after upstream has run v2/core as the default path for at least 2-4 weeks or 2-3 releases.
• Record the PawWork dev commit SHA and upstream anomalyco/opencode commit SHA used in each refresh.
• Use live upstream PRs/commits, current PawWork code, and file-level evidence rather than stale handoff notes.
• Check whether upstream is still actively rewriting the same runtime/session/event/runner surfaces.
• Confirm whether the PawWork go/no-go gates above are satisfied, blocked, or still untested.

For any future spike proposed from this issue:

• Keep it read-only or behind a clear non-production boundary unless a maintainer explicitly approves implementation work.
• Prefer a shadow replay / compatibility proof before any production runtime replacement.
• Include old-session compatibility, compaction continuation, tool lifecycle, and recovery behavior in the verification plan.

Execution mode

Investigate and propose a plan first — the agent must post the plan as an issue comment and wait for an explicit "approved" comment before writing code or opening a PR.