dash: model the per-wait ping plan in the keep-alive calculator and recommendation #868

Summary

The dashboard's keep-alive calculator and recommendation model a fixed ping count (K) per idle span. Since #867, the live proxy picks the count from what the thread waits for (#858). The panel labels its numbers as the "fixed K (plan off)" model. So the figures a manager sees are not the policy that runs.

What we found

• pingSpans (dash/keepalive.go) selects spans by turn >= 1 AND prefix >= ? and charges maxPings or PingsPerSpan(gap, idle, maxPings) per span.
• The live plan (keepalive/waitplan.go, Policy.WaitPings) gives:
  • a tool wait: up to 8 pings;
  • background work: base + 3;
  • a person: base + 1;
  • a thread with no tool call yet: 0 pings.
• The recommendation bootstraps at recMaxPings = 2.
• feat(keepalive): choose the ping count from what the thread waits for #867 took the honest fallback: the panel says "plan off", plan: "fixed_k" is in the response, and no rung is marked current.

Proposal

1. Read each span's wait cause and tool history from requests: stop_reason, waiting_for, wait_tool, open_background, open_teammate, and whether the thread called a tool before.
2. Apply the plan per span through the same function the keeper uses (Policy.WaitPings and the no-tool rule). Do not copy the rule.
3. Give the calculator a current rung again, for the live plan. Let the recommendation compare "plan on" with fixed-K rungs.
4. Add a test that pins the dashboard model to the keeper's plan, so they cannot drift apart.

Data dependence: metadata only. It uses the same columns the proxy already writes.

This changes what the dashboard shows, not what the proxy does.

Open questions

• For an expiry, the previous request's wait cause decides the plan. Is it always on the same thread row in requests, or does a subagent's row need a join?

Related: #858, #867.

🤖 Generated with Claude Code