wg-html-v2

Metadata

Description

## Description

The previous `wg html` redesign (commit 69f791f9a, agent-1004) shipped clickable task ids in monospace ASCII output, but the user reports it 'didn't quite land' — there's a gap between what was implemented and the actual vision. This task closes that gap.

## Vision

User framing: 'this is kind of version zero of a distributed system. Just a way to view. The wg viz is the whole beginning, the nucleation of everything. The ability to visualize the graph is actually essential.'

The web view should be a **read-only TUI sibling**: every element you can interact with in the TUI should be clickable in the web view, opening an overlay/side panel with the same task details the TUI shows. No chat (this is viewing-only). The viz IS the interface.

## Concrete spec — close the gap from v1

### 1. Rendering substrate: `wg viz --all` output, monospace, all-tasks-by-default
- Render the full output of `wg viz --all` (not just public tasks unless --public-only flag is passed; current default is wrong direction for the use case)
- Preserve ASCII layout exactly — same characters, same alignment, same colors as TUI
- Compose with the existing `--since` time filter from wg-html-add (commit 52f8a4198)

### 2. Universal clickability — match TUI interaction model
Every interactive element in the TUI should be clickable in the web view:
- **Task ids** in node labels → open task detail overlay
- **Status indicators / glyphs** → same overlay (clicking a status icon should work, not just the task id text)
- **Edge labels / dependency markers** → if the TUI shows edge info on click, mirror that
- **Header / cycle indicators** → relevant detail overlay

Reference: the TUI's tui-detail-view (commit b07601fcd, agent-953) shows what clickable detail looks like in TUI. Mirror that pattern.

### 3. Edge highlighting on selection (the specific ask)
User quote: 'see the specific pattern of before and after edges drawn in the colors that we're using in the TUI.'

When a task is selected (clicked):
- Highlight all `--after` edges (incoming dependencies) in the TUI's 'before' edge color
- Highlight all `--before` / impact edges (outgoing dependents) in the TUI's 'after' edge color
- Use the EXACT same color values as the TUI's terminal palette (not approximations)
- Other edges dim out so the selection's edges pop

### 4. Theme support — match TUI dark/light
- Default to **dark theme** (black/very-dark background, light text) — matches TUI default
- Support **light theme** with same toggle UX as the TUI
- Theme toggle button in the page header (persists via localStorage)
- Color palette MUST be identical to TUI palette files — pull from the same source if a shared color module exists; otherwise extract carefully and document the mapping

### 5. Detail overlay layout (per user)
- Click a node → overlay opens to the right (desktop) or below (narrow screens / mobile)
- Overlay contents (mirror TUI detail view): title, status, exec mode, agent, model, executor, description (markdown rendered), recent log entries, evaluation scores (eval + FLIP + dimension breakdown), agent archives if present
- Clicking a dependency link inside the overlay updates the overlay (no hard navigation)
- Close button + ESC to close
- Multiple overlays? Probably no — one at a time, replace on new click

### 6. Stay rsync-friendly
- Static files only. No server. No XHR to a backend (inline JSON or per-task JSON files alongside HTML).
- Vanilla JS for interactions. No framework.

