docs(agents): describe the animation rule both forks actually follow

[rynfar]

The problem

AGENTS.md said, flatly:

No continuously repainting animations; they peg the GPU on high-refresh displays.

That line is inherited verbatim from upstream (line 150 of theirs, identical
text, arrived via b64ae880e, 2026-07-28). Neither fork follows it.

Surface	Infinite animations shipping today
web	live-activity-focus, live-activity-focus-counter, ultrathink-rainbow, ultrathink-chroma-shift
mobile	LoadingStrip, ConnectionStatusDot, and now the work-log shimmer

Upstream wrote the rule on 2026-07-28 and shipped an unbounded withRepeat
shimmer on 2026-08-30 in #8793. They have never revised the line.

This came up because that shimmer landed in Pylon via #223 and I flagged it for
sign-off against the rule. Checking the rule's provenance showed the rule was
the problem, not the shimmer.

What everyone actually does

The real practice is narrower and more useful than a blanket ban: continuous
animation is fine when it is scoped to a transient state and gated. Every
one of the animations above is opt-in and mounted only during a specific state
— live activity, ultrathink, loading, reconnecting, a running tool. None paints
at rest.

The reworded rule says that, and names thread-work-log.tsx's shimmer as the
reference, because it is the only thing in the repo that gates on all three of
reduce-motion, app state, and screen focus.

On following upstream

This is a deliberate divergence from upstream's wording, and worth being
explicit about: following the inherited text would mean rejecting upstream's own
code, which is not a coherent position for a fork that adopts from them. The
underlying intent — don't peg the GPU — is preserved and made checkable.

Known gap

LoadingStrip and ConnectionStatusDot predate this and gate on none of the
three; only cancelAnimation on cleanup. They are unchanged here to keep
this to one concern. Bringing them up to the rule is worth a follow-up — the
shimmer shows the pattern.

Reviewed and integrated with Claude Opus 5 in Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.5 KiB	13.5 KiB	+2 B (+0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	−6 B (−0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+8 B (+0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.1 KiB	57.1 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	9	9	0 (0.0%)	21	✅
Claude	Total thread wire	13.5 KiB	13.6 KiB	+32 B (+0.2%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.0 KiB	6.9 KiB	−16 B (−0.2%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+48 B (+0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	58.0 KiB	58.1 KiB	+44 B (+0.1%)	66.4 KiB	✅
Claude	Live turn messages	9	10	+1 (+11.1%)	21	✅

Baseline: 9d82e68 · PR result: ba05cc8 · 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: 109.5 KiB
• Claude decoded thread snapshot: 110.2 KiB

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