@elevasis/sdk 1.5.3 → 1.5.5

package/reference/claude-config/skills/sync/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: sync
+description: Pull latest changes, wipe all node_modules and caches, fresh reinstall
+---
+
+# Sync
+
+Pull latest changes, wipe all stale packages and caches, fresh reinstall.
+
+**Usage:** `/sync`
+
+Use this when: packages feel stale, Vite cache is serving old code, `pnpm install` didn't fully clean up after a package version bump, or after pulling a branch with dependency changes.
+
+## Process
+
+### Step 1: Check for Uncommitted Changes
+
+```bash
+git status --short
+```
+
+If there are uncommitted changes (modified, staged, or untracked files), ask the user:
+
+```
+You have uncommitted changes:
+<git status --short output>
+
+Commit and push before syncing? (yes/no)
+```
+
+- **Yes** — ask for a commit message (or auto-generate one from the diff), then:
+  ```bash
+  git add -A
+  git commit -m "<message>"
+  git push
+  ```
+  If commit or push fails, stop and report the error.
+- **No** — stop and let the user decide:
+  ```
+  Sync cancelled. Commit, stash, or discard your changes, then re-run /sync.
+  ```
+
+### Step 2: Pull
+
+```bash
+git pull
+```
+
+Report any merge conflicts and stop.
+
+### Step 3: Wipe
+
+Remove all `node_modules` and build caches across the workspace in parallel:
+
+```bash
+rm -rf node_modules
+rm -rf ui/node_modules
+rm -rf ui/node_modules/.vite
+rm -rf operations/node_modules
+rm -rf shared/node_modules
+```
+
+### Step 4: Reinstall
+
+```bash
+pnpm install
+```
+
+Report success or any errors.
+
+### Step 5: Report
+
+```
+Sync Complete
+=============
+Git:     pulled (<branch>)
+Wiped:   node_modules (root, ui, operations, shared) + Vite cache
+Install: success
+```
+
+If `pnpm install` fails, report the error and stop — do not attempt to start the dev server.

package/reference/cli.mdx

@@ -1,10 +1,10 @@
 ---
 title: CLI Reference
-description: Full reference for every elevasis-sdk CLI command -- validate, deploy, execute, inspect resources, and operate project-management surfaces
+description: Full reference for every elevasis-sdk CLI command -- validate, deploy, execute, inspect resources, and manage Projects through the canonical SDK CLI surface
 loadWhen: "Running CLI operations"
 ---
 
-The `elevasis-sdk` CLI is the primary interface for working with your Elevasis SDK project. Install it as part of `@elevasis/sdk` and use it to validate resource definitions, deploy to the platform, inspect execution history, and work with the shared project-management API surfaces.
+The `elevasis-sdk` CLI is the primary interface for working with your Elevasis SDK project. Install it as part of `@elevasis/sdk` and use it to validate resource definitions, deploy to the platform, inspect execution history, and manage Projects through `project:*`.
 
 **Installation:**
 
@@ -505,7 +505,15 @@ elevasis-sdk rename ist-upload-workflow --to ist-upload-contacts-workflow --exec
 
 ## elevasis-sdk project:\*
 
-Project-management commands operate on the shared delivery system used by packaged Projects pages and task-oriented agent workflows.
+`elevasis-sdk project:*` is the canonical project-management surface. Use it for project, milestone, task, and note operations whether the caller is a human, a scripted workflow, or a slash-command router like `/project`.
+
+This CLI family is SDK-first, but it is not semantically standalone. It operates on the same Organization OS contract that the shared delivery UI uses:
+
+- UI manifest key: `delivery`
+- Organization model feature ID: `projects`
+- Default surface: `projects.index`
+- Semantic domain fields: `organizationModel.delivery`
+- Core entity/capability IDs: `delivery.project`, `delivery.milestone`, `delivery.task`, `delivery.projects.view`
 
 ### Projects
 
@@ -573,6 +581,13 @@ Most `project:*` commands support:
 
 For exact required flags and accepted enum values, see the command source under `packages/sdk/src/cli/commands/project/`.
 
