← graph

html-graph-view

HTML graph view: rsync-able static site mirroring wg viz/tui semantics, public-filtered

Metadata

Statusdone
Assignedagent-919
Agent identityf51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e
Created2026-04-28T20:17:02.185396943+00:00
Started2026-04-28T20:19:06.872020798+00:00
Completed2026-04-28T20:46:19.546398038+00:00
Tagseval-scheduled
Eval score0.80
└ blocking impact0.85
└ completeness0.82
└ constraint fidelity0.70
└ coordination overhead0.85
└ correctness0.78
└ downstream usability0.76
└ efficiency0.80
└ intent fidelity0.87
└ style adherence0.82

Description

Description

User wants a static HTML site that mirrors the workgraph state. Goal: rsync the output to a remote endpoint and get a constantly-evolving public mirror of the project's graph. Visual semantics should match what wg viz and the TUI already show — same colors, same node shapes, same status meanings.

User quote: 'a HTML view of the graph. idea is that this is something we could rsync to a remote endpoint to get a constantly evolving model of the graph in public selectively. but the html should be a whole tree, browsable, with much the same semantics as we have in wg viz and wg tui.'

v1 spec (pre-decided defaults — see 'Forks for user' below to flag any to flip BEFORE coding)

  • Output: a directory of static HTML/CSS/SVG files. No JS-only frameworks (React/Vue/etc); plain HTML + minimal vanilla JS only if needed for tree expand/collapse. Default output dir: ./public/ (configurable via --out).
  • Index page: full DAG rendering as inline SVG (auto-layout — graphviz dot if available, else a simple layered layout we generate ourselves). Status colors match TUI conventions.
  • Per-task pages: one HTML file per task, with title, status, description, dependencies (links to neighbor tasks), agents that worked on it, evaluation scores, completion time. Links between tasks make the whole tree browsable.
  • Visibility filter: include only tasks with visibility = public (the field already exists in the graph model). Internal/peer tasks are EXCLUDED from output. Document this clearly in the rendered index page footer.
  • Trigger: a new command wg html [--out PATH]. No auto-hook in v1 — user wires it to their own cron / git hook / CI step.
  • Sanitization: when rendering description bodies, strip anything tagged for redaction (if such a mechanism exists; otherwise treat full description as published when visibility=public — but verify no API keys or paths-to-private-data leak).

Forks for user (flag BEFORE worker starts coding if any need to flip)

  1. SVG (recommended) vs ASCII-in-<pre> (closer to wg viz's exact look)?
  2. Default output dir — ./public/ (chosen) vs ./.workgraph/html/ (more 'private by default')?
  3. Auto-hook on wg done in v1? (chosen: no, keep manual)
  4. Include archived tasks? (chosen: no for v1; ties to the parallel archival research task)

Out of scope

  • Live SPA / WebSocket-based real-time updates
  • Authentication / per-viewer filters
  • Search across the rendered site (let user grep / browser find)
  • Hosting / deployment (rsync is the user's responsibility — we just emit files)

Why no design task first

The contract is concrete (rsync target, public-filter, mirror viz/tui semantics). The pre-decided defaults above match what the user described. Flag any fork to flip before the impl task dispatches.

Validation

  • New wg html command exists and accepts --out PATH
  • Failing test first: wg html against a fixture graph produces an index.html with N task nodes (N = count of public tasks in fixture)
  • Failing test: tasks marked visibility = internal do NOT appear in any output file (grep the output dir)
  • Per-task page links resolve (no broken links across the rendered site)
  • Status colors in SVG/CSS match the TUI's color scheme (visual check; reference src/tui/ for the palette)
  • Run wg html against this repo's actual graph; open in a browser; verify (a) DAG layout is readable, (b) all expected public tasks appear, (c) clicking a node opens its detail page, (d) deps go both ways
  • cargo build + cargo test pass with no regressions
  • No new heavyweight runtime dependencies (no chromium-headless, no webpack — keep it static-files-only)

Depends on

Required by

Log