fix(server): Implement starts a run from a proposed plan again

[juliusmarminge]

Clicking Implement on a proposed plan fails on V2 with a toast: Proposed plan <planId> does not exist on thread <threadId>. Nothing runs. "Implement in a new thread" sends the same sourcePlanRef, so it goes through the same failing lookup. I hit this on a Claude plan-mode thread: the plan row was in orchestration_v2_projection_plans with status = 'active', and the dispatch still failed.

The cause is in message.dispatch. It looked up sourcePlanRef in getProjectionWithPendingEvents, which is built on readCommandProjection. Since 28051c4 ("replace unnecessary full projection reads"), that projection hard-codes plans: [], so the lookup could never find a plan. This affects every provider.

Fix

Read the source plan with projectionStore.getPlan(threadId, planId) instead. That is one indexed row read, and the command projection stays as lean as before. The existing checks (same project, still active) and completeSourcePlan work as they did.

Verification

• New test in Orchestrator.control-reads.test.ts. It creates a thread, applies an active proposed_plan, dispatches a message with sourcePlanRef, and asserts that the plan becomes completed.
  • Without the fix it fails with Proposed plan plan:implement-plan does not exist on thread thread:implement-plan., the same error the web toast shows.
  • With the fix, vp test run src/orchestration-v2/Orchestrator.control-reads.test.ts passes (2/2).
• vp exec tsc --noEmit -p . in apps/server: no error TS or warning TS.
• vp lint on both touched files: no new findings. One existing no-unused-vars warning at Orchestrator.ts layerUnavailable was already there.
• knip --workspace apps/server --exports: clean.
• Not run: the full server suite. I also did not re-drive the web Implement button against the fixed build.

Model: Claude Opus 5.5 (Claude Code)

🤖 Generated with Claude Code

---

[macroscopeapp]

Approvability

Verdict: Approved at edf3ed9

Macroscope's review found this PR approvable — This is a focused server bug fix that restores proposed-plan implementation by reading the plan through the existing projection-store API, with validation behavior preserved and a regression test added. It does not alter schemas, defaults, infrastructure, security-sensitive code, or static-analysis configuration.

^{You can add or adjust custom eligibility rules. Learn more.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	4.9 KiB	—	6.8 KiB	✅
Codex	Thread snapshot wire	—	3.7 KiB	—	4.9 KiB	✅
Codex	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Codex	Live turn WebSocket decoded	—	20.4 KiB	—	29.3 KiB	✅
Codex	Live turn messages	—	2	—	8	✅
Claude	Total thread wire	—	4.9 KiB	—	6.8 KiB	✅
Claude	Thread snapshot wire	—	3.7 KiB	—	4.9 KiB	✅
Claude	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Claude	Live turn WebSocket decoded	—	20.8 KiB	—	29.3 KiB	✅
Claude	Live turn messages	—	2	—	8	✅

Baseline: unavailable · PR result: edf3ed9 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 106.1 KiB
• Claude decoded thread snapshot: 106.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.