+### Command Boundary
+
+- `/project` is a convenience router to these `elevasis-sdk project:*` commands. It is not a separate project system.
+- `/work` is for docs-backed in-progress task tracking and session resume, not project CRUD.
+- `/external` is for managing standalone apps in `external/`, not project records inside a deployed system.
+- `/adev` is for implementation, debugging, testing, and platform execution flows. Use it when you need to build or run agent/workflow code rather than update project data.
+
 ---
 
 ## Global Flags
@@ -593,4 +608,4 @@ These flags are accepted by all commands:
 
 ---
 
-**Last Updated:** 2026-04-15
+**Last Updated:** 2026-04-17

package/reference/deployment/provided-features.mdx

@@ -88,7 +88,7 @@ This is the published contract split in `@elevasis/ui@2.9.0`:
 | Exported compatibility components        | Reusable components exported without a manifest-backed shell contract                                                               | Dashboard components such as `Dashboard`, `OperationsOverview`, `ResourceOverview`, `RecentExecutionsByResource`, `UnresolvedErrorsTeaser` |
 | Compatibility barrel                     | Existing imports remain available from `@elevasis/ui/components`, but new host integrations should prefer feature/provider subpaths | Manifests, sidebars, and page components re-exported for compatibility                                                                     |
 
-Projects is currently the only packaged system with a first-class `elevasis-sdk project:*` CLI family. Lead Gen and CRM are still primarily UI + API + workflow/runtime surfaces, and browser-facing interactions remain REST-driven even when runtime tools exist.
+Projects is currently the only packaged system with a first-class `elevasis-sdk project:*` CLI family. Treat that CLI family as the canonical project-management path. Lead Gen and CRM are still primarily UI + API + workflow/runtime surfaces, and browser-facing interactions remain REST-driven even when runtime tools exist.
 
 ## System Map
 
@@ -233,6 +233,15 @@ That means downstream users can build against CRM with shared UI, API, and runti
 
 Projects is the packaged delivery/project-management system. It has both a shared UI surface and a first-class CLI surface in `elevasis-sdk`, plus a dedicated runtime adapter for workflow and agent use.
 
+Within Organization OS, this packaged system sits on the **delivery** semantic domain but is exposed as the first-class feature ID **`projects`**. In practice that means:
+
+- the published UI manifest is `deliveryManifest`
+- the manifest gates against `featureId: 'projects'`
+- the default navigation surface is `projects.index`
+- the underlying semantic entities and capabilities still use delivery-scoped IDs such as `delivery.project`, `delivery.milestone`, `delivery.task`, and `delivery.projects.view`
+
+Treat `elevasis-sdk project:*` as the operational interface to that same contract, not as a separate project system layered beside Organization OS.
+
 ### Shared UI Surface
 
 `@elevasis/ui/features/delivery` exports:
@@ -260,7 +269,7 @@ Projects is the packaged delivery/project-management system. It has both a share
 
 ### CLI Surface
 
