Tracking: iterate on the viewer plan ladder (#230) — gaps and follow-ups

## Context

#230 (merged 2026-09-14) turned the three-rung plan ladder the harness publishes to console viewers from fixed text into something built from the run: repo/branch/insight count on the prep rung, stage position + task excerpt + model + turn progress on the middle rung, and named push tool calls. The tee's replay ring now keys plan frames so per-turn re-emission does not evict other frames.

This issue tracks what is still rough, so the next person can pick items up independently. Each item names where it lives. None are blocking.

Where the code is:
- `harness/cmd/migration-harness/main.go`: `emitPlan`, `planPrepRung`, `planTaskRung`, `taskSummary`, `workflowStagePosition`
- `harness/internal/tee/tee.go`: `EmitRunUpdate`, `replayKeyFor`, `replayCap` (32)
- tackle2-ui `client/src/app/pages/agent-runs/components/ChatPanel.tsx`: the `plan` item kind (replace-in-place on every update) and its renderer

## Gaps

### 1. The ladder is prose only; the console cannot localize or render it structurally
Rung text is English composed in Go. tackle2-ui routes every user-facing string through i18n, and it cannot show a progress bar or "turn 12 of 200" as a meter because the numbers are baked into a sentence. Proposal: keep `content` for ACP compatibility but add structured fields on each entry (e.g. `stage`, `stageCount`, `model`, `turnsUsed`, `maxTurns`, `repo`, `branch`, `insights`) so the console can render and translate, falling back to `content`. Cross-repo: needs a contract change in tackle2-ui `api/agentic/contract.ts`.

### 2. Standalone runs with no stage instructions show nothing about the work
`planTaskRung` deliberately stopped quoting the agent prompt (persona text), so a run outside a workflow with empty `StageInstructions` reads "Agent works its standing prompt". Options: name the application and target from run params, or let an Agent declare a one-line `summary` for this purpose.

### 3. Per-turn re-emission is one full ladder frame per `tool_call`
Fine for the ring (keyed) but every frame is broadcast to every attached viewer, and a busy run is hundreds of tool calls. Consider throttling: emit on turn milestones or at most every N seconds, and always on status transitions.

### 4. "Turn" semantics and the ceiling shown
A turn is one `tool_call` notification, not a model turn. The rung shows `turn N of MaxTurns`, but the runtime's native ceiling sits at `ReserveFraction` of that with the rest held for the handoff, so viewers can see the primary stop well before N of N. Either show the effective ceiling or word it as a budget.

### 5. Runtime-originated `plan` updates vs the harness ladder
The console replaces any `plan` update in place regardless of origin, and the tee keys only harness-emitted plan frames. If the agent runtime (goose, or opencode per #137) emits its own `plan` session updates, the two would overwrite each other. Needs verification; if real, namespace the harness ladder or merge the two.

### 6. Replay ring pressure from unkeyed frames
Plan frames are keyed now, but push tool calls (including the auto-commit watcher's), notices, and pending asks still accumulate toward the 32-frame cap. A long run with many watcher pushes can still evict the outcome frame a late viewer needs. Options: key watcher pushes by sequence, or key the outcome frame so it is never evicted.

### 7. Task excerpt heuristics
`taskSummary` takes the first paragraph, strips leading `#*->`, and cuts at 80 runes. Instructions whose first paragraph is a heading or a preamble ("Context:") produce a poor excerpt. Consider an explicit per-stage `summary` field for workflow authors, with the heuristic as fallback.

### 8. The third rung is still fixed
"Push results to branch X" does not change when the watcher pushes interim work or when the final push lands. Enrich it with the outcome once known (commit count, PR/MR link when the SCM provides one), and reflect the watcher's checkpoints.

### 9. Test coverage for the late-viewer path
Unit tests cover rung text and the ring's keying. There is no tee-level test that a viewer attaching after N turns receives exactly one current ladder plus the unkeyed frames, nor an e2e check that the console shows it.

### 10. Console-side follow-ups (tackle2-ui)
- Pre-connection states: the panel waits on `ACPReady` with no time bound or hint. Today that surfaced as an indefinite "Waiting" against a stale controller (#226, #227). A "still waiting after Ns" hint pointing at the run's conditions would have shortened the diagnosis.
- Plan entries show a status icon only; no elapsed time per rung and no motion on `in_progress`.
- Usage (tokens/cost from #192) and the turn count live in different places; consider one header line.

## Related
- #123 plan ladder as sample workflow content
- #192 meter agent usage
- #231 / #232 rejected model call outcome
- #166 work lost on abnormal stage termination (watcher checkpoints, relevant to rung 3)
- #137 opencode support (relevant to item 5)

🤖 Generated with [Claude Code](https://claude.com/claude-code)