polish-wg-html

Metadata

Description

## Description
Two small polish items on the wg html output. User reports the html viewer is 'fantastic and really appears that it's doing the right thing' for general use (rsync to a public URL), but two specifics need refinement:

### Item 1: Chat task color
Chat tasks (`.chat-*` ids) currently render in yellow in the html output. They should render in the blue we use in the TUI for chat agents.

User quote: 'the chat in particular, those are shown as yellow, they should be shown as this nice blue color which we're using.'

Action:
- Find the TUI's chat-task color (likely in src/tui/viz_viewer/state.rs near the status palette — was cited as src/tui/viz_viewer/state.rs:271 (flash_color_for_status) by wg-html-v2's task log, but the chat-specific color may be elsewhere)
- Apply the same RGB triple to the html output's chat-task styling
- Verify dark theme + light theme both render correctly

### Item 2: Markdown description rendering
Task descriptions are typically well-formatted markdown but render as raw text in the side panel. Pretty-print them as HTML (with code blocks syntax-highlighted, lists, headings, links).

User quote: 'the description is usually well-formatted markdown, and frankly, we should use a nice system to pretty print that in HTML. However, I would like it to be possible to switch back and forth between raw and HTML, like pretty printed views. It should default to the HTML, though, and the switch should be unobtrusive.'

Spec:
- Default rendering: pretty-printed markdown (parsed via a sensible Rust crate — `pulldown-cmark` is the standard; a JS markdown renderer like `marked` would also work but adds runtime dep, prefer build-time rendering)
- Toggle UI: small button or icon in the corner of the description panel — 'raw' / 'pretty' label or a discreet code-vs-document icon. Default state shows pretty; clicking toggles to raw; clicking again toggles back.
- Unobtrusive: don't add a chrome bar or large button; small + corner-placed
- localStorage persistence: remember the user's last choice