-The SDK CLI now exposes project-management commands:
+The SDK CLI exposes the canonical project-management commands:
 
 ```bash
 elevasis-sdk project:list
@@ -277,6 +286,19 @@ elevasis-sdk project:task:save <task-id> --current-state "Implemented the API sl
 
 This matters for downstream user agents because project tasks now have a resumable machine-readable surface. `project:task:resume` returns `resume_context`, and `project:task:save` updates it.
 
+For semantic context, the CLI maps onto the same Organization OS contract that drives the shared shell:
+
+- project records correspond to the `projects` feature in the organization model
+- the shared UI route space resolves through `projects.index`
+- status semantics still come from `organizationModel.delivery`, not from a separate CLI-only schema
+
+### Command Boundary
+
+- `/project` should route here. It is a convenience layer over `elevasis-sdk project:*`, not a separate system.
+- `/work` should stay focused on docs-backed task tracking and resume notes.
+- `/external` applies only to standalone apps in `external/`.
+- `/adev` applies when building, testing, debugging, or executing resources, not when managing project records.
+
 ---
 
 ## Choosing The Right Surface

package/reference/framework/agent.mdx

@@ -52,7 +52,7 @@ The following skills are scaffolded by `elevasis-sdk init` and committed to vers
 | `/setup`    | `skills/setup/SKILL.md`    | First-time project setup (placeholder replacement, deps) |
 | `/status`   | `skills/status/SKILL.md`   | Quick project health check                               |
 | `/continue` | `skills/continue/SKILL.md` | Resume in-progress work from docs                        |
-| `/project`  | `skills/project/SKILL.md`  | Client project management via elevasis-sdk               |
+| `/project`  | `skills/project/SKILL.md`  | Route project management to `elevasis-sdk project:*`     |
 | `/sync`     | `skills/sync/SKILL.md`     | Pull latest, wipe caches, fresh reinstall                |
 | `/explore`  | `skills/explore/SKILL.md`  | Codebase exploration anchored to docs                    |
 | `/save`     | `skills/save/SKILL.md`     | Auto-manage docs from conversation context               |
@@ -66,7 +66,7 @@ The following skills are scaffolded by `elevasis-sdk init` and committed to vers
 
 **`/elevasis`** -- SDK operations entry point: `check` validates resource definitions, `deploy` bundles and uploads, `exec` runs a resource with input.
 
-**`/work`** -- File-based task lifecycle. Creates, resumes, saves, and completes task docs in `docs/in-progress/`. Intent-driven: the agent detects what to do from context.
+**`/work`** -- File-based task lifecycle. Creates, resumes, saves, and completes task docs in `docs/in-progress/`. It tracks in-progress work state, not project records.
 
 **`/status`** -- Quick project health check: shows SDK version, deployed resources, last deploy date, and environment status.
 
@@ -76,7 +76,15 @@ The following skills are scaffolded by `elevasis-sdk init` and committed to vers
 
 **`/continue`** -- Resumes in-progress work by reading `docs/in-progress/` and picking up where the last session left off.
 
-**`/project`** -- Client project management: milestones, tasks, and notes via `elevasis-sdk project` commands.
+**`/project`** -- Project-management routing for milestones, tasks, notes, and status. It should call the canonical `elevasis-sdk project:*` CLI surface rather than inventing a parallel workflow.
+
+That routing is interface-first, not a separate semantic model. `/project` should treat the SDK CLI as the operational entrypoint for the Organization OS delivery/projects contract: `deliveryManifest` in the shared UI, `featureId: 'projects'` in the organization model, and `organizationModel.delivery` for project/milestone/task status semantics.
+
+When these command families overlap conceptually, use this boundary:
+
+- `/project` -- update or inspect project data in the shared Projects system
+- `/work` -- capture implementation progress and resume context in docs
+- `/adev` -- build, debug, test, or execute resources
 
 **`/dsp`** -- Dispatches subagents in parallel for implementation tasks that can run concurrently.
 
@@ -145,4 +153,4 @@ The `CLAUDE.md` Interaction Guidance section translates skill dimensions from `m
 
 ---
 
-**Last Updated:** 2026-03-03
+**Last Updated:** 2026-04-17

package/reference/framework/project-structure.mdx

@@ -94,7 +94,7 @@ This file is NOT scaffolded by default. The agent creates it the first time you
 
 ### `docs/in-progress/`
 
-Work-in-progress task documents managed by `/work`. Each file represents an active work item with objective, plan, progress markers, and resume context. When all steps are complete, the agent suggests finalizing the task, which moves finished items to their permanent location in `docs/`.
+Work-in-progress task documents managed by `/work`. Each file represents an active work item with objective, plan, progress markers, and resume context. This is separate from the Projects data model exposed through `elevasis-sdk project:*`. When all steps are complete, the agent suggests finalizing the task, which moves finished items to their permanent location in `docs/`.
 
 This directory is NOT deployed -- it is filtered out during the doc scan in `elevasis-sdk deploy`.
 
@@ -229,10 +229,16 @@ The `.claude/skills/` directory contains skills covering the core development lo
 - **`/save`** -- Auto-manage docs from conversation context
 - **`/explore`** -- Codebase exploration anchored to docs
 - **`/continue`** -- Resume in-progress work from docs
-- **`/project`** -- Client project management via elevasis-sdk
+- **`/project`** -- Routes project management to the canonical `elevasis-sdk project:*` commands
 - **`/dsp`** -- Parallel agent dispatch for implementation tasks
 - **`/sync`** -- Pull latest, wipe caches, fresh reinstall
 
+Boundary summary:
+
+- `/project` updates shared project records
+- `/work` manages docs-backed work tracking
+- `/adev` handles implementation and execution work
+
 For detailed command documentation, see [Agent System](agent).
 
 ---
