fix(ui,cli): count down provider retry wait from the event timestamp

[me2seeks]

Fixes #3393.

Problem

When a provider returns a long Retry-After (e.g. a subscription quota window reset — kimi-k3 / OpenCode Go returns ~4.5h when its 5h quota is exhausted), the retry indicator pins the original delay for the entire sleep: Retrying in 16083s (2/10) never counts down, indistinguishable from a hung process. The TUI's 1s heartbeat re-renders the strip and the sibling Working… <elapsed> counter ticks, but the retry line renders a static delayMs snapshot.

Fix

Render the remaining wait as delayMs - (now - retry.ts) in both clients:

• TUI activity strip (pi-transcript.ts): reuses the shared duration formatter, so hours-long waits read 4h 28m 3s instead of a raw five-digit second count; floors at 0s.
• Desktop banner (chat-turn.tsx): follows the same determinism contract as the turn's elapsed clock — first paint and frozen fixtures show the provider's original delay; live mounts tick the countdown once per second.

Scope

Presentation layer only: the wait itself is unchanged. Honoring a multi-hour Retry-After from a subscription quota window is intentional (the turn resumes when quota resets); whether the runtime should additionally cap extreme values is a separate policy question noted in the issue.

Tests

• New regression tests on both sides: countdown ticks down, floors at zero, started phase shows no countdown.
• Full cli (338) and ui (185) suites pass; biome lint/format clean.

AI use

• Generative tooling made a substantive contribution
• No generative tool made a substantive contribution

Tool(s) and scope: Maka (AI coding agent) authored the implementation and tests; the diff was human-reviewed before push. Generated-by: Maka trailer will be added to the branch commit on its next update (local worktree had uncommitted changes, history rewrite skipped this round).

[jackwener]

Automated review of exact head 5eb038d3ddb75cb0d8eea8a614ac2c6da8a407a1.

The current main UI and TUI both render the original delayMs, so the bug still exists. The implementation correctly derives remaining time from the event timestamp, clamps at zero, preserves the frozen-fixture contract, and cleans up the one-second interval. The focused UI build and new UI tests passed locally (2/2). I found no P0-P2 product defect.

Non-blocking test-quality gap: provider-retry-countdown.test.tsx proves the timestamp calculation by rerendering with an older event, but it never advances the mounted interval. The test would still pass if the interval were deleted. Please consider advancing fake timers on one mounted banner so the live ticking behavior is pinned directly.

Merge readiness: not ready yet. This exact head has no hosted checks and still requires independent human review.

[Astro-Han]

Thanks for fixing the frozen retry presentation without moving retry authority out of Runtime. I reviewed exact head 5eb038d3ddb75cb0d8eea8a614ac2c6da8a407a1. Reusing the TUI heartbeat and keeping the Desktop timer local to the banner are both appropriately scoped. I left two P2 presentation-contract issues below.

AI-assisted review disclosure: Codex performed the exact-head analysis, and an independent reviewer agent adversarially checked clock semantics, remote Runtime Host paths, timer lifecycle, accessibility, and regression coverage. I verified the source paths, live state, and final severity.

[Astro-Han]

Thanks for deriving the remaining delay from the event rather than storing another countdown state. [P2] retry.ts is produced by the Runtime Host clock, while nowMs comes from the Client clock. On the supported remote-Host path, ordinary clock skew can therefore make a multi-hour retry display 0s immediately or show substantially more time than the Host will actually wait. Could the Host projection provide an authoritative remaining value, or otherwise establish a single clock domain before the Client starts ticking it down? The same calculation in the TUI has the same boundary.

[Astro-Han]

Thanks for keeping the countdown visually live. [P2] Because this banner is a role="status" live region, changing its title every second can cause screen readers to announce every tick—potentially for hours during a quota wait. Could the changing visual countdown be hidden from the live region while exposing a stable accessible status, following the pattern already used by the running-turn indicator? A focused accessibility regression would help keep the timer from reintroducing this.

[Astro-Han]

Thanks @me2seeks — reviewed at exact head 5eb038d3ddb75cb0d8eea8a614ac2c6da8a407a1. The countdown itself is correct: the elapsed portion is subtracted properly, the clamps prevent negative values, and both test files pin Date via mock timers so there is no wall-clock flakiness on slow machines.

One P2 and one P3 below, both about scope rather than about the calculation being wrong.

The P2 is that the fix does not reach users who have reduced motion enabled — for them the banner still shows the full original delay, frozen, which is the #3393 symptom this PR sets out to remove. The determinism contract in the comment is right for frozen fixtures and SSR; the issue is that a real accessibility preference is currently on the same side of that gate.

The P3 is that UI and CLI each carry their own copy of delayMs - (now - ts), and the two have already diverged on the floor: the UI clamps to 1 s, the CLI to 0 s, and each side's new test pins its own value.

The clock-domain question and the role="status" announcement cadence are already covered in earlier reviews on this PR; not repeating them here.

---

This review was AI-assisted. It is not a substitute for independent human review by a committer.

[Astro-Han]

[P2] This gate covers both the interval and the initial setNowMs(Date.now()), so under reduced motion nowMs stays undefined for the lifetime of the banner.

remainingMs then falls through to retry.delayMs — the full original delay, never decremented. For a provider-mandated wait that can span hours, a reduced-motion user sees exactly the frozen number that #3393 describes, which is the symptom this PR is fixing everywhere else.

isTimeDrivenMotionEnabled returns false whenever the element or an ancestor matches [data-maka-reduced-motion="true"], and the Banner carrying rootRef is itself that root, so this is reachable through the ordinary preference rather than only in fixtures. It is the only writer of nowMs in this component, and there is no fallback in the remainingMs expression.

The determinism contract in the comment above is sound for frozen fixtures and SSR — the gap is that a genuine accessibility preference currently shares a gate with them. Taking the initial measurement outside the gate and leaving only the setInterval behind it would give reduced-motion users a correct static value that reflects the time already waited, while still not animating:

useEffect(() => {
  if (retry.phase !== 'scheduled') return;
  setNowMs(Date.now());
  if (!isTimeDrivenMotionEnabled(rootRef.current)) return;
  const tick = window.setInterval(() => setNowMs(Date.now()), ELAPSED_TICK_MS);
  return () => window.clearInterval(tick);
}, [retry.phase, retry.ts]);

[Astro-Han]

[P3] The same delayMs - (now - ts) calculation now exists here and in pi-transcript.ts, and the two copies have already drifted apart at the boundary: this side clamps with Math.max(1, …) so an expired countdown reads 1s, while formatRetryCountdown on the CLI side clamps with Math.max(0, …) and reads 0s.

Each side's new test pins its own value, so the divergence is now locked in by tests rather than flagged by them — the same wait renders differently depending on where the user is looking.

Worth extracting the remaining-time computation (and one agreed floor) into a shared helper, e.g. in @maka/core, so the next change to the formula cannot land on only one surface.