## Validation
- [ ] Failing test or repro: open wg html output in browser, locate a chat task. Pre-fix: yellow. Post-fix: blue (matching TUI's chat color RGB triple).
- [ ] Live smoke: chat tasks render blue in BOTH dark and light themes
- [ ] Live smoke: clicking a task with markdown description shows pretty-printed version (lists rendered, code blocks syntax-highlighted, links clickable)
- [ ] Toggle button visible but unobtrusive; clicking switches to raw; clicking again switches back; choice persists across reload via localStorage
- [ ] Toggle button visible in both light and dark themes
- [ ] No regression of wg-html-v2's edge highlighting / theme detection / click-to-inspect side panel
- [ ] cargo build + cargo test pass
- [ ] Permanent smoke scenario added: assert chat task has blue color; assert markdown is parsed (not raw text) by default
- [ ] cargo install --path . was run before claiming done

Depends on

• done quality-pass-viewport
• done .assign-polish-wg-html

Required by

• (none)

Log

• 2026-04-30T16:26:55.845489120+00:00 Task paused
• 2026-04-30T16:27:40.458086734+00:00 USER OBSERVATION 2026-04-30: it's NOT just a chat-color mismatch — there's a deeper TUI vs HTML color inconsistency. User direct quote: 'the in-process tasks appear to be shown as yellow in the TUI, but then they're shown as blue in the HTML view. And then the chat is shown as yellow, but should be blue.' Parsed observations: - in-progress tasks in TUI: shown YELLOW - in-progress tasks in HTML: shown BLUE - chat tasks in HTML: shown YELLOW (as previously reported) - chat tasks should be BLUE (user's preference / TUI canonical) This conflicts with what wg-html-v2's task log claimed about the palette source (src/tui/viz_viewer/state.rs:271 → flash_color_for_status: InProgress = rgb(60,200,220) which IS blue/cyan; Open = rgb(200,200,80) which IS yellow). Possible explanations: 1. The user is seeing OPEN tasks (yellow per state.rs:271) and reading them as 'in-process' — i.e., what they perceive as 'in-process' is actually status=open. The HTML correctly uses blue for actual InProgress; the TUI does too, but the user's eye is misclassifying. 2. The TUI uses a DIFFERENT code path for status coloring than the one wg-html-v2 cited — maybe an override applies that overrides state.rs:271. If so, the cited 'palette source' is wrong. 3. Chat tasks specifically: regardless of status (typically Open while waiting for input), they should have a SPECIAL color override (blue) that distinguishes them from regular tasks. Neither TUI nor HTML currently does this — both fall back to status-based color, which for typical chat-in-Open is yellow. REVISED SCOPE for this task: ### Phase 1: investigate (don't ship yet) - Capture the actual rendered colors in TUI for: open task, in-progress task, chat task in any state - Capture the same for HTML - Document the truth — what color is what, in both renderers - Determine which is canonical (or whether either is): which color SHOULD chat tasks be? (User says blue; neither has it now) ### Phase 2: align - Pick a canonical palette (default: state.rs:271 if it's truly the source; another source if state.rs:271 is being overridden) - Add a chat-task-specific override (blue) in BOTH TUI and HTML - Apply consistently in both renderers ### Phase 3: ship the markdown rendering work (still in scope) The markdown-pretty-print + raw/pretty toggle stays as originally specified. UPDATED VALIDATION: - [ ] Side-by-side screenshot or text description: TUI vs HTML rendering of (open, in-progress, chat-Open, chat-InProgress, done, failed, blocked) — evidence the colors now match across both renderers - [ ] Chat tasks render BLUE in both TUI and HTML (this is a NEW override; chat-as-task currently has no special color) - [ ] No regression of other status colors - [ ] Markdown pretty-print + raw/pretty toggle (per original spec) still ships in this task
• 2026-04-30T16:28:25.338065137+00:00 Task published
• 2026-04-30T16:33:16.535000800+00:00 Spawned by coordinator --executor claude --model sonnet
• 2026-04-30T16:33:27.795428868+00:00 Starting implementation — no prior work on branch, beginning from scratch
• 2026-04-30T16:33:42.526472585+00:00 USER PALETTE CORRECTION 2026-04-30: actual TUI status colors are NOT what wg-html-v2's task log claimed. Correct TUI palette per user: - open: WHITE - abandoned: GRAY - in-progress: YELLOW - failed: RED - done: (presumably green; not directly stated in this message but implied by 'pending green' described next) - pending-eval / .evaluate-* / .flip-* in-progress: light green OR light orange — color depends on the TERMINAL state of the task being evaluated (recently-done evaluations are green-tinted, recently-failed are orange-tinted) - chat tasks: should be BLUE (special override regardless of status) So wg-html-v2's claim that state.rs:271 (flash_color_for_status) is the canonical palette is WRONG, OR that function isn't where the actual TUI colors come from. The user's empirical observation supersedes that citation. Action for the polish-wg-html agent: 1. Don't trust the wg-html-v2 task log's palette citation; re-derive the palette from what the TUI actually renders 2. Sample colors from a live TUI screenshot or terminal-color-extract for each status 3. Apply those exact colors to the html output 4. Add the chat-task BLUE override (new logic, not just palette match) 5. Handle the pending-eval color which depends on the underlying task's terminal state — light-green if task was done, light-orange if task was failed, presumably the orange we discussed for failed-pending-eval state earlier Updated palette table: | Status | TUI color | RGB hint (verify in code) | |--------|-----------|---------------------------| | open | white | rgb(255,255,255) — verify | | in-progress | yellow | rgb(200-255,200-255,80) — verify | | done | green | rgb(80,220,100) — likely the same as state.rs:271's done | | failed | red | rgb(220,60,60) — likely same as state.rs | | abandoned | gray | rgb(128,128,128) — verify | | blocked | (TBD — verify) | — | | pending-eval (after-done) | light green | a tinted variant of done | | pending-eval (after-fail) | light orange | a tinted variant of failed (matches implement-failed-pending's orange) | | chat task (any status) | blue | NEW — special override |
• 2026-04-30T16:35:40.336815699+00:00 Research complete: Color::Blue = rgb(36,114,200), pulldown-cmark already in deps, is_chat_task_id available. Starting implementation.
• 2026-04-30T17:01:03.713646275+00:00 cargo build + cargo test pass (21/21 html tests). All 4 html smoke scenarios pass. config test failure is pre-existing env issue unrelated to changes.
• 2026-04-30T17:01:38.300672596+00:00 Committed: 0aca60014 — pushed to origin wg/agent-1278/polish-wg-html
• 2026-04-30T17:02:18.449221646+00:00 Task pending eval (agent reported done; awaiting `.evaluate-*` to score)
• 2026-04-30T17:04:15.588688400+00:00 PendingEval → Done (evaluator passed; downstream unblocks)