@@ -275,4 +281,4 @@ Not all scaffolded files participate in template updates. Files fall into two ca
 
 ---
 
-**Last Updated:** 2026-03-03
+**Last Updated:** 2026-04-17

package/reference/packages/core/src/README.md

@@ -23,7 +23,7 @@ Within the monorepo, the internal `@repo/core` package exposes additional subpat
 - `@repo/core/server` - Node.js-only helpers and services.
 - `@repo/core/platform` - shared constants, utilities, registry, SSE, and API types.
 - `@repo/core/auth` - multi-tenancy types for organizations, users, memberships, invitations, and credentials.
-- `@repo/core/execution` - workflow, agent, scheduler, calibration, and execution-interface contracts.
+- `@repo/core/execution` - workflow, agent, scheduler, and execution-interface contracts.
 - `@repo/core/commands` - command queue types and schemas.
 - `@repo/core/operations` - sessions, notifications, observability, activities, triggers, and debug logs.
 - `@repo/core/supabase` - generated database types and helpers.

package/reference/packages/core/src/business/README.md

@@ -0,0 +1,52 @@
+# Entities
+
+Published base entity contracts for the Elevasis platform. Each entity ships as a TypeScript interface, a matching Zod schema, and an inferred `Input` type, generic over a `<TMeta>` extension slot.
+
+External projects extend these in `foundations/types/entities.ts` to attach project-specific metadata while keeping the canonical shape stable.
+
+## Published Exports
+
+The published entry point exposes six entity contracts:
+
+- `BaseProject<TMeta>`, `BaseProjectSchema`, `BaseProjectInput`
+- `BaseMilestone<TMeta>`, `BaseMilestoneSchema`, `BaseMilestoneInput`
+- `BaseTask<TMeta>`, `BaseTaskSchema`, `BaseTaskInput`
+- `BaseDeal<TMeta>`, `BaseDealSchema`, `BaseDealInput`
+- `BaseCompany<TMeta>`, `BaseCompanySchema`, `BaseCompanyInput`
+- `BaseContact<TMeta>`, `BaseContactSchema`, `BaseContactInput`
+
+Import them from the published subpath:
+
+```ts
+import { BaseDealSchema, type BaseDeal } from '@elevasis/core/entities'
+```
+
+## Extension Pattern
+
+Each base interface accepts a generic metadata type. Extend the schema with `.extend({ metadata: ... })` and infer the type with `BaseProject<z.infer<typeof MetaSchema>>`.
+
+```ts
+import { z } from 'zod'
+import { BaseProjectSchema, type BaseProject } from '@elevasis/core/entities'
+
+const ProjectMetaSchema = z.object({
+  budget: z.number().int().nonnegative(),
+  clientPriority: z.enum(['low', 'medium', 'high'])
+})
+
+export const ProjectSchema = BaseProjectSchema.extend({ metadata: ProjectMetaSchema })
+export type Project = BaseProject<z.infer<typeof ProjectMetaSchema>>
+```
+
+Use the base shape as-is when no extension is needed:
+
+```ts
+export const DealSchema = BaseDealSchema
+export type Deal = BaseDeal
+```
+
+## Recipe
+
+The full pattern is documented in the SDK scaffold bundle: `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-a-base-entity.md`.
+
+The canonical template demo lives at `external/_template/foundations/types/entities.ts`.

package/reference/packages/core/src/organization-model/README.md

@@ -12,6 +12,9 @@ The public entry point exposes:
 - `DEFAULT_ORGANIZATION_MODEL`
 - `defineOrganizationModel`
 - `resolveOrganizationModel`
+- `PROJECTS_FEATURE_ID`
+- `PROJECTS_INDEX_SURFACE_ID`
+- `DELIVERY_PROJECTS_VIEW_CAPABILITY_ID`
 - `OrganizationModel` and the supporting domain types
 
 Import it from the published subpath:
