feat(web): build read-only operator views

docs/implementation-roadmap.md

@@ -35,6 +35,7 @@ As of now:
 - `orchd` now serves a minimal read-only web API with `chi`, including `/health`, runs list/detail, run task list, blocked-task list, and thread detail endpoints backed by the existing SQLite state
 - HTTP tests now cover the initial read-only `orchd` slice, and the new frontend workspace builds successfully with `pnpm run web:build`
 - Phase 2 frontend work has now started by bootstrapping `apps/web` with copied-in `cadence-ui` tokens and foundational components for button, input, textarea, dialog, form, tabs, card, badge, and alert, with the shared token stylesheet loaded from the frontend entrypoint
+- the first real Phase 2 read-only operator UI is now implemented in `apps/web`, including routed runs list, run detail, blocked queue, and thread timeline views backed by the existing `orchd` HTTP API, plus Tailwind v4 consumer wiring so the source-owned Cadence UI components render correctly in the app
 - a repo-local `scripts/package_skill_clis.sh` packaging flow now builds bundled skill CLI assets for `inbox`, `orch`, and `council-review`
 - `orch` now implements `run init/show`, `task add`, `dep add`, `ready`, `dispatch`, `reconcile`, `wait`, `blocked`, `answer`, `retry`, `reassign`, `cancel`, `cleanup`, and `status`
 - `orch` can create runs, gate tasks through dependencies, dispatch work through `inbox`, reconcile worker thread state back into task state, answer blocked tasks, retry or reassign work, cancel tasks or runs, clean attempt worktrees, and create per-attempt Git worktrees during strict dispatch
@@ -93,9 +94,9 @@ Current implementation status:
 - `Milestone 6: Waiting Primitives` is complete
 - `Milestone 7: Council Review` is complete
 - `Milestone 8: Web Product Phase 1 Skeleton` is complete
-- `Milestone 9: Web Product Phase 2 UI Foundation` is in progress
+- `Milestone 9: Web Product Phase 2 Read-Only Operator UI` is complete for the initial operator surface
 
-The council review v1 surface is complete, the first web-product skeleton now exists as a separate monorepo workspace plus read-only HTTP backend slice, and Phase 2 frontend work has started on top of the internal Cadence UI component library.
+The council review v1 surface is complete, the first web-product skeleton now exists as a separate monorepo workspace plus read-only HTTP backend slice, and the first real operator-facing Phase 2 read-only web views now exist on top of the internal Cadence UI component library.
 
 ### Milestone 1: Go Skeleton
 
@@ -416,38 +417,45 @@ Remaining:
 
 - Phase 2 should turn the frontend shell into actual run, task-board, blocked-queue, and thread-detail pages using the new HTTP contract
 
-### Milestone 9: Web Product Phase 2 UI Foundation
+### Milestone 9: Web Product Phase 2 Read-Only Operator UI
 
 Goal:
 
-- bootstrap the frontend UI layer on top of the Phase 1 shell and read-only backend contract
+- implement the first real operator-facing read-only web UI on top of the Phase 1 shell and current `orchd` API contract
 
 Add:
 
 - copied-in `cadence-ui` primitives and token CSS under `apps/web/src/cadence-ui`
-- app-wide token style wiring in the frontend entrypoint
-- any additional component installs needed as real screens land
+- Tailwind v4 consumer setup so the copied-in Cadence UI source renders correctly in the app
+- routed screens for runs list, run detail, blocked queue, and thread timeline
+- typed frontend read helpers for the current `orchd` endpoints
 
 Definition of done:
 
 - `apps/web` imports the shared Cadence token stylesheet from the frontend entrypoint
-- the initial shared component set builds successfully inside the workspace
+- the Cadence UI source-owned components render correctly inside the consumer app
+- the first routed read-only operator screens ship against the existing `orchd` contract
 - future web screens can compose from `cadence-ui` primitives instead of raw one-off HTML controls
 
 Status:
 
-- in progress
+- completed for the first read-only operator slice
 
 Completed so far:
 
 - `apps/web/src/cadence-ui/` now contains copied-in Cadence UI tokens plus foundational components for button, input, textarea, dialog, form, tabs, card, badge, and alert
 - `apps/web/package.json` now includes the required Radix, `react-hook-form`, `motion`, and utility dependencies for the copied-in components
 - `apps/web/src/main.tsx` now imports `./cadence-ui/tokens/styles.css`
-- `pnpm install` refreshed the workspace lockfile, and `pnpm run web:build` succeeds with the copied-in component slice
+- `apps/web` now includes Tailwind v4 consumer wiring in Vite and the global stylesheet so the copied-in Cadence UI utility classes render correctly
+- `apps/web` now includes a typed frontend read layer for runs, run detail, blocked queue aggregation, and thread detail
+- `apps/web` now ships routed runs list, run detail, blocked queue, and thread timeline pages using Cadence UI source-owned components for cards, tabs, alerts, inputs, badges, buttons, dialogs, and textareas
+- the run detail view now includes grouped task boards and blocked-task summaries, while the thread timeline view now shows message payload and artifact metadata inspectors
+- `pnpm run web:build` succeeds for the new operator UI, and local Vite-to-`orchd` proxy smoke checks confirm the frontend can read the seeded runs, blocked, and thread endpoints through the dev server
 
 Remaining:
 
