refactor(monorepo): remove root cmd entrypoints

docs/web-product-monorepo.md

@@ -20,7 +20,7 @@ The recommended direction is:
 
 - keep a single monorepo
 - add a standalone frontend app under `apps/web`
-- add a standalone HTTP backend entrypoint under `cmd/orchd`
+- add a standalone HTTP backend entrypoint, now owned under `packages/orchd-runtime/cmd/orchd`
 - keep the current Go repository as the backend source of truth
 - evolve the backend by introducing shared application services and UI-oriented query layers
 - avoid building the web backend by shelling out to the existing CLIs
@@ -113,9 +113,9 @@ Recommended stack:
 The frontend should consume only HTTP APIs and event streams from the backend.
 It should never read SQLite directly and should not depend on CLI output parsing.
 
-### `cmd/orchd`
+### `packages/orchd-runtime`
 
-The backend HTTP service should start as a new Go binary under `cmd/orchd`.
+The backend HTTP service should live in a package-owned runtime with its Go binary under `packages/orchd-runtime/cmd/orchd`.
 
 Responsibilities:
 
@@ -124,9 +124,9 @@ Responsibilities:
 - load the same database as the CLI tools
 - use shared application services rather than reimplementing logic
 
-The existing `cmd/orch` and `cmd/inbox` binaries should remain available as operator and debugging tools.
+The existing orch and inbox runtimes should remain available as operator and debugging tools through their package-owned binaries under `packages/orch-runtime/cmd/orch` and `packages/inbox-runtime/cmd/inbox`.
 
-### `internal/app`
+### `packages/orchd-runtime/internal/app`
 
 This package should become the shared application-service layer.
 
@@ -142,7 +142,7 @@ It should own business actions that currently sit mostly in CLI command handlers
 
 Both CLI commands and HTTP handlers should call into this layer.
 
-### `internal/query`
+### `packages/orchd-runtime/internal/query`
 
 This package should hold read models specifically shaped for the web UI.
 
@@ -156,7 +156,7 @@ Examples:
 
 These should be query-oriented models rather than raw database table mirrors.
 
-### `internal/httpapi`
+### `packages/orchd-runtime/internal/httpapi`
 
 This package should hold the web transport layer.
 
@@ -257,9 +257,9 @@ The current project already has strong backend assets:
 The backend should therefore evolve in-place:
 
 1. keep the current store and schema as the persistence foundation
-2. extract shared application actions into `internal/app`
-3. add UI-oriented read models in `internal/query`
-4. add `cmd/orchd` and `internal/httpapi`
+2. extract shared application actions into the orchd runtime app layer
+3. add UI-oriented read models in the orchd runtime query layer
+4. add the orchd runtime package and its HTTP transport layer
 5. attach the React frontend after the API contract stabilizes
 
 This is safer than first attempting a large repo split or backend rewrite.
@@ -325,10 +325,10 @@ The goal is to avoid rewriting product boundaries just because the storage engin
 Add:
 
 - `apps/web`
-- `cmd/orchd`
-- `internal/httpapi`
-- `internal/app`
-- `internal/query`
+- `packages/orchd-runtime/cmd/orchd`
+- `packages/orchd-runtime/internal/httpapi`
+- `packages/orchd-runtime/internal/app`
+- `packages/orchd-runtime/internal/query`
 - `api/openapi.yaml`
 - `api/events.md`
 - root JS workspace files such as `package.json` and `pnpm-workspace.yaml`
@@ -409,10 +409,10 @@ The current codebase should be adapted incrementally.
 
 Recommended rules:
 
-- keep `cmd/orch` and `cmd/inbox` working while the HTTP layer is introduced
+- keep the package-owned `orch` and `inbox` binaries working while the HTTP layer is introduced
 - move business logic out of command handlers only when the shared service abstraction is clear
 - do not rewrite `store` just to match HTTP names
-- let the frontend shape drive `internal/query`, not the table layout alone
+- let the frontend shape drive the orchd runtime query layer, not the table layout alone
 - avoid introducing duplicate orchestration logic between CLI and HTTP
 
 ## Immediate Recommended Next Step
@@ -420,7 +420,7 @@ Recommended rules:
 If the project begins this web-product milestone, the first implementation slice should be:
 
 1. scaffold the monorepo workspace files and `apps/web`
-2. add `cmd/orchd` with a `chi` router and a minimal health or runs endpoint
+2. add the `orchd` runtime package with a `chi` router and a minimal health or runs endpoint
 3. introduce the first shared application or query boundary rather than letting handlers call storage ad hoc
 4. write the initial API contract in `api/openapi.yaml`