@@ -19,7 +22,10 @@ Import it from the published subpath:
 ```ts
 import {
   DEFAULT_ORGANIZATION_MODEL,
+  DELIVERY_PROJECTS_VIEW_CAPABILITY_ID,
   defineOrganizationModel,
+  PROJECTS_FEATURE_ID,
+  PROJECTS_INDEX_SURFACE_ID,
   resolveOrganizationModel,
   type OrganizationModel
 } from '@elevasis/core/organization-model'
@@ -31,43 +37,36 @@ The model is versioned and currently validates against `version: 1`.
 
 Top-level fields:
 
-- `domains` - semantic domain entries that bind entity IDs, surface IDs, resource IDs, and capability IDs.
+- `version` - schema version for the resolved contract.
 - `branding` - organization branding defaults and overrides.
-- `features` - grouped shell-level feature flags and labels.
+- `features` - unified feature entries that combine enablement, labels, and semantic references.
 - `navigation` - navigation model for the product shell.
 - `crm` - CRM-specific contract data.
 - `leadGen` - lead generation contract data.
 - `delivery` - delivery and project contract data.
 - `resourceMappings` - cross-surface resource mappings.
 
-## Default Domain Set
+## Default Feature Set
 
-The default model includes four semantic domains:
+The default model includes seven feature IDs:
 
 - `crm` - deal pipeline and relationship management.
 - `lead-gen` - lists, companies, and contacts.
-- `delivery` - projects, milestones, and tasks.
+- `projects` - projects, milestones, and tasks.
 - `operations` - organization graph and command-view surfaces.
+- `monitoring` - monitoring surfaces.
+- `settings` - organization settings.
+- `seo` - SEO surfaces (disabled by default).
 
-## Feature Keys
+## Project Bridge Constants
 
-The current canonical feature keys are grouped shell features:
+The organization-model surface now exports a narrow set of canonical IDs for the shared Projects bridge:
 
-- `acquisition`
-- `delivery`
-- `operations`
-- `monitoring`
-- `settings`
-- `calibration`
-- `seo`
+- `PROJECTS_FEATURE_ID` -> `projects`
+- `PROJECTS_INDEX_SURFACE_ID` -> `projects.index`
+- `DELIVERY_PROJECTS_VIEW_CAPABILITY_ID` -> `delivery.projects.view`
 
-Each feature can carry an enabled flag and an optional label override.
-
-This is intentionally different from the domain and surface vocabulary:
-
-- domains and surface IDs still use IDs such as `crm`, `lead-gen`, and `projects.index`
-- navigation surfaces point those routes at grouped `featureKey` values such as `acquisition` and `delivery`
-- downstream apps may still carry compatibility aliases for legacy route-level keys, but the published organization-model contract does not
+Use these when wiring shared UI manifests, template adapters, or other consumers that need to agree on the same Projects contract without repeating raw literals.
 
 ## Resolution Semantics
 
@@ -82,13 +81,13 @@ This is intentionally different from the domain and surface vocabulary:
 
 - `navigation.defaultSurfaceId` must point at a declared navigation surface.
 - Every navigation group `surfaceId` must resolve to a declared surface.
-- Domain, surface, and resource-mapping IDs must resolve to declared counterparts; dangling references fail validation.
-- Domain-to-surface and domain/surface-to-resource links are validated in both directions so one-sided declarations fail during resolution.
-- Feature-bearing surfaces validate `featureKey` against the canonical grouped feature set.
+- Feature, surface, and resource-mapping IDs must resolve to declared counterparts; dangling references fail validation.
+- Feature-to-surface and feature/surface-to-resource links are validated in both directions so one-sided declarations fail during resolution.
+- Feature-bearing surfaces validate `featureId` against the canonical feature set.
 
 ## Practical Guidance
 
 - Use `resolveOrganizationModel()` when you need a runtime-safe model for rendering or policy checks.
 - Use `defineOrganizationModel()` when authoring a static partial model in source.
-- Treat `features.enabled` and `features.labels` as the shell-level contract; do not use `crm`, `lead-gen`, or `projects` as canonical feature keys in new organization-model authoring.
-- Keep domain IDs, surface IDs, and capability IDs stable because downstream UI and policy code depend on them.
+- Treat feature IDs such as `crm`, `lead-gen`, and `projects` as the canonical shell-level contract in new organization-model authoring.
+- Keep feature IDs, surface IDs, and capability IDs stable because downstream UI and policy code depend on them.

package/reference/packages/ui/src/app/README.md

@@ -0,0 +1,24 @@
+# App
+
+Published app factory for downstream applications.
+
+## Exports
+
+- `createElevasisApp(config)` -- factory that composes providers, router, auth, and theme into a mountable React app
+- `ElevasisAppConfig` -- configuration interface (router, query client, theme, store hooks, error handling)
+- `ElevasisAppStoreConfig` -- store integration hooks for theme state
+
+## Usage
+
+```ts
+import { createElevasisApp } from '@elevasis/ui/app'
+
+const { App } = createElevasisApp({
+  router,
+  queryClient,
+  store: { useThemePreset, useThemeColorScheme, useSetTheme },
+  themeConfig: { presets, defaultPreset },
+})
+```
+
+Consumers must import CSS separately in their entry point.

package/reference/platform-tools/type-safety.mdx

@@ -79,14 +79,4 @@ Some adapters were audited and deliberately left with flexible types. Do not tig
 
 ---
 
-## Known Exceptions
-
-### `website-extract-calibration.ts`
-
-`external/elevasis/src/client-acquisition/lead-gen-pipeline/02-extract/website-extract-calibration.ts` intentionally omits `provider` and `model` on its `llm.generate()` call. This is a calibration variant that injects model config via `definitionOverrides.modelConfig` at deploy time.
-
-This file requires `@ts-expect-error` above the `llm.generate()` call after each SDK publish, since the type change would otherwise cause a compile error on a legitimate use case.
-
----
-
 **Source:** `packages/sdk/src/worker/adapters/llm.ts`, `packages/core/src/execution/engine/tools/tool-maps.ts`

package/reference/scaffold/core/organization-graph.mdx

@@ -5,7 +5,7 @@ description: Organization OS Graph layer documentation for the Cytoscape-based o
 
 ## Overview
 
-Within Organization OS, the organization graph is the dedicated **Graph** layer. It treats the organization model as the top-level ontology and bridges in Command View runtime topology so one graph can support semantic exploration and operations-oriented tracing. It is not a replacement renderer for Command View; it is a shared graph product that subsumes Command View as one operational lens.
+Within Organization OS, the organization graph is the dedicated **Graph** layer. It treats the organization model as the top-level ontology and bridges in Command View runtime topology so one graph can support semantic exploration and operations-oriented tracing. Command View is now one lens over this shared graph, not a separate live graph renderer.
 
 Graph contracts live in `@repo/core` alongside the organization model. Rendering lives in `@repo/ui` with Cytoscape.js. The command-center route is a thin wrapper over the shared page.
 
@@ -32,7 +32,7 @@ Graph types are intentionally **not** part of the published `@elevasis/core` sur
 The graph helps users:
 
 - orient themselves in the organization model
-- discover how domains, capabilities, surfaces, entities, resources, and workflows connect
+- discover how features, capabilities, surfaces, entities, resources, and workflows connect
 - trace upstream/downstream dependencies
 - understand ownership and implementation boundaries
 - assess blast radius before changing a workflow, agent, feature, or integration
@@ -46,21 +46,22 @@ The graph does not replace workflow editors, execution-run visualizers, or build
 
 The implementation uses one typed graph, not separate semantic and implementation taxonomies.
 
-- Node kinds: `organization`, `feature`, `domain`, `surface`, `entity`, `capability`, `resource`
+- Node kinds: `organization`, `feature`, `surface`, `entity`, `capability`, `resource`
 - Edge kinds: `contains`, `references`, `exposes`, `maps_to`
 - `resource` nodes carry `resourceType` metadata: `workflow`, `agent`, `trigger`, `integration`, `external`, or `human_checkpoint`
 - `references` edges may also carry `relationshipType`: `triggers`, `uses`, or `approval`
 
-This means runtime topology is represented as bridged `resource` nodes plus relationship metadata on shared edge types, rather than as a second disconnected edge/node vocabulary.
+This means runtime topology is represented as bridged `resource` nodes plus relationship metadata on shared edge types, rather than as a second disconnected edge/node vocabulary. `maps_to` is the main crossover edge: the builder emits it from organization-model resource mappings, and the UI presence helpers also treat it as topology-facing when classifying which non-resource nodes participate in runtime-adjacent views.
 
 ### Compatibility rules with the organization model
 
 - `OrganizationModelSchema` is the source of truth for semantic structure. The graph does not introduce a second ontology.
 - Graph node IDs and references reuse organization-model IDs wherever those IDs already exist.
-- `domain` nodes derive from `organizationModel.domains`.
 - `surface` nodes derive from `organizationModel.navigation.surfaces`; graph routing respects surface `path` and `defaultSurfaceId`.
 - Feature gating and labels respect `organizationModel.features.enabled` and `.labels`.
 - Implementation-resource bridging prefers `organizationModel.resourceMappings`.
+- Semantic grouping now comes from the unified `organizationModel.features` array. The builder no longer emits separate `domain` nodes.
+- Command View resource `domains` metadata is currently bridged onto `feature` references, not onto a distinct domain-node layer.
 - Graph defaults remain valid when produced by `resolveOrganizationModel()`.
 - If the graph needs a concept the model cannot express, extend the model first.
 
@@ -70,7 +71,6 @@ This means runtime topology is represented as bridged `resource` nodes plus rela
 type OrganizationGraphNodeKind =
   | 'organization'
   | 'feature'
-  | 'domain'
   | 'surface'
   | 'entity'
   | 'capability'
@@ -86,7 +86,7 @@ interface OrganizationGraph {
 }
 ```
 
