toor
a623398fe8
The app had a single cyan accent, so every emphasis in the chat chain was a shade of the same hue. An approval waiting on the user, a tool that had already run, a streaming response and an outright error all looked equally urgent — the hue carried no information at all. The colours are now split by meaning rather than by shade, and the rule is documented at the top of variables.scss so it survives future edits: cyan the system itself brand, primary buttons, selection, user bubbles amber needs you approval cards, context about to fill lime the machine works tool execution, assistant output, streaming red something failed errors only — deliberately not a palette member Red staying out is the load-bearing part: when failure reuses the accent family the urgency signal disappears entirely. `--warning` moves from yellow (hue 85) to amber (hue 68) and `--success` from a muted green to fluorescent lime (hue 128). Because both are global tokens, every page using them changes hue in the same pass; the Arco `--green-*` / `--orange-*` bridges are updated with them so solid controls follow instead of staying behind. Six translucent companions (`--success-soft`, `--warning-line`, …) were added for fills and borders. On the chat surface: the approval card goes amber with a slow pulse on its icon — the only moving part in the chain, marking the one thing that is genuinely waiting. Tool-change cards and assistant bubbles take a 2px lime left edge meaning "already ran"; user bubbles get a cyan right edge so the two sides read apart without labels. The context meter is green under 60%, amber to 80%, red above; those thresholds already existed and only the colours were wrong. Rendering-layer only. No store logic, no /chat-run payload, no markup or event wiring.
Chat Chain Change Fragments
Add one Markdown fragment per PR when a change touches the Chat session chain,
Agent Bridge, compression, or Group Chat runtime paths documented in
docs/cli-chat-sessions.md.
Do not append new rows to docs/cli-chat-sessions.md. Keeping one fragment per
PR avoids merge conflicts when multiple branches change the chat chain at the
same time.
Use this shape:
---
date: YYYY-MM-DD
pr: 1234
feature: Short feature name
impact: One-sentence behavior impact
---
Optional extra notes.
If the PR number is not known yet, use pr: pending while the branch is local,
then update that same fragment after the PR is opened.