chore(monorepo): bootstrap workspace packages
This commit is contained in:
@@ -37,6 +37,7 @@ As of now:
|
||||
- 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 repository-level skill workspace monorepo migration plan now exists under `docs/skill-workspace-monorepo.md`, defining the target split between runtime packages under `packages/`, agent-facing skill bundles under `skills/`, support apps under `apps/`, and package-based skill packaging flows
|
||||
- the first migration phase for the skill workspace monorepo is now complete: root `go.work` exists, `pnpm-workspace.yaml` now discovers `packages/*`, empty runtime module roots now exist under `packages/`, and a declarative `scripts/skill-bundles.json` plus `scripts/package_skill_runtimes.sh` scaffold now define package-oriented skill bundle metadata from the repo root
|
||||
- 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
|
||||
@@ -96,9 +97,9 @@ Current implementation status:
|
||||
- `Milestone 7: Council Review` is complete
|
||||
- `Milestone 8: Web Product Phase 1 Skeleton` is complete
|
||||
- `Milestone 9: Web Product Phase 2 Read-Only Operator UI` is complete for the initial operator surface
|
||||
- `Milestone 10: Skill Workspace Monorepo Migration` is planned
|
||||
- `Milestone 10: Skill Workspace Monorepo Migration` is in progress
|
||||
|
||||
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, the first real operator-facing Phase 2 read-only web views now exist on top of the internal Cadence UI component library, and the repository now has an explicit migration plan for becoming a true skill workspace monorepo.
|
||||
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, the first real operator-facing Phase 2 read-only web views now exist on top of the internal Cadence UI component library, and the repository has now started the actual migration into a true skill workspace monorepo.
|
||||
|
||||
### Milestone 1: Go Skeleton
|
||||
|
||||
@@ -482,34 +483,38 @@ Definition of done:
|
||||
|
||||
Status:
|
||||
|
||||
- planned
|
||||
- in progress
|
||||
|
||||
Completed so far:
|
||||
|
||||
- the repository-level migration design is captured in `docs/skill-workspace-monorepo.md`
|
||||
- the target package split now distinguishes `coord-core`, runtime packages, skill bundles, and support apps
|
||||
- the migration plan now defines phased extraction for `coord-core`, `inbox-runtime`, `orch-runtime`, `orchd-runtime`, and `repo-memory-runtime`
|
||||
- root `go.work` now includes the current root module plus the initial runtime package module roots under `packages/`
|
||||
- `pnpm-workspace.yaml` now includes `packages/*`, and root `package.json` now exposes monorepo bundle planning and validation scripts
|
||||
- initial module roots now exist for `packages/coord-core`, `packages/inbox-runtime`, `packages/orch-runtime`, `packages/orchd-runtime`, and `packages/repo-memory-runtime`
|
||||
- `scripts/skill-bundles.json` now records the first package-oriented skill bundle metadata, including the future `repo-memory` runtime mapping
|
||||
- `scripts/package_skill_runtimes.sh` now provides a declarative bundle plan/validate scaffold that targets package paths rather than hardcoded root runtime paths
|
||||
|
||||
Remaining:
|
||||
|
||||
- bootstrap `go.work` plus expanded workspace configuration
|
||||
- extract shared coordination code into `packages/coord-core`
|
||||
- extract `inbox`, `orch`, and `orchd` into package-owned runtimes
|
||||
- import `repo-memory` as its own runtime package and add the corresponding skill bundle
|
||||
- replace the hardcoded skill packaging script with declarative bundle metadata
|
||||
- graduate the bundle scaffold into the primary packaging flow once package-owned runtime entrypoints exist
|
||||
|
||||
## Immediate Next Task
|
||||
|
||||
If a new agent is taking over now, the next concrete step should be:
|
||||
|
||||
1. treat `Milestone 9: Web Product Phase 2 Read-Only Operator UI` as complete for the initial operator surface and do not expand web feature scope further until the workspace split is decided package-by-package
|
||||
2. start `Milestone 10: Skill Workspace Monorepo Migration` by bootstrapping `go.work`, expanding workspace metadata, and creating the first empty `packages/` roots
|
||||
2. treat the Phase 1 workspace bootstrap for `Milestone 10` as complete and keep the new `go.work`, `packages/`, and declarative bundle metadata as the baseline for all further migration steps
|
||||
3. extract the shared coordination kernel into `packages/coord-core` before moving `inbox`, `orch`, or `orchd` into package-owned runtimes
|
||||
4. keep the authored skill forward-test plans under `docs/tests/*-skill/` synchronized as runtime ownership moves from root paths to package paths
|
||||
5. replace the hardcoded skill packaging flow with declarative bundle metadata before adding `repo-memory`
|
||||
5. keep the legacy hardcoded packaging flow working temporarily, but evolve the new declarative bundle scaffold into the primary packaging path before adding `repo-memory`
|
||||
6. import `repo-memory` only after the package-based runtime and skill packaging pattern exists
|
||||
|
||||
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, the web product now has its first real operator-facing read surfaces, and the repository now has an explicit plan to become a skill workspace monorepo, so the next step should be repository restructuring rather than continuing to accrete new root-owned runtimes.
|
||||
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, the web product now has its first real operator-facing read surfaces, and the repository has finished the first workspace-bootstrap phase of the skill monorepo migration, so the next step should be package extraction rather than continuing to accrete new root-owned runtimes.
|
||||
|
||||
## Recommended Driver Choices
|
||||
|
||||
|
||||
@@ -0,0 +1,57 @@
|
||||
# Skill Workspace Monorepo Migration
|
||||
|
||||
## Status
|
||||
|
||||
- `in_progress`
|
||||
|
||||
## Owner
|
||||
|
||||
- Codex
|
||||
|
||||
## Started At
|
||||
|
||||
- `2026-03-20`
|
||||
|
||||
## Goal
|
||||
|
||||
- Execute `Milestone 10: Skill Workspace Monorepo Migration` by moving the repository toward a true multi-package monorepo whose primary deliverables are skills and skill runtimes.
|
||||
|
||||
## Scope
|
||||
|
||||
- bootstrap the shared workspace structure described in `docs/skill-workspace-monorepo.md`
|
||||
- complete migration phases incrementally, committing after each completed phase
|
||||
- keep packaging, roadmap, and validation flows synchronized as the migration proceeds
|
||||
|
||||
## Checklist
|
||||
|
||||
- [x] create or adopt an active execution roadmap for the migration workstream
|
||||
- [x] Phase 1: bootstrap `go.work`, expanded workspace manifests, package roots, and declarative skill bundle metadata
|
||||
- [ ] Phase 2: extract shared coordination code into `packages/coord-core`
|
||||
- [ ] Phase 3: extract `inbox-runtime` and `orch-runtime`
|
||||
- [ ] Phase 4: extract `orchd-runtime`
|
||||
- [ ] Phase 5: import `repo-memory-runtime` and add `skills/repo-memory`
|
||||
- [ ] Phase 6: remove root runtime ownership and normalize package-based packaging
|
||||
|
||||
## Files
|
||||
|
||||
- `docs/roadmaps/active/skill-workspace-monorepo-migration.md`
|
||||
- `docs/skill-workspace-monorepo.md`
|
||||
- `docs/implementation-roadmap.md`
|
||||
- `go.work`
|
||||
- `pnpm-workspace.yaml`
|
||||
- `package.json`
|
||||
- `packages/`
|
||||
- `scripts/`
|
||||
|
||||
## Decisions
|
||||
|
||||
- keep one long-lived active roadmap for the full migration rather than opening a new execution trace for every individual phase
|
||||
- complete and commit one migration phase at a time so the workspace remains bisectable
|
||||
|
||||
## Blockers
|
||||
|
||||
- none
|
||||
|
||||
## Next Step
|
||||
|
||||
- start Phase 2 by extracting the shared coordination kernel into `packages/coord-core`, using the new workspace and bundle metadata scaffold as the stable base for subsequent package moves
|
||||
Reference in New Issue
Block a user