-`OrganizationGraphNode` also includes optional `sourceId`, `description`, `enabled`, `featureKey`, `surfaceType`, and `resourceType`. `OrganizationGraphEdge` includes optional `label` and `relationshipType`.
+`OrganizationGraphNode` also includes optional `sourceId`, `description`, `enabled`, `featureId`, `surfaceType`, and `resourceType`. `OrganizationGraphEdge` includes optional `label` and `relationshipType`.
 
 ### Build pipeline
 
@@ -100,9 +100,9 @@ interface BuildOrganizationGraphInput {
 `buildOrganizationGraph` accepts optional topology input so the semantic graph still renders when operational bridging is sparse. The derivation flow is additive and upsert-oriented:
 
 1. Resolve the active organization model.
-2. Derive semantic nodes and edges from domains, features, surfaces, entities, capabilities, and resource mappings.
+2. Derive semantic nodes and edges from features, surfaces, entities, capabilities, and resource mappings.
 3. Upsert bridged runtime resources from Command View data into shared `resource` nodes.
-4. Merge topology relationships onto the same DTO using `references` or `maps_to` edges plus optional `relationshipType`.
+4. Bridge Command View runtime topology onto the same DTO as `references` edges between `resource` nodes, using `relationshipType` for runtime relationship labels.
 5. Hand the resulting graph to UI-level lensing, filtering, and Cytoscape projection.
 
 Keeping assembly outside the renderer keeps graph semantics testable without UI and prevents Cytoscape concepts from leaking into business logic.
@@ -110,7 +110,7 @@ Keeping assembly outside the renderer keeps graph semantics testable without UI
 ### Ownership split
 
 - `@repo/core` owns normalized node/edge types, schemas, and build/derivation helpers.
-- `@repo/ui` owns Cytoscape element conversion, layout presets, selection/hover/expansion/viewport state, detail panels, and presentation helpers.
+- `@repo/ui` owns Cytoscape element conversion, layout presets, selection state, path tracing, viewport mechanics, detail panels, and presentation helpers.
 - `apps/command-center` owns route wiring and page-level integration.
 
 ## Interaction Model
@@ -124,6 +124,8 @@ The graph ships with two lens presets in UI code:
 
 Lenses do not change the core DTO. They configure how the shared graph is initially presented.
 
+The command-view preset is intentionally narrow. It starts from topology-focused `resource` nodes so runtime traces stay readable, even though the underlying graph still contains semantic nodes and bridge edges.
+
 ### Modes
 
 - **Map mode** -- clustered for broad graph orientation
@@ -138,18 +140,13 @@ Layouts are deterministic presets, not unconstrained force simulation:
 
 ### Interactions
 
-Primary set, kept small and high-value:
+Primary set in the current shared page:
 
 - click node for detail panel
 - click edge for relationship meaning
-- hover for adjacency preview
-- search and jump to node
-- expand immediate neighbors
-- isolate selected node + N-hop neighborhood
 - switch mode
-- pin selected nodes
-- highlight shortest or most relevant path between two nodes
-- filter by node kind, domain, capability, feature, status, environment
+- highlight shortest directed paths between two visible nodes in trace mode
+- filter by node kind, topology presence, and free-text search
 
 Deferred: freeform node placement, collaborative annotations, graph editing/authoring, arbitrary canvas drawing.
 
@@ -163,13 +160,15 @@ Filter inputs:
 - `nodeKinds`
 - `topologyPresence: 'all' | 'semantic-only' | 'topology-only'`
 
-Presence is derived per node:
+Presence is derived per node in UI helpers:
 
 - `resource` nodes are `topology-only`
-- nodes with only semantic edges are `semantic-only`
-- nodes with both semantic and topology edges are treated as bridge nodes internally
+- non-resource nodes with only semantic edges are `semantic-only`
+- non-resource nodes with `maps_to` edges or runtime relationship edges alongside semantic edges are treated as `bridge` nodes internally
+
+`bridge` is an internal classification used by the filtering helpers. The public filter control only exposes `all`, `semantic-only`, and `topology-only`, so bridge nodes appear when presence is `all`.
 
-Search matches node IDs, labels, descriptions, source IDs, feature keys, surface/resource types, edge labels, edge kinds, and `relationshipType`.
+Search matches node IDs, labels, descriptions, source IDs, feature IDs, surface/resource types, edge labels, edge kinds, and `relationshipType`.
 
 The page applies `useDeferredValue()` to the active filters so graph search stays responsive while typing.
 
@@ -188,19 +187,28 @@ The graph is exposed through `ElevasisFeaturesProvider` rather than as app-local
 - The provider resolves that against `organizationModel.navigation.surfaces` and exposes the result as `organizationGraph` in context.
 - Shared UI/operations code stays manifest-driven while remaining aware of semantic organization topology.
 
+This provider bridge resolves the canonical shared graph surface, not a Command View-specific surface. Command View still has its own navigation surface (`operations.command-view`), but the live page delegates into the shared graph renderer.
+
 ## Command View Integration
 
-`CommandViewPage` now delegates to `OrganizationGraphPage` through a command-view lens preset. The lens restores high-value operational context through:
+`CommandViewPage` now delegates to `OrganizationGraphPage` through a command-view lens preset. The shared page adds command-view operational context through:
 
-- route-level execution-health cards
+- command-view summary cards rendered in `OrganizationGraphPage`
 - selection-aware resource and human-checkpoint summaries inside the shared graph detail panel
 - follow-up actions for recent executions and pending tasks inside the detail panel
-- dedicated command-view sidebar content (`Command View` labeling and node filters live in the subshell sidebar, not on the graph canvas)
+- dedicated command-view sidebar content alongside the shared graph controls
 
 Operational summary and drill-down derivation is covered by tests under `packages/ui/src/features/operations/organization-graph/__tests__/`.
 
 The detail experience is shared through `OrganizationGraphDetailPanel`, which can render both semantic context and command-view-specific follow-up sections.
 
+Keep the current seam explicit:
+
+- The graph canvas, selection model, path tracing, shared filters, and detail panel all live in `OrganizationGraphPage`.
+- `OperationsSidebarMiddle` still renders `CommandViewSidebarContent` for `/operations/command-view`.
+- That sidebar remains a companion operational panel with some legacy store/filter assumptions and is not the source of truth for the shared graph's filter state.
+- Older React Flow Command View code still exists in the repo, but it is no longer the live renderer for the current Command View route.
+
 ## Cytoscape Responsibility Split
 
 Cytoscape owns:
@@ -217,16 +225,17 @@ React owns:
 
 - mode switching
 - side panels and inspectors
-- search and command-palette entry
+- filter toolbar search and trace controls
 - route state and deep-linking
 - server data fetching
-- persistence of saved filters and views
 
 ## Package Boundary
 
 - `packages/ui/package.json` declares Cytoscape on the published UI surface.
 - `packages/ui/tsup.config.ts` and `packages/ui/rollup.dts.config.mjs` keep Cytoscape **externalized** for publish output.
-- Graph DTO types are internal to `@repo/core`. The published `@elevasis/core` wrapper still exposes only the narrow organization-model API. External graph adoption should not be assumed.
+- Graph DTO types, schemas, and builders live in monorepo `@repo/core` organization-model modules.
+- Cytoscape rendering, lens presets, filtering helpers, and detail/runtime presentation live in `@repo/ui`.
+- The published `@elevasis/core` wrapper still exposes only the narrow organization-model API; this graph contract should be treated as monorepo-internal for now.
 
 ## Theming