-- build the actual runs list, run detail, blocked queue, and thread timeline screens on top of the Cadence UI primitives
+- add operator write actions such as answer, retry, reassign, and cancel on top of the new read-only screens
+- add council result/report views and realtime event handling on top of the current routed UI
 - install additional `cadence-ui` components on demand as the product surface expands
 
 ## Immediate Next Task
@@ -456,11 +464,13 @@ If a new agent is taking over now, the next concrete step should be:
 
 1. treat `Milestone 8: Web Product Phase 1 Skeleton` as complete unless a new user request reopens the backend skeleton itself
 2. keep the authored inbox test-plan set in `docs/tests/inbox/` synchronized if future `orch` or web work changes shared CLI-visible behavior
-3. continue `Milestone 9: Web Product Phase 2 UI Foundation` by implementing the first runs list, run detail, blocked queue, and thread timeline screens on top of the existing `apps/web` and `orchd` contract
-4. install additional `cadence-ui` components on demand when those screens need them, instead of reintroducing bespoke primitives into `apps/web`
-5. keep `api/openapi.yaml`, `api/events.md`, and `docs/web-product-monorepo.md` synchronized as the web surface expands
+3. treat `Milestone 9: Web Product Phase 2 Read-Only Operator UI` as complete for the initial operator surface and build the next web slice on top of the shipped read pages rather than replacing them
+4. start the next web phase by wiring operator write actions such as answer, retry, reassign, and cancel into the existing runs, blocked, and thread views
+5. add council result/report screens and realtime event handling after the operator write path is clear
+6. install additional `cadence-ui` components on demand when those screens need them, instead of reintroducing bespoke primitives into `apps/web`
+7. keep `api/openapi.yaml`, `api/events.md`, and `docs/web-product-monorepo.md` synchronized as the web surface expands
 
-The inbox implementation and its human-readable test-plan set are already in place, `orch` supports the main scheduler loop plus the complete council start/wait/tally/report workflow, and the web product is now past the bare frontend shell stage, so the next step should be actual Phase 2 product screens built on top of the Cadence UI foundation rather than reopening earlier milestones.
+The inbox implementation and its human-readable test-plan set are already in place, `orch` supports the main scheduler loop plus the complete council start/wait/tally/report workflow, and the web product now has its first real operator-facing read surfaces, so the next step should be write-capable operator workflows and council/realtime expansion rather than reopening the frontend shell or basic read pages.
 
 ## Recommended Driver Choices
 

docs/roadmaps/archive/web-phase2-read-only-ui.md

@@ -0,0 +1,70 @@
+# Web Phase 2 Read-Only UI
+
+## Status
+
+- `completed`
+
+## Owner
+
+- Codex
+
+## Started At
+
+- `2026-03-20`
+
+## Goal
+
+- Implement the first real Phase 2 operator UI in `apps/web` by shipping the read-only runs list, run detail, blocked queue, and thread timeline views on top of the existing `orchd` HTTP API and Cadence UI source-owned components.
+
+## Scope
+
+- create an execution trace for the Phase 2 read-only UI workstream
+- wire the frontend to the existing read-only API contract
+- implement routed views for runs list, run detail, blocked queue, and thread timeline
+- reuse Cadence UI source-owned components instead of introducing new foundational UI primitives
+- validate the frontend build and keep `docs/implementation-roadmap.md` synchronized
+
+## Checklist
+
+- [x] create the active execution roadmap for the Phase 2 read-only UI workstream
+- [x] inspect the current frontend shell and backend read contract
+- [x] add the frontend data layer and route structure for the Phase 2 read-only views
+- [x] implement the runs list, run detail, blocked queue, and thread timeline screens
+- [x] ensure Cadence UI styles render correctly in the consumer app
+- [x] validate the frontend build and fix any type or integration issues
+- [x] update `docs/implementation-roadmap.md`
+- [x] archive this roadmap with a completion summary if the slice is fully complete
+
+## Files
+
+- `docs/roadmaps/archive/web-phase2-read-only-ui.md`
+- `docs/implementation-roadmap.md`
+- `apps/web/package.json`
+- `apps/web/src/app.tsx`
+- `apps/web/src/features/operator-console.tsx`
+- `apps/web/src/lib/api.ts`
+- `apps/web/src/lib/format.ts`
+- `apps/web/src/styles.css`
+- `apps/web/src/vite-env.d.ts`
+- `apps/web/vite.config.ts`
+- `pnpm-lock.yaml`
+
+## Decisions
+
+- keep the first Phase 2 UI slice read-only and route it against the existing HTTP API instead of coupling UI delivery to new backend mutations
+- prefer composition from the copied-in Cadence UI source over new hand-rolled UI primitives
+
+## Blockers
+
+- none
+
+## Next Step
+
+- build the next web slice on top of the shipped read-only screens by adding operator write actions, council views, and realtime event handling without replacing the new routed operator shell
+
+## Completion Summary
+
+- replaced the placeholder `apps/web` landing screen with a routed read-only operator UI that now ships runs list, run detail, blocked queue, and thread timeline pages backed by the existing `orchd` API
+- added a typed frontend read layer for the current HTTP contract, including client-side blocked queue aggregation across runs and thread timeline payload/artifact rendering
+- wired Tailwind v4 into the consumer app so the copied-in Cadence UI source-owned components render correctly, and used those components throughout the new pages instead of introducing new foundational UI primitives
+- validated the slice with `pnpm run web:build`, seeded a local demo run/thread dataset through the existing `orch` and `inbox` CLIs, and verified the Vite dev server can proxy the runs, run detail, and thread endpoints through to `orchd`