Add web product Phase 1 skeleton
This commit is contained in:
@@ -31,6 +31,9 @@ As of now:
|
||||
- a council-review skill forward-test plan directory now exists under `docs/tests/council-review-skill/`, with a shared execution contract and nine council workflow scenarios covering end-to-end flow, unanimous-only defaults, timeout/before-tally errors, explicit minority reporting, invalid report filters, strict tally semantics, malformed reviewer JSON, and target-file inputs
|
||||
- an execution-roadmap workflow now exists under `docs/roadmaps/active/` and `docs/roadmaps/archive/` for agent-level work traces and completion archives
|
||||
- a forward-looking web product monorepo plan now exists under `docs/web-product-monorepo.md`, defining the recommended React frontend, `chi` HTTP service, `cmd/orchd` entrypoint, and shared application/query layering for future web work
|
||||
- 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`
|
||||
- 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
|
||||
@@ -88,8 +91,9 @@ Current implementation status:
|
||||
- `Milestone 5: Strict Worktree Support` is complete
|
||||
- `Milestone 6: Waiting Primitives` is complete
|
||||
- `Milestone 7: Council Review` is complete
|
||||
- `Milestone 8: Web Product Phase 1 Skeleton` is complete
|
||||
|
||||
The council review v1 surface is now complete, including final report rendering and metadata persistence.
|
||||
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.
|
||||
|
||||
### Milestone 1: Go Skeleton
|
||||
|
||||
@@ -367,16 +371,59 @@ Remaining:
|
||||
|
||||
- none for the v1 council workflow
|
||||
|
||||
### Milestone 8: Web Product Phase 1 Skeleton
|
||||
|
||||
Goal:
|
||||
|
||||
- create the first durable web-product backbone without replacing the existing CLI workflows
|
||||
|
||||
Add:
|
||||
|
||||
- root `pnpm` workspace files
|
||||
- `apps/web`
|
||||
- `api/openapi.yaml`
|
||||
- `api/events.md`
|
||||
- `cmd/orchd`
|
||||
- `internal/app`
|
||||
- `internal/query`
|
||||
- `internal/httpapi`
|
||||
|
||||
Definition of done:
|
||||
|
||||
- the repository contains the agreed monorepo skeleton
|
||||
- `orchd` can serve a small read-only HTTP API against the existing database
|
||||
- the frontend workspace builds and can evolve independently in later milestones
|
||||
|
||||
Status:
|
||||
|
||||
- completed
|
||||
|
||||
Completed so far:
|
||||
|
||||
- root `package.json`, `pnpm-workspace.yaml`, and `pnpm-lock.yaml` now define the monorepo JS workspace
|
||||
- `apps/web` now contains a Vite + React + TypeScript + TanStack Router + TanStack Query frontend shell
|
||||
- `cmd/orchd` now opens the shared SQLite database, applies migrations, and serves a `chi` router with graceful shutdown handling
|
||||
- `internal/query` now exposes run list/detail, run tasks, blocked-task, and thread-detail read models for the web surface
|
||||
- `internal/app` now provides a thin web-service boundary over the new read service
|
||||
- `internal/httpapi` now owns HTTP routing, JSON/error helpers, and the initial read-only endpoints
|
||||
- `api/openapi.yaml` now documents the implemented read-only endpoints and response shapes
|
||||
- `api/events.md` now captures the planned SSE contract for the next realtime slice
|
||||
- `go test ./...` covers the new HTTP slice, and `pnpm run web:build` succeeds for the frontend workspace
|
||||
|
||||
Remaining:
|
||||
|
||||
- Phase 2 should turn the frontend shell into actual run, task-board, blocked-queue, and thread-detail pages using the new HTTP contract
|
||||
|
||||
## Immediate Next Task
|
||||
|
||||
If a new agent is taking over now, the next concrete step should be:
|
||||
|
||||
1. treat `Milestone 7: Council Review` as complete unless a new user request introduces a new council capability
|
||||
2. keep the authored inbox test-plan set in `docs/tests/inbox/` synchronized if future `orch` work changes shared CLI behavior
|
||||
3. if the next milestone is the web product, use `docs/web-product-monorepo.md` as the starting implementation shape for the monorepo, `cmd/orchd`, and `apps/web`
|
||||
4. choose the next milestone explicitly instead of reopening the completed council v1 slice
|
||||
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
|
||||
|
||||
The inbox implementation and its human-readable test-plan set are already in place, and `orch` now supports the main scheduler loop plus the complete council start/wait/tally/report workflow, so any next step should be a new milestone rather than unfinished council v1 work.
|
||||
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.
|
||||
|
||||
## Recommended Driver Choices
|
||||
|
||||
|
||||
@@ -0,0 +1,74 @@
|
||||
# Web Product Phase 1 Skeleton
|
||||
|
||||
## Status
|
||||
|
||||
- `completed`
|
||||
|
||||
## Owner
|
||||
|
||||
- Codex
|
||||
|
||||
## Started At
|
||||
|
||||
- `2026-03-20`
|
||||
|
||||
## Goal
|
||||
|
||||
- Implement the first web-product milestone slice described in `docs/web-product-monorepo.md` by creating the monorepo skeleton, a minimal `orchd` HTTP service, and the first read-oriented backend boundaries.
|
||||
|
||||
## Scope
|
||||
|
||||
- add an active execution trace for this web implementation workstream
|
||||
- add the initial monorepo workspace files and `apps/web` scaffold
|
||||
- add `cmd/orchd`, `internal/httpapi`, `internal/app`, and `internal/query`
|
||||
- expose a small read-only HTTP API for health, runs, run detail, blocked tasks, and thread detail
|
||||
- add initial API contract docs under `api/`
|
||||
- keep `docs/implementation-roadmap.md` synchronized with the new implementation state
|
||||
|
||||
## Checklist
|
||||
|
||||
- [x] create the active execution roadmap for the Phase 1 web skeleton workstream
|
||||
- [x] scaffold the monorepo workspace files and `apps/web`
|
||||
- [x] add `cmd/orchd` with a minimal `chi`-based HTTP server
|
||||
- [x] introduce initial shared app/query boundaries for read-only web endpoints
|
||||
- [x] add initial API contract documents under `api/`
|
||||
- [x] validate the new slice with builds or targeted tests
|
||||
- [x] update `docs/implementation-roadmap.md`
|
||||
- [x] archive this execution roadmap with a completion summary if the slice is fully complete
|
||||
|
||||
## Files
|
||||
|
||||
- `docs/roadmaps/active/web-product-phase1-skeleton.md`
|
||||
- `docs/implementation-roadmap.md`
|
||||
- `docs/web-product-monorepo.md`
|
||||
- `cmd/orchd/main.go`
|
||||
- `internal/httpapi/`
|
||||
- `internal/app/`
|
||||
- `internal/query/`
|
||||
- `internal/store/`
|
||||
- `api/openapi.yaml`
|
||||
- `api/events.md`
|
||||
- `apps/web/`
|
||||
- `package.json`
|
||||
- `pnpm-workspace.yaml`
|
||||
|
||||
## Decisions
|
||||
|
||||
- implement a narrow read-only backend slice first instead of starting with frontend pages
|
||||
- keep the first HTTP layer thin and let query/app packages own the web-facing backend boundary
|
||||
- preserve the existing CLI entrypoints while introducing the new service
|
||||
|
||||
## Blockers
|
||||
|
||||
- none
|
||||
|
||||
## Next Step
|
||||
|
||||
- start Phase 2 on top of the new `apps/web` and `orchd` skeleton by wiring real runs, run-detail, blocked-queue, and thread-detail screens to the read-only API
|
||||
|
||||
## Completion Summary
|
||||
|
||||
- added the first web-product skeleton described in `docs/web-product-monorepo.md`, including root `pnpm` workspace files, a standalone React frontend shell under `apps/web`, initial API contract documents under `api/`, and a new `cmd/orchd` HTTP service
|
||||
- introduced `internal/app`, `internal/query`, and `internal/httpapi` so the web backend has an explicit read-oriented boundary instead of letting handlers query storage ad hoc
|
||||
- implemented and validated the first read-only HTTP endpoints for health, runs, run detail, run tasks, blocked tasks, and thread detail
|
||||
- verified the slice with `go test ./...` and `pnpm run web:build`, then synchronized `docs/implementation-roadmap.md`
|
||||
Reference in New Issue
Block a user