chore(monorepo): bootstrap workspace packages

docs/implementation-roadmap.md

@@ -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