refactor(monorepo): rename operator api runtime

apps/web/src/features/operator-console.tsx

@@ -107,7 +107,7 @@ export function RunsPage() {
         <LoadingState count={4} />
       ) : runsQuery.isError ? (
         <QueryErrorState
-          description="The runs endpoint did not return data. Make sure `orchd` is running and the dev server can reach it."
+          description="The runs endpoint did not return data. Make sure the operator API is running and the dev server can reach it."
           onRetry={() => void runsQuery.refetch()}
           title="Unable to load orchestration runs"
         />
@@ -186,7 +186,7 @@ export function BlockedQueuePage() {
         <LoadingState count={3} />
       ) : blockedQuery.isError ? (
         <QueryErrorState
-          description="The queue view composes run summaries with per-run blocked endpoints. Check that `orchd` is reachable."
+          description="The queue view composes run summaries with per-run blocked endpoints. Check that the operator API is reachable."
           onRetry={() => void blockedQuery.refetch()}
           title="Unable to load the blocked queue"
         />
@@ -465,7 +465,7 @@ export function ThreadTimelinePage({ threadId }: { threadId: string }) {
   if (threadQuery.isError) {
     return (
       <QueryErrorState
-        description="The selected thread could not be loaded. Make sure the thread id is still valid and `orchd` can reach the shared SQLite database."
+        description="The selected thread could not be loaded. Make sure the thread id is still valid and the operator API can reach the shared SQLite database."
         onRetry={() => void threadQuery.refetch()}
         title={`Unable to load thread ${threadId}`}
       />

docs/implementation-roadmap.md

@@ -30,17 +30,17 @@ As of now:
 - the original five `docs/tests/orch-skill/` cases also include recorded real subagent-forward runs captured on `2026-03-19`, with spawned leader and worker agents using the packaged `skills/orch/` and `skills/inbox/` bundles
 - 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, and the package-owned `orchd` runtime path for future web work
+- a forward-looking web product monorepo plan now exists under `docs/web-product-monorepo.md`, defining the recommended React frontend, `chi` HTTP service, and the package-owned `operator-api` runtime path 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 the package-owned `orchd` backend runtime
+- 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 the package-owned `operator-api` backend runtime
-- `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
+- the operator API 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`
+- HTTP tests now cover the initial read-only operator API 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
-- 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
+- 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 operator 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
 - `packages/coord-core` now exists as the first real extracted runtime package, containing shared coordination DB/schema, protocol, and store code, and the active coordination runtimes now import `coord-core` instead of root `internal/db`, `internal/store`, and `internal/protocol`
 - `packages/inbox-runtime` and `packages/orch-runtime` now exist as package-owned runtimes with their own `cmd/` entrypoints and package-local CLI wiring/tests, and the root skill packaging flow now builds `skills/inbox`, `skills/orch`, and `skills/council-review` from package entrypoints instead of root `cmd/` paths
-- `packages/orchd-runtime` now exists as the package-owned HTTP/query/web backend runtime, with package-local `cmd/orchd`, app, query, and HTTP transport code plus passing package-local tests
+- `packages/operator-api` now exists as the package-owned HTTP/query/web backend runtime, with package-local `cmd/operator-api`, app, query, and HTTP transport code plus passing package-local tests
 - `packages/repo-memory-runtime` now exists as the package-owned `briefdb` runtime imported from the exploratory prototype, `skills/repo-memory` now exists as an agent-facing skill bundle, and the declarative root packaging flow now builds a bundled `skills/repo-memory/assets/briefdb` binary from the package runtime
 - a repo-local declarative packaging flow now builds bundled skill CLI assets for `inbox`, `orch`, `council-review`, and `repo-memory`
 - `orch` now implements `run init/show`, `task add`, `dep add`, `ready`, `dispatch`, `reconcile`, `wait`, `blocked`, `answer`, `retry`, `reassign`, `cancel`, `cleanup`, and `status`
@@ -391,7 +391,7 @@ Add:
 - `apps/web`
 - `api/openapi.yaml`
 - `api/events.md`
-- `packages/orchd-runtime`
+- `packages/operator-api`
 
 Definition of done:
 
@@ -407,10 +407,10 @@ 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
-- `packages/orchd-runtime/cmd/orchd` now opens the shared SQLite database, applies migrations, and serves a `chi` router with graceful shutdown handling
+- `packages/operator-api/cmd/operator-api` now opens the shared SQLite database, applies migrations, and serves a `chi` router with graceful shutdown handling
-- `packages/orchd-runtime/internal/query` now exposes run list/detail, run tasks, blocked-task, and thread-detail read models for the web surface
+- `packages/operator-api/internal/query` now exposes run list/detail, run tasks, blocked-task, and thread-detail read models for the web surface
-- `packages/orchd-runtime/internal/app` now provides a thin web-service boundary over the new read service
+- `packages/operator-api/internal/app` now provides a thin web-service boundary over the new read service
-- `packages/orchd-runtime/internal/httpapi` now owns HTTP routing, JSON/error helpers, and the initial read-only endpoints
+- `packages/operator-api/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
@@ -423,20 +423,20 @@ Remaining:
 
 Goal:
 
-- implement the first real operator-facing read-only web UI on top of the Phase 1 shell and current `orchd` API contract
+- implement the first real operator-facing read-only web UI on top of the Phase 1 shell and current operator API contract
 
 Add:
 
 - copied-in `cadence-ui` primitives and token CSS under `apps/web/src/cadence-ui`
 - Tailwind v4 consumer setup so the copied-in Cadence UI source renders correctly in the app
 - routed screens for runs list, run detail, blocked queue, and thread timeline
-- typed frontend read helpers for the current `orchd` endpoints
+- typed frontend read helpers for the current operator API endpoints
 
 Definition of done:
 
 - `apps/web` imports the shared Cadence token stylesheet from the frontend entrypoint
 - the Cadence UI source-owned components render correctly inside the consumer app
-- the first routed read-only operator screens ship against the existing `orchd` contract
+- the first routed read-only operator screens ship against the existing operator API contract
 - future web screens can compose from `cadence-ui` primitives instead of raw one-off HTML controls
 
 Status:
@@ -488,10 +488,10 @@ 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`
+- the migration plan now defines phased extraction for `coord-core`, `inbox-runtime`, `orch-runtime`, `operator-api`, and `repo-memory-runtime`
 - root `go.work` now includes the package-owned runtime module roots under `packages/`
 - `pnpm-workspace.yaml` now includes `packages/*`, and root `package.json` now exposes monorepo bundle planning, validation, and Go package test scripts
-- initial module roots now exist for `packages/coord-core`, `packages/inbox-runtime`, `packages/orch-runtime`, `packages/orchd-runtime`, and `packages/repo-memory-runtime`
+- initial module roots now exist for `packages/coord-core`, `packages/inbox-runtime`, `packages/orch-runtime`, `packages/operator-api`, 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
 - `packages/coord-core/db` now owns the shared SQLite open, pragmas, migrations, and coordination schema files
@@ -504,7 +504,7 @@ Completed so far:
 - `scripts/skill-bundles.json` now marks `inbox`, `orch`, and `council-review` as ready package-backed bundles
 - `scripts/package_skill_runtimes.sh package` now builds and installs `skills/inbox/assets/inbox`, `skills/orch/assets/orch`, and `skills/council-review/assets/orch` from package entrypoints
 - the legacy `scripts/package_skill_clis.sh` entrypoint now delegates to the declarative package-oriented packaging flow instead of hardcoding root `cmd/` paths
-- `packages/orchd-runtime/cmd/orchd` plus `packages/orchd-runtime/internal/{app,httpapi,query}` now provide a package-owned web backend runtime and pass `go test ./...`
+- `packages/operator-api/cmd/operator-api` plus `packages/operator-api/internal/{app,httpapi,query}` now provide a package-owned web backend runtime and pass `go test ./...`
 - `packages/repo-memory-runtime/cmd/briefdb` plus its package-local `internal/brief` and `internal/store` now provide a package-owned repo-memory runtime and pass `go test ./...`
 - `skills/repo-memory/` now exists with `SKILL.md`, `agents/openai.yaml`, and a bundled `assets/briefdb` binary produced by the declarative packaging flow
 - `docs/tests/repo-memory-skill/` now exists with a README plus an initial forward-test case covering search-before-add and durable entry retrieval through the bundled skill

docs/roadmaps/archive/rename-orchd-runtime-to-operator-api.md

@@ -0,0 +1,59 @@
+# Rename Operator API Runtime
+
+## Status
+
+- `completed`
+
+## Owner
+
+- Codex
+
+## Started At
+
+- `2026-03-20`
+
+## Goal
+
+- Rename the package-owned web backend runtime from `packages/orchd-runtime` to `packages/operator-api` and rename its command entrypoint from `cmd/orchd` to `cmd/operator-api` so the current workspace no longer carries the ambiguous `orchd` name.
+
+## Scope
+
+- rename the package directory and module path
+- update imports, workspace metadata, and current docs
+- validate the package-oriented build and test flows after the rename
+
+## Checklist
+
+- [x] inspect current `orchd-runtime` references
+- [x] rename the package directory and module path to `operator-api`
+- [x] update workspace metadata, imports, and current docs
+- [x] validate package-oriented Go tests and frontend build after the rename
+- [x] archive this roadmap and commit the completed rename
+
+## Files
+
+- `docs/roadmaps/archive/rename-orchd-runtime-to-operator-api.md`
+- `go.work`
+- `packages/operator-api/`
+- `docs/implementation-roadmap.md`
+- `docs/skill-workspace-monorepo.md`
+- `docs/web-product-monorepo.md`
+
+## Decisions
+
+- rename both the package and the command entrypoint together so current source-of-truth code no longer carries the `orchd` name
+
+## Blockers
+
+- none
+
+## Next Step
+
+- continue feature work with `packages/operator-api` as the backend runtime name and avoid reintroducing the old `orchd` label
+
+## Completion Summary
+
+- renamed the package-owned backend runtime from `packages/orchd-runtime` to `packages/operator-api`
+- renamed the package-owned daemon entrypoint from `cmd/orchd` to `cmd/operator-api`
+- updated current imports, workspace metadata, frontend copy, and current architecture docs to the new operator API name
+- validated the renamed runtime through package-oriented Go tests, skill bundle packaging, and frontend build checks

docs/skill-workspace-monorepo.md

@@ -82,7 +82,7 @@ Examples:
 │  ├─ coord-core/                    # shared coordination kernel
 │  ├─ inbox-runtime/                 # inbox CLI runtime
 │  ├─ orch-runtime/                  # orch CLI runtime
-│  ├─ orchd-runtime/                 # orch HTTP + query/web backend runtime
+│  ├─ operator-api/                  # operator HTTP + query/web backend runtime
 │  ├─ repo-memory-runtime/           # briefdb / repo-memory runtime
 │  └─ ...                            # future skill runtimes
 ├─ skills/
@@ -163,13 +163,13 @@ It depends on `coord-core`.
 `council-review` remains a skill bundle that currently reuses the `orch` binary
 unless it later grows its own standalone runtime.
 
-### `packages/orchd-runtime`
+### `packages/operator-api`
 
 This package owns the HTTP and read-model runtime for the operator web surface.
 
 It should contain:
 
-- `cmd/orchd/main.go`
+- `cmd/operator-api/main.go`
 - package-local `internal/httpapi`
 - package-local `internal/query`
 - package-local `internal/app/web.go`
@@ -237,7 +237,7 @@ Add a root `go.work` that includes every Go runtime package:
 - `packages/coord-core`
 - `packages/inbox-runtime`
 - `packages/orch-runtime`
-- `packages/orchd-runtime`
+- `packages/operator-api`
 - `packages/repo-memory-runtime`
 
 The root repository should stop relying on one giant root `go.mod` as the long-term
@@ -394,16 +394,16 @@ Exit criteria:
 - inbox and orch binaries build from package-owned runtimes
 - `skills/inbox` and `skills/orch` package from package paths only
 
-### Phase 4: Extract `orchd-runtime`
+### Phase 4: Extract `operator-api`
 
 Changes:
 
-- move `cmd/orchd`, `internal/httpapi`, `internal/query`, and web app service layer into `packages/orchd-runtime`
+- move the operator API runtime into `packages/operator-api`
 - make `apps/web` depend only on HTTP contract and dev proxy, not root assumptions
 
 Exit criteria:
 
-- the web stack builds against `orchd-runtime`
+- the web stack builds against `operator-api`
 
 ### Phase 5: Import `repo-memory-runtime`
 

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, now owned under `packages/orchd-runtime/cmd/orchd`
+- add a standalone HTTP backend entrypoint, now owned under `packages/operator-api/cmd/operator-api`
 - 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.
 
-### `packages/orchd-runtime`
+### `packages/operator-api`
 
-The backend HTTP service should live in a package-owned runtime with its Go binary under `packages/orchd-runtime/cmd/orchd`.
+The backend HTTP service should live in a package-owned runtime with its Go binary under `packages/operator-api/cmd/operator-api`.
 
 Responsibilities:
 
@@ -126,7 +126,7 @@ Responsibilities:
 
 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`.
 
-### `packages/orchd-runtime/internal/app`
+### `packages/operator-api/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.
 
-### `packages/orchd-runtime/internal/query`
+### `packages/operator-api/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.
 
-### `packages/orchd-runtime/internal/httpapi`
+### `packages/operator-api/internal/httpapi`
 
 This package should hold the web transport layer.
 
@@ -325,10 +325,10 @@ The goal is to avoid rewriting product boundaries just because the storage engin
 Add:
 
 - `apps/web`
-- `packages/orchd-runtime/cmd/orchd`
+- `packages/operator-api/cmd/operator-api`
-- `packages/orchd-runtime/internal/httpapi`
+- `packages/operator-api/internal/httpapi`
-- `packages/orchd-runtime/internal/app`
+- `packages/operator-api/internal/app`
-- `packages/orchd-runtime/internal/query`
+- `packages/operator-api/internal/query`
 - `api/openapi.yaml`
 - `api/events.md`
 - root JS workspace files such as `package.json` and `pnpm-workspace.yaml`

go.work

@@ -4,6 +4,6 @@ use (
 	./packages/coord-core
 	./packages/inbox-runtime
 	./packages/orch-runtime
-	./packages/orchd-runtime
+	./packages/operator-api
 	./packages/repo-memory-runtime
 )

packages/operator-api/cmd/operator-api/main.go

@@ -3,7 +3,7 @@ package main
 import (
 	"os"
 
-	"ai-workflow-skill/packages/orchd-runtime/server"
+	"ai-workflow-skill/packages/operator-api/server"
 )
 
 func main() {

packages/operator-api/go.mod

@@ -1,4 +1,4 @@
-module ai-workflow-skill/packages/orchd-runtime
+module ai-workflow-skill/packages/operator-api
 
 go 1.26
 

packages/operator-api/internal/app/web.go

@@ -4,7 +4,7 @@ import (
 	"context"
 	"database/sql"
 
-	"ai-workflow-skill/packages/orchd-runtime/internal/query"
+	"ai-workflow-skill/packages/operator-api/internal/query"
 	"ai-workflow-skill/packages/coord-core/store"
 )
 

packages/operator-api/internal/httpapi/router.go

@@ -8,7 +8,7 @@ import (
 	"github.com/go-chi/chi/v5"
 	"github.com/go-chi/chi/v5/middleware"
 
-	"ai-workflow-skill/packages/orchd-runtime/internal/query"
+	"ai-workflow-skill/packages/operator-api/internal/query"
 	"ai-workflow-skill/packages/coord-core/store"
 )
 

packages/operator-api/internal/httpapi/router_test.go

@@ -9,7 +9,7 @@ import (
 	"testing"
 	"time"
 
-	"ai-workflow-skill/packages/orchd-runtime/internal/app"
+	"ai-workflow-skill/packages/operator-api/internal/app"
 	dbpkg "ai-workflow-skill/packages/coord-core/db"
 	"ai-workflow-skill/packages/coord-core/store"
 )

packages/operator-api/server/execute.go

@@ -14,12 +14,12 @@ import (
 	"time"
 
 	"ai-workflow-skill/packages/coord-core/db"
-	"ai-workflow-skill/packages/orchd-runtime/internal/app"
+	"ai-workflow-skill/packages/operator-api/internal/app"
-	"ai-workflow-skill/packages/orchd-runtime/internal/httpapi"
+	"ai-workflow-skill/packages/operator-api/internal/httpapi"
 )
 
 func Execute(args []string, stderr io.Writer) int {
-	fs := flag.NewFlagSet("orchd", flag.ContinueOnError)
+	fs := flag.NewFlagSet("operator-api", flag.ContinueOnError)
 	fs.SetOutput(stderr)
 
 	var (
@@ -71,7 +71,7 @@ func Execute(args []string, stderr io.Writer) int {
 		}
 	}()
 
-	logger.Printf("orchd listening on %s", listen)
+	logger.Printf("operator-api listening on %s", listen)
 	if err := server.ListenAndServe(); err != nil && !errors.Is(err, http.ErrServerClosed) {
 		logger.Printf("serve http api: %v", err)
 		return 1