feat(opencode): per-phase prep timings on turn.done
Issue for this PR
Issues are disabled on this fork; motivation below. Stacked on #23 (extends the same turn.done line); re-target to dev after #23 merges.
Type of change
- New feature
What does this PR do?
prep_ms (#23) says how much time the harness spends before the provider request; this says where it goes. Four additive fields on turn.done, accumulated across the turn's steps with plain Date.now() pairs:
history_ms— loading session history from SQLite (filterCompactedEffect, runs every step)tools_ms—SessionTools.resolvecontext_ms— the system-prompt/instructions/model-messageEffect.allsnapshot_ms— the pre-stream gitsnapshot.track()in the processor (exposed via asnapshotMshandle getter, mirroringfirstTokenAt)
These four are the optimization targets of the per-step-prep workstream; this instrumentation lands first so each later change has a fleet-wide before/after, and so the p90 tail can be attributed before anyone chases it.
How did you verify your code works?
Extended the #23 turn.done test: all four fields present and ≥ 0 on a scripted two-step turn. bun run typecheck clean, bun run lint 0 errors, prompt.test.ts + compaction.test.ts 112/112.
Checklist
- I have tested my changes locally
- I have not included unrelated changes in this PR
🤖 Generated with Claude Code
Summary by cubic
Breaks down turn preparation time into four phases and logs them on turn.done. Previously we only emitted prep_ms; now we also emit history_ms, tools_ms, context_ms, and snapshot_ms to attribute pre-request latency.
- Instruments
historyloading,toolsresolution,contextconstruction, and pre-streamsnapshotcapture; accumulates per step and emits onturn.done. - Adds
snapshotMstoHandle/ProcessorContextand measures pre-streamsnapshot.track()in the processor; exposes viahandle.snapshotMs. - Updates tests to assert the four new fields and adapts fakes to include
snapshotMs.
Migration
- Add
snapshotMsto any customHandleimplementations or test fakes.