feat(web): bootstrap cadence ui foundation
This commit is contained in:
@@ -34,6 +34,7 @@ As of now:
|
||||
- the Phase 1 web-product skeleton is now in place, including root `pnpm` workspace files, a standalone React app under `apps/web`, an initial OpenAPI/events contract under `api/`, and a new `cmd/orchd` HTTP service backed by `internal/app`, `internal/query`, and `internal/httpapi`
|
||||
- `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
|
||||
- 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
|
||||
@@ -92,8 +93,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
|
||||
|
||||
The council review v1 surface is complete, and the first web-product skeleton now exists as a separate monorepo workspace plus read-only HTTP backend slice.
|
||||
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.
|
||||
|
||||
### Milestone 1: Go Skeleton
|
||||
|
||||
@@ -414,16 +416,51 @@ 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
|
||||
|
||||
Goal:
|
||||
|
||||
- bootstrap the frontend UI layer on top of the Phase 1 shell and read-only backend 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
|
||||
|
||||
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
|
||||
- future web screens can compose from `cadence-ui` primitives instead of raw one-off HTML controls
|
||||
|
||||
Status:
|
||||
|
||||
- in progress
|
||||
|
||||
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
|
||||
|
||||
Remaining:
|
||||
|
||||
- build the actual runs list, run detail, blocked queue, and thread timeline screens on top of the Cadence UI primitives
|
||||
- install additional `cadence-ui` components on demand as the product surface expands
|
||||
|
||||
## Immediate Next Task
|
||||
|
||||
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. start `Phase 2: Read-Only Web UI` on top of the existing `apps/web` and `orchd` contract, beginning with runs list, run detail, blocked queue, and thread timeline views
|
||||
4. keep `api/openapi.yaml`, `api/events.md`, and `docs/web-product-monorepo.md` synchronized as the web surface expands
|
||||
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
|
||||
|
||||
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 Phase 1 skeleton now exists, so the next step should be Phase 2 product surface work 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 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.
|
||||
|
||||
## Recommended Driver Choices
|
||||
|
||||
|
||||
@@ -0,0 +1,62 @@
|
||||
# Web Frontend Cadence UI Bootstrap
|
||||
|
||||
## Status
|
||||
|
||||
- `completed`
|
||||
|
||||
## Owner
|
||||
|
||||
- Codex
|
||||
|
||||
## Started At
|
||||
|
||||
- `2026-03-20`
|
||||
|
||||
## Goal
|
||||
|
||||
- Bootstrap the `apps/web` frontend with copied-in `cadence-ui` components and shared token styles so Phase 2 web UI work can build on the project component library instead of the bare Vite scaffold.
|
||||
|
||||
## Scope
|
||||
|
||||
- create an execution trace for this frontend bootstrap slice
|
||||
- install the initial `cadence-ui` component set into `apps/web`
|
||||
- wire the Cadence token stylesheet into the frontend entrypoint
|
||||
- validate the frontend workspace build after the component copy-in
|
||||
- keep `docs/implementation-roadmap.md` synchronized with the new frontend state
|
||||
|
||||
## Checklist
|
||||
|
||||
- [x] create the active execution roadmap for the Cadence UI frontend bootstrap workstream
|
||||
- [x] install the initial `cadence-ui` component set into `apps/web`
|
||||
- [x] wire `apps/web/src/main.tsx` to load `cadence-ui` token styles
|
||||
- [x] validate the frontend workspace build and resolve any dependency gaps
|
||||
- [x] update `docs/implementation-roadmap.md`
|
||||
- [x] archive this execution roadmap with a completion summary if the slice is fully complete
|
||||
|
||||
## Files
|
||||
|
||||
- `docs/roadmaps/archive/web-frontend-cadence-ui-bootstrap.md`
|
||||
- `docs/implementation-roadmap.md`
|
||||
- `apps/web/package.json`
|
||||
- `apps/web/src/main.tsx`
|
||||
- `apps/web/src/cadence-ui/`
|
||||
- `pnpm-lock.yaml`
|
||||
|
||||
## Decisions
|
||||
|
||||
- start Phase 2 frontend work by copying in the shared component library instead of building bespoke primitives inside `apps/web`
|
||||
|
||||
## Blockers
|
||||
|
||||
- none
|
||||
|
||||
## Next Step
|
||||
|
||||
- build the first Phase 2 product screens in `apps/web` on top of the copied-in Cadence UI primitives, installing additional registry components only when those screens need them
|
||||
|
||||
## Completion Summary
|
||||
|
||||
- ran the `cadence-ui` registry installer from `/Users/xd/project/cadence-ui` and copied the initial component set into `apps/web/src/cadence-ui`, including shared tokens plus button, input, textarea, dialog, form, tabs, card, badge, and alert primitives
|
||||
- wired `apps/web/src/main.tsx` to import `./cadence-ui/tokens/styles.css` so the copied-in components share the library token base from app startup
|
||||
- installed the newly required frontend dependencies into the workspace, refreshed `pnpm-lock.yaml`, and verified the result with `pnpm run web:build`
|
||||
- synchronized `docs/implementation-roadmap.md` so Phase 2 frontend work now explicitly continues from the Cadence UI foundation
|
||||
Reference in New Issue
Block a user