## Validation
- [ ] Live smoke: `wg html` (with no flags — default should be all-tasks, dark theme) rendered on this project
- [ ] All task ids and status glyphs are clickable; clicking opens the detail overlay
- [ ] Selecting a node highlights its before-edges and after-edges in TUI-matching colors; non-selected edges dim
- [ ] Detail overlay contents match what `wg show <task>` plus `wg log <task> --agent` show in the terminal
- [ ] Theme toggle works; light theme is visually correct (not just 'inverted dark', actually styled)
- [ ] Color values verified to match TUI palette (cite source file or document the mapping)
- [ ] Page works as a static rsync target (open file:// URL, no server needed) with all interactivity functional
- [ ] cargo build + cargo test pass
- [ ] Permanent smoke scenario added that loads the rendered HTML and asserts key elements (e.g., querySelector for clickable task ids, edge-highlight class on selection); this task id in owners
- [ ] cargo install --path . was run before claiming done
- [ ] Record before/after screenshots in task log so the user can verify the gap is closed

Depends on

• done verify-tui-light
• done quality-pass-20260429t001500
• done .assign-wg-html-v2

Required by

• (none)

Log

• 2026-04-29T00:31:17.534738911+00:00 Task paused
• 2026-04-29T00:31:34.355075025+00:00 Task published
• 2026-04-29T00:31:56.810960924+00:00 Lightweight assignment: agent=Careful Programmer (f5143935), exec_mode=full, context_scope=task, reason=Careful Programmer is best fit: programmer role matches frontend/backend implementation, Careful tradeoff suits TUI-parity color matching and smoke test validation, proven track record (244 tasks, 0.77 score)
• 2026-04-29T00:32:42.735341027+00:00 USER REFINEMENT (2026-04-29 00:18): Theme detection should auto-detect via the browser's prefers-color-scheme media query, then allow manual override via the theme toggle button. - On first load: read `window.matchMedia('(prefers-color-scheme: dark)').matches` and apply dark or light accordingly. This makes the page respect the user's OS-level dark mode setting (macOS Auto, Windows app theme, GNOME night mode, etc.). - After user clicks the manual toggle: persist their explicit choice via localStorage and stop auto-following the OS preference for that browser. - Optional: also listen for prefers-color-scheme changes during a session and follow them UNLESS the user has explicitly toggled. User quote: 'we do want the web pages to be at least responsive to the default settings the user might be expecting. Like if the user's using some kind of dark mode type thing, then we should basically detect that and try to render dark mode. Or if they're using light mode or regular mode, it should be light version. Frankly, it could be black all the time. The dark mode would be fine for me.' Implication: default-to-dark is acceptable as a user preference but the BETTER product behavior is auto-detect-then-allow-override. Implement the better version. CSS media queries make this trivial — `@media (prefers-color-scheme: dark) { ... }` plus a JS check on load.
• 2026-04-29T01:09:31.075918386+00:00 Spawned by coordinator --executor claude --model opus
• 2026-04-29T01:12:51.771664068+00:00 Starting v2: switching to in-process generate_viz_output_from_graph (gives char_edge_map for per-edge highlighting), strip ANSI, emit task-link + edge spans, dark/light theme via prefers-color-scheme + manual toggle, mirror tui-detail-view in side panel.
• 2026-04-29T01:40:46.137155773+00:00 Implementation complete. Files: src/html.rs (rewritten), src/html_assets/style.css (rewritten), src/html_assets/panel.js (new), src/cli.rs (--public-only flag + Viz in supports_json), src/main.rs (wire-through), src/commands/viz/mod.rs (run_json), tests/integration_html.rs (+5 v2 tests, 18 total pass), tests/smoke/scenarios/wg_html_ascii_viz.sh (updated for v2), tests/smoke/scenarios/wg_html_v2_tui_parity.sh (new), tests/smoke/manifest.toml (wg-html-v2 owner).
• 2026-04-29T01:40:57.964515972+00:00 Validation summary (live smoke on this project's .workgraph): wg html (no flags) wrote 655 pages to /tmp/wg_html_after; index.html 941 lines; 162 .task-link spans (clickable task IDs covering whole 'task-id (status...)' label); 1200 .edge spans with data-edges='from>to' attribution per character; 654 entries in window.WG_TASKS, 654 in window.WG_EDGES, 3 in window.WG_CYCLES (all valid JSON via python json.JSONDecoder).
• 2026-04-29T01:40:58.002345272+00:00 TUI palette source mapping (cited in CSS comments): status colors from src/tui/viz_viewer/state.rs:271 (flash_color_for_status) — Done rgb(80,220,100), Failed rgb(220,60,60), InProgress rgb(60,200,220), Open rgb(200,200,80), Blocked rgb(180,120,60), etc. Edge highlight colors from src/tui/viz_viewer/render.rs:1500-1510 — magenta (188,63,188) = upstream deps, cyan (17,168,205) = downstream consumers, yellow (229,229,16) = cycle. Light-theme values are hand-tuned darkenings (not just inverted dark) per task spec.
• 2026-04-29T01:41:08.688576303+00:00 Before/after evidence (cannot capture screenshots; rendering side-effects shown via grep + JSON validity). BEFORE (v1, commit 69f791f9a): no edge attribution per character; no theme support; default = public-only; subprocess captured plain ASCII without structural metadata, so click highlight 'specific pattern of before/after edges' was impossible. AFTER (v2, this commit): wg viz --json sidecar exposes char_edge_map; html.rs strips ANSI + walks per-character emitting <span class='edge' data-edges='from>to'> for each connector cell; panel.js applies is-upstream / is-downstream / is-cycle / is-selected classes via CSS variables backed by TUI RGB triples. Theme = prefers-color-scheme on first load, persists via localStorage on manual toggle. Default flag = --all replaced with --public-only opt-in. To verify: open file:///tmp/wg_html_after/index.html in a browser, click a task id, observe the connecting edges colorize while unrelated rows dim.
• 2026-04-29T01:41:12.264580391+00:00 Validated: cargo build clean (15 pre-existing warnings unrelated). cargo test --test integration_html: 18/18 PASS. Pre-existing config::tests::test_global_config_path failure also fails on stash (unrelated to this change). cargo install --path . completed. Live smoke: tests/smoke/scenarios/wg_html_ascii_viz.sh PASS, tests/smoke/scenarios/wg_html_v2_tui_parity.sh PASS (latter is new — pins all v2 contracts: edge data-edges attribution, RGB palette, dual-theme CSS, no fetch/XHR in panel.js, WG_EDGES reachability).
• 2026-04-29T01:41:45.568528281+00:00 Committed: 928c1ea48 — pushed to remote
• 2026-04-29T01:41:57.301741041+00:00 Pushed to origin/wg/agent-1049/wg-html-v2 (928c1ea48)
• 2026-04-29T01:42:06.126422061+00:00 Task pending eval (agent reported done; awaiting `.evaluate-*` to score)
• 2026-04-29T01:45:56.367004067+00:00 PendingEval → Done (evaluator passed; downstream unblocks)