@elevasis/sdk 1.32.0 → 1.33.1

package/reference/claude-config/sync-notes/2026-06-02-nest-projects-under-platform.md

@@ -0,0 +1,45 @@
+# Nest `projects` under `platform` (fleet-wide OM reparent)
+
+## Why this note exists
+
+The shared `@elevasis/ui` `deliveryManifest` now emits `systemId: 'platform.projects'` (it consumes the republished `@elevasis/core` constant `PROJECTS_SYSTEM_ID`, which flipped from `'projects'` to `'platform.projects'`). Any tenant Organization Model that still declares a **root-level** `projects` system will fail `validateManifests` on boot once it installs the new `@elevasis/ui`, because the delivery manifest references a `systemId` that does not exist in the tenant OM.
+
+This is a fleet-wide convention change: `projects` is now a child of `platform` (canonical id `platform.projects`) everywhere — Elevasis, the template, and every derived tenant.
+
+## Applies to
+
+- Every tenant whose `core/config/organization-model/` declares a root `projects` system (work-item / checkpoint shape) and a root `platform` system to nest it under.
+- Confirmed in this train: `ZentaraHQ`, `nirvana-marketing`. Run the verification below in any other derived project before installing the new `@elevasis/ui`.
+
+## Required actions
+
+Apply these in your own `core/config/organization-model/` (this is project-owned OM content — `/external sync` does NOT overwrite it; reparent it yourself via `/om`):
+
+1. **Reparent the system.** In `systems.ts`, move the `projects` system block under the existing `platform` system. Set `id: 'platform.projects'` and add `parentSystemId: 'platform'`. Leave the object key, route `path`, and icon as-is.
+2. **Rewrite ontology IDs.** Change every `projects:*` ontology id to `platform.projects:*` (objects, links, actions, catalogs, events, surfaces) — including all cross-references (`ownerSystemId`, `objectType`, `catalogType`, `from`/`to`).
+3. **Navigation.** In `navigation.ts`, update any `targets: { systems: ['projects'] }` to `['platform.projects']`.
+4. **Profile / roles.** In `profile.ts` (or `roles.ts`), update `deliveryFeatureId` / role `responsibleFor` references from `projects` to `platform.projects`.
+5. **Tests.** Update `core/config/organization-model.test.ts`, `organization-model.contract.test.ts`, and `ui/src/routes/__tests__/__root.test.tsx` assertions that reference the `projects` system id, parent, or ontology ids.
+6. **Install + reparent together.** Bump `@elevasis/core` and `@elevasis/ui` (see the dependency baseline written by `/external sync`), reparent the OM in the **same** change, then `pnpm -C core test` and `pnpm -C ui check-types` before booting the app. Do not install the new `@elevasis/ui` while the OM still has root `projects`.
+
+Route file paths (`ui/src/routes/projects*.tsx`) stay at `/projects`; only OM ids and nav/profile targets change.
+
+## Verification
+
+```bash
+# 1. Find any remaining root projects references
+grep -rn "'projects'\|projects:" core/config/organization-model ui/src/routes
+
+# 2. Template-family coherence
+pnpm -C core test
+pnpm -C ui check-types
+pnpm -C ui test:contracts
+
+# 3. Boot must not throw validateManifests (deliveryManifest systemId must resolve)
+```
+
+`platform.projects` must resolve as a child System of `platform`, and the delivery surface must render under it.
+
+## Not handled by /git-sync
+
+`/git-sync` and `/external sync` will deliver the new `@elevasis/core` + `@elevasis/ui` dependency baselines and this note, but they will **not** edit your `core/config/organization-model/` — tenant OM content is project-owned (`sync-preservation`). The reparent in steps 1-5 is manual per tenant. Installing the new `@elevasis/ui` without doing the reparent first will crash the app on boot.

package/reference/claude-config/sync-notes/2026-06-03-skill-autogen-and-client-skill.md

@@ -0,0 +1,34 @@
+# Skill autogen and `/client` skill
+
+## Why this note exists
+
+This train adds the template `/client` skill, a generated `.claude/Overview.md` skill and bundled-rules inventory, `skill-coverage.json`, and capability-query guidance that points agents to `elevasis-sdk cli` as the live command surface.
+
+It also ships new `@elevasis/sdk` CLI support for `skill:scaffold` and `skill:check-coverage`, and extends `elevasis-sdk check` so future CLI domains cannot land without either skill ownership or an explicit waiver.
+
+## Applies to
+
+- Every template-derived project that carries `.claude/` skills from `external/_template`.
+- Projects that use `elevasis-sdk check` as their local validation gate.
+- Operators using Claude Code skills to discover or manage clients through the existing `client:*` CLI domain.
+
+## Required actions
+
+1. Run the prepared external sync so `.claude/skills/client/`, `.claude/Overview.md`, `.claude/registries/skill-coverage.json`, and the updated setup/elevasis skill guidance are copied from the template.
+2. Install the new `@elevasis/sdk` baseline in `operations/package.json` after the SDK publish stage.
+3. Run `pnpm -C operations exec elevasis-sdk check` in each project to verify skill coverage against the live CLI catalog.
+4. Use `elevasis-sdk cli` when answering "what can I do?" or auditing available CLI domains; do not rely on stale prose inventories.
+
+## Verification
+
+```bash
+pnpm -C operations exec elevasis-sdk cli client
+pnpm -C operations exec elevasis-sdk check
+pnpm -C operations exec elevasis-sdk skill:check-coverage
+```
+
+The project should contain `.claude/skills/client/SKILL.md`, `.claude/Overview.md`, and `.claude/registries/skill-coverage.json` after sync.
+
+## Not handled by /git-sync
+
+`/git-sync` does not infer skill coverage or regenerate local command inventories. It can deliver the synced files, but maintainers still need to install the new SDK baseline and run the verification commands above. Project-owned `CLAUDE.md` content remains verify-only; the authoritative generated inventory is `.claude/Overview.md`.

package/reference/claude-config/sync-notes/2026-06-04-scaffold-registry-lane-severity.md

@@ -0,0 +1,34 @@
+# Scaffold registry lane severity annotations
+
+## Why this note exists
+
+This train adds `sync_lane_severity` annotations to the scaffold registry schema and moves external sync lane-severity ownership from hardcoded script sets into registry metadata.
+
+The change is intended to keep project sync behavior the same while making the registry the single edit point for paths that need critical manual-merge handling or optional-feature-selection treatment.
+
+## Applies to
+
+- Template-derived projects that use `/external sync` or `pnpm sync:apply` from the Elevasis monorepo.
+- Projects that receive `@elevasis/core` package-baseline updates through `core/package.json` or `operations/package.json`.
+- Operators reviewing external-sync plans that mention critical manual-merge or optional-feature-selection paths.
+
+## Required actions
+
+1. Run the prepared external sync from the release train so this note reaches derived projects.
+2. After the `@elevasis/core` publish stage, install the prepared core package baseline in template-derived project package files.
+3. Review any sync plan lane labels against the registry entry metadata before widening a manifest or applying catch-up work.
+
+No project-authored Organization Model content should be overwritten for this train.
+
+## Verification
+
+```bash
+pnpm sync:verify
+pnpm exec tsx scripts/external/sync-apply.ts --all --dry-run --manifest apps/docs/content/docs/in-progress/active-development/sdk-changes/ship/_external-sync-prep.json --strict-manifest
+```
+
+The strict manifest dry-run should authorize only the prepared sync note and the core package-baseline cascades.
+
+## Not handled by /git-sync
+
+`/git-sync` can deliver committed file changes, but it does not publish `@elevasis/core`, install package baselines, validate scaffold registry metadata, or enforce manifest-scoped external-sync write authorization.

package/reference/rules/agent-start-here.md

@@ -65,7 +65,6 @@ Once project continuity is resolved (or confirmed irrelevant), the template is n
 - `operations/` -- Elevasis SDK resources deployed to the platform
 - `core/` -- runtime-agnostic shared contracts and organization model adaptation
 - `.claude/` -- local agent rules, skills, and hooks
-- `client-workspace/` -- optional separate knowledge workspace for richer team knowledge management
 - `node_modules/@elevasis/sdk/reference/scaffold/` -- SDK reference scaffold: canonical recipes, UI patterns, gating model, contracts, and glossary. Entry point: `index.mdx`.
 
 ## Discovery Order
@@ -157,7 +156,7 @@ Load first:
 - `node_modules/@elevasis/sdk/reference/scaffold/index.mdx` (scaffold index -- contracts, gating patterns, glossary)
 - `core/config/README.md`
 - `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md`
-- typed feature/surface constants from `@elevasis/core/organization-model` -- `CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`, `PROJECTS_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, `MONITORING_FEATURE_ID`, `SETTINGS_FEATURE_ID`, `SEO_FEATURE_ID`, `CRM_PIPELINE_SURFACE_ID`, `LEAD_GEN_LISTS_SURFACE_ID`, `PROJECTS_INDEX_SURFACE_ID`, `OPERATIONS_ORGANIZATION_GRAPH_SURFACE_ID`. Use these typed constants instead of magic strings when overriding feature/surface IDs.
+- typed feature/surface constants from `@elevasis/core/organization-model` -- `SALES_FEATURE_ID`, `PROSPECTING_FEATURE_ID`, `PROJECTS_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, `MONITORING_FEATURE_ID`, `SETTINGS_FEATURE_ID`, `SEO_FEATURE_ID`, `SALES_PIPELINE_SURFACE_ID`, `PROSPECTING_LISTS_SURFACE_ID`, `PROJECTS_INDEX_SURFACE_ID`, `OPERATIONS_COMMAND_VIEW_SURFACE_ID`. Use these typed constants instead of magic strings when overriding feature/surface IDs.
 - `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-crm.md` -- CRM is an Organization OS + UI + hooks + workflow-adapter surface; read this before extending CRM structure.
 - `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md` -- lead gen is an Organization OS + UI + hooks + workflow-adapter surface; read this before extending lead-gen lists, members, artifacts, or state transitions.
 - `node_modules/@elevasis/sdk/reference/scaffold/recipes/customize-crm-actions.md` -- CRM action buttons are not `sales.actions` org-model config in v1; use the recipe's provider/custom-button path.
@@ -269,6 +268,13 @@ If a hand-authored doc conflicts with source or published package docs, trust so
 - Do not trust stable docs blindly when `.claude/rules/active-change-index.md` flags related in-progress architecture work.
 - Do not write `resume_context` into task-doc frontmatter. DB is canonical; write via `project:task:save` or the inline editor in Command Center.
 
+## Capability Surface
+
+When a user asks what skills or commands are available, do NOT answer from recollection.
+
+- **Skill inventory:** Read `.claude/Overview.md` — it is the authoritative list of skills available in this project.
+- **Live CLI capability:** Run `pnpm elevasis-sdk cli` — it outputs every command and domain currently registered in the SDK, grouped by domain.
+
 ## Operations-Only Projects
 
 Some projects derived from this template are operations-only. They have `operations/` (or a top-level `src/`) but NO `ui/`, NO `core/config/organization-model.ts`, and NO frontend. Finding none of these is not missing scaffolding -- it is by design.

package/reference/rules/organization-os.md

@@ -1,6 +1,10 @@
+---
+description: Organization OS orientation -- the semantic contract layer relating Systems, Actions, ontology, resources, policies, roles, goals, and knowledge; consumed via published @elevasis/core / @elevasis/sdk
+---
 <!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
 <!-- Regenerate: pnpm scaffold:sync -->
 
+
 # Organization OS
 
 Organization OS is the semantic contract layer defining how organizations, Systems, Actions, ontology, resources, policies, roles, goals, knowledge, and runtime surfaces relate. This project consumes Organization OS through published `@elevasis/core` / `@elevasis/sdk` configuration and does not maintain the monorepo schema.
@@ -38,11 +42,11 @@ Do not confuse `System.apiInterface` with ontology `interface` records. Ontology
 
 Some legacy UI feature constants and consumer-facing route keys are intentionally unchanged for compatibility:
 
-| Old field  | New field     | Legacy key (unchanged) | UI constant (unchanged) |
-| ---------- | ------------- | ---------------------- | ----------------------- |
-| `crm`      | `sales`       | `'crm'`                | `CRM_FEATURE_ID`        |
-| `leadGen`  | `prospecting` | `'lead-gen'`           | `LEAD_GEN_FEATURE_ID`   |
-| `delivery` | `projects`    | `'projects'`           | `PROJECTS_FEATURE_ID`   |
+| Old field  | New field     | Legacy key (unchanged) | Published constant       |
+| ---------- | ------------- | ---------------------- | ------------------------ |
+| `crm`      | `sales`       | `'crm'`                | `SALES_FEATURE_ID`       |
+| `leadGen`  | `prospecting` | `'lead-gen'`           | `PROSPECTING_FEATURE_ID` |
+| `delivery` | `projects`    | `'projects'`           | `PROJECTS_FEATURE_ID`    |
 
 ## Reference Documentation
 
@@ -79,8 +83,8 @@ All paths under `node_modules/@elevasis/sdk/reference/scaffold/`:
 ## Published Subpaths and Constants
 
 - `@elevasis/core/organization-model` -- the curated organization-model barrel. Exports `defineOrganizationModel`, `resolveOrganizationModel`, `OrganizationModelSchema`, `DEFAULT_ORGANIZATION_MODEL`, organization-model types, and typed System/Action plus legacy UI feature/surface constants.
-  - Legacy UI feature IDs: `CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`, `PROJECTS_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, `MONITORING_FEATURE_ID`, `SETTINGS_FEATURE_ID`, `SEO_FEATURE_ID`
-  - Headline surface IDs: `CRM_PIPELINE_SURFACE_ID`, `LEAD_GEN_LISTS_SURFACE_ID`, `PROJECTS_INDEX_SURFACE_ID`, `OPERATIONS_ORGANIZATION_GRAPH_SURFACE_ID`
+  - Feature IDs: `SALES_FEATURE_ID`, `PROSPECTING_FEATURE_ID`, `PROJECTS_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, `MONITORING_FEATURE_ID`, `SETTINGS_FEATURE_ID`, `SEO_FEATURE_ID`
+  - Headline surface IDs: `SALES_PIPELINE_SURFACE_ID`, `PROSPECTING_LISTS_SURFACE_ID`, `PROJECTS_INDEX_SURFACE_ID`, `OPERATIONS_COMMAND_VIEW_SURFACE_ID`
   - Reality domain types: `OrganizationModelIdentity`, `OrganizationModelCustomers`, `OrganizationModelCustomerSegment`, `OrganizationModelOfferings`, `OrganizationModelProduct`, `OrganizationModelRoles`, `OrganizationModelRole`, `OrganizationModelGoals`, `OrganizationModelObjective`, `OrganizationModelKeyResult`
   - TechStack: `TechStackEntrySchema`, `OrganizationModelTechStackEntry`
   - Use constants instead of magic strings when overriding the org model.

package/reference/rules/package-taxonomy.md

@@ -1,6 +1,10 @@
+---
+description: Package taxonomy (consumer view) -- external projects consume the published @elevasis/* surface only; workspace-internal @repo/elevasis-* packages are not installable here
+---
 <!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
 <!-- Regenerate: pnpm scaffold:sync -->
 
+
 # Package Taxonomy (Consumer View)
 
 External projects consume the **published `@elevasis/*` surface only**. The Elevasis monorepo also has workspace-internal `@repo/elevasis-*` packages — those are NOT installable here and should never appear in your imports or `package.json`.

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

@@ -46,17 +46,18 @@ Edge kinds:
 
 - `contains`
 - `references`
-- `maps_to`
-- `uses`
-- `governs`
-- `governed-by`
-- `links`
-- `affects`
-- `emits`
+- `maps_to`
+- `uses`
+- `governs`
+- `links`
+- `affects`
+- `emits`
 - `originates_from`
 - `triggers`
 - `applies_to`
-- `effects`
+- `effects`
+
+`governed-by` is a Knowledge Graph route verb for traversing incoming `governs` edges; it is not an Organization Graph edge kind.
 
 System nodes come from the id-keyed `OrganizationModel.systems` map. Their graph IDs use `system:<id>`, such as `system:sales.crm`.
 

package/reference/scaffold/operations/propagation-pipeline.md

@@ -31,15 +31,19 @@ Layer 3: Sync Verification (pnpm sync:verify)
 
 ## Layer 1: Source Generation
 
-`pnpm scaffold:sync` is the meta-script that regenerates all derived documentation and validates the output. It chains three sub-scripts:
-
-| Script                                  | Input                                                                                                                                         | Output                                                              |
-| --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
-| `generate-scaffold-contracts.js`        | `packages/core/src/organization-model/types.ts`, `packages/ui/src/features/registry/types.ts`, `packages/core/src/platform/registry/types.ts` | `packages/core/src/reference/_generated/contracts.md`               |
-| `generate-scaffold-feature-registry.js` | `packages/ui/src/features/registry/manifests.ts`, `packages/ui/src/features/*/manifest.ts`                                                    | `packages/ui/src/scaffold/_generated/feature-registry.md`           |
-| `generate-reference-artifacts.js`       | SDK manifest, navigation sources                                                                                                              | `packages/sdk/reference/_reference-manifest.json`, `_navigation.md` |
-
-After generation, `validate-reference-artifacts.js` checks that the outputs are consistent. Exit 1 if drifted.
+`pnpm scaffold:sync` is the meta-script that regenerates all derived documentation and validates the output. It chains seven sub-scripts:
+
+| Script                 | Input                                                                                                                 | Output                                                                                                     |
+| ---------------------- | --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
+| `scaffold:generate`    | Scaffold contract and feature-registry sources                                                                        | `packages/core/src/reference/_generated/**`, `packages/ui/src/scaffold/_generated/feature-registry.md`     |
+| `knowledge:generate`   | Elevasis core knowledge nodes and UI knowledge body sources                                                           | Generated knowledge nodes and UI knowledge bodies                                                          |
+| `gen:sdk-catalog`      | SDK catalog source definitions                                                                                         | SDK catalog artifacts                                                                                      |
+| `gen:sdk-adapters`     | SDK adapter definitions                                                                                                | SDK adapter artifacts                                                                                      |
+| `copy-docs`            | SDK docs, package-owned reference docs, scaffold docs, and `_template/.claude` config                                  | `packages/sdk/reference/**` copied docs and scaffold reference bundle                                       |
+| `sdk-ref:generate`     | SDK manifest and navigation sources                                                                                    | `packages/sdk/reference/_reference-manifest.json`, `packages/sdk/reference/_navigation.md`                  |
+| `sdk-ref:check`        | Generated SDK reference artifacts                                                                                      | Freshness validation for `packages/sdk/reference/_reference-manifest.json` and `_navigation.md`             |
+
+The final `sdk-ref:check` step validates that the reference artifacts are consistent. Exit 1 if drifted.
 
 ### Trigger Points
 

package/reference/scaffold/operations/scaffold-maintenance.md

@@ -99,13 +99,14 @@ Generated files should never be edited manually. If the output is wrong, fix the
 
 ## SDK Build Pipeline (Reference Copy)
 
-`packages/sdk/scripts/copy-reference-docs.mjs` runs during `pnpm --filter @elevasis/sdk build` and has three phases:
-
-1. **Phase 1:** Copies SDK public docs from `apps/docs/content/docs/sdk/` with link rewriting and MDX escape stripping
-2. **Phase 2:** Copies package-owned reference docs declared in reference manifests
-3. **Phase 3:** Copies scaffold docs from co-located package sources using the `SCAFFOLD_COPIES` map
-
-The output lands in `packages/sdk/reference/` which is included in the npm package's `files` array. External projects access it via `node_modules/@elevasis/sdk/reference/`.
+`packages/sdk/scripts/copy-reference-docs.mjs` runs during `pnpm --filter @elevasis/sdk build` and has four phases:
+
+1. **Phase 1:** Copies SDK public docs from `apps/docs/content/docs/sdk/` with link rewriting and MDX escape stripping
+2. **Phase 2:** Copies package-owned reference docs declared in reference manifests
+3. **Phase 3:** Copies scaffold docs from co-located package sources using the `SCAFFOLD_COPIES` map
+4. **Phase 4:** Copies `external/_template/.claude` into `packages/sdk/reference/claude-config` for tenant-facing agent configuration
+
+The output lands in `packages/sdk/reference/` which is included in the npm package's `files` array. External projects access it via `node_modules/@elevasis/sdk/reference/`.
 
 ---
 

package/reference/scaffold/recipes/customize-knowledge-browser.md

@@ -321,44 +321,42 @@ The sidebar (managed by the manifest) continues to operate normally. Tree clicks
 
 **Own everything:** Skip `knowledgeManifest` and build your own route tree as described in the Replace section above. Call `@elevasis/core/knowledge` directly for data and supply your own dispatcher.
 
-### Overriding Per-Kind Views (extend the dispatcher's switch)
+### Overriding Per-Kind Views
 
-If you want the default dispatcher behavior for most kinds but need a custom layout for one kind, extend the exported `DescribeNodeView` rather than replacing it entirely. Phase 1.5 exports `createDescribeNodeDispatcher` for this purpose:
+If you want the default dispatcher behavior for most kinds but need a custom layout for one kind, wrap the exported `DescribeNodeView` and intercept the specific kind before falling back to the platform dispatcher:
 
 ```tsx
-import {
-  createDescribeNodeDispatcher,
-  SystemDescribeView,
-} from '@elevasis/ui/knowledge'
+import { DescribeNodeView, SystemDescribeView } from '@elevasis/ui/knowledge'
+import type { DescribeNodeViewProps } from '@elevasis/ui/knowledge'
 
-// Supply overrides for specific kinds; all others fall through to platform defaults.
-const MyDescribeNodeView = createDescribeNodeDispatcher({
-  system: ({ node, graph, onNavigateToNode }) => (
-    // Project-specific System view with extra metadata section.
-    <MyFeatureDetailView node={node} graph={graph} onNavigateToNode={onNavigateToNode} />
-  ),
-  // 'knowledge', 'resource', 'organization', and the default fallback
-  // are handled by the platform unless you override them here.
-})
-```
+function MyDescribeNodeView(props: DescribeNodeViewProps) {
+  if (props.node.kind === 'system') {
+    return <MyFeatureDetailView node={props.node} graph={props.graph} onNavigateToNode={props.onNavigateToNode} />
+  }
 
-`createDescribeNodeDispatcher` returns a component with the same props interface as `DescribeNodeView` (`node`, `graph`, `onNavigateToNode`). You can drop it anywhere the default dispatcher is used.
+  return <DescribeNodeView {...props} />
+}
+```
 
-Override keys match `OrgGraphNodeKind` values: `'knowledge'`, `'feature'`, `'resource'`, `'organization'`, `'surface'`, `'entity'`, `'action'`. The `default` key overrides the generic fallback for unknown kinds.
+`MyDescribeNodeView` has the same props interface as `DescribeNodeView` (`node`, `graph`, `onNavigateToNode`, plus optional context props). You can drop it anywhere the default dispatcher is used.
 
-Each override function receives `{ node, graph, onNavigateToNode }` and must return a `ReactNode`. The platform kind-specific components (`KnowledgeNodeView`, `SystemDescribeView`, etc.) are all exported from `@elevasis/ui/knowledge` so you can compose them inside your override rather than replacing them from scratch:
+The platform kind-specific components (`KnowledgeNodeView`, `SystemDescribeView`, etc.) are exported from `@elevasis/ui/knowledge` so you can compose them inside your wrapper rather than replacing them from scratch:
 
 ```tsx
-const MyDescribeNodeView = createDescribeNodeDispatcher({
-  system: ({ node, graph, onNavigateToNode }) => (
+function MyDescribeNodeView(props: DescribeNodeViewProps) {
+  if (props.node.kind === 'system') {
+    return (
     <>
       {/* Platform view for the standard fields */}
-      <SystemDescribeView node={node} graph={graph} onNavigateToNode={onNavigateToNode} />
+        <SystemDescribeView {...props} />
       {/* Project-specific extension panel below */}
-      <MySystemAuditPanel systemId={node.id} />
+        <MySystemAuditPanel systemId={props.node.id} />
     </>
-  ),
-})
+    )
+  }
+
+  return <DescribeNodeView {...props} />
+}
 ```
 
 ### Phase 1.5 Exports Reference
@@ -368,7 +366,6 @@ The following exports are added in Phase 1.5 on top of the exports table above:
 | Export                         | Package                  | Purpose                                                                      |
 | ------------------------------ | ------------------------ | ---------------------------------------------------------------------------- |
 | `DescribeNodeView`             | `@elevasis/ui/knowledge` | Default graph-node dispatcher; routes by `node.kind`                         |
-| `createDescribeNodeDispatcher` | `@elevasis/ui/knowledge` | Factory for per-kind overrides; returns a `DescribeNodeView`-shape component |
 | `SystemDescribeView`           | `@elevasis/ui/knowledge` | Minimal System node view: path, icon, lifecycle, hierarchy, edges            |
 | `ResourceDescribeView`         | `@elevasis/ui/knowledge` | Minimal resource node view: resourceType, description, edges                 |
 | `OrganizationDescribeView`     | `@elevasis/ui/knowledge` | Minimal organization node view: label, edges                                 |

package/reference/scaffold/reference/feature-registry.md

@@ -15,7 +15,7 @@ description: Auto-generated catalog of registered system manifests. Do not edit
 | System Key | System ID | Nav Label | Domains | Routes |
 | --- | --- | --- | --- | --- |
 | `crm` | `sales.crm` | — | — | — |
-| `delivery` | `projects` | — | — | — |
+| `delivery` | `platform.projects` | — | — | — |
 | `knowledge` | `—` | — | — | — |
 | `lead-gen` | `sales.lead-gen` | — | — | — |
 | `monitoring` | `—` | — | — | — |

package/reference/scaffold/ui/composition-extensibility.mdx

@@ -226,7 +226,7 @@ See [recipes/customize-knowledge-browser.md](../recipes/customize-knowledge-brow
 Phase 1.5 adds two further extension surfaces documented in the same recipe file under the "Phase 1.5" section:
 
 - **Extending the SegmentedControl** -- supply a `segments` prop to `KnowledgeSidebarMiddle` to add custom mount-axis tabs beyond the default five (By Feature, By Kind, By Owner, Governs, Governed By).
-- **Replacing `DescribeNodeView`** -- override the `/knowledge/:nodeId` route component to swap the entire main-pane dispatcher, or use `createDescribeNodeDispatcher` from `@elevasis/ui/knowledge` to override only specific node-kind views while keeping the platform defaults for the rest.
+- **Replacing `DescribeNodeView`** -- override the `/knowledge/:nodeId` route component to swap the entire main-pane dispatcher, or wrap `DescribeNodeView` from `@elevasis/ui/knowledge` to intercept specific node-kind views while falling back to the platform defaults for the rest.
 
 ## What Not to Do
 

package/reference/sdk/cli-management.mdx

@@ -14,8 +14,8 @@ This page covers the domain management commands for `elevasis-sdk`. For core SDK
 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`
+- Organization model System ID: `PROJECTS_SYSTEM_ID` (`platform.projects`)
+- Default surface: `PROJECTS_INDEX_SURFACE_ID` (`platform.projects.index`)
 - Semantic domain fields: `organizationModel.delivery`
 - Core entity/capability IDs: `delivery.project`, `delivery.milestone`, `delivery.task`, `delivery.projects.view`
 

package/reference/sdk/framework/agent.mdx

@@ -78,7 +78,7 @@ The following skills ship with every Elevasis SDK project and are committed to v
 
 **`/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.
+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, `PROJECTS_SYSTEM_ID` (`platform.projects`) in the organization model, and `organizationModel.delivery` for project/milestone/task status semantics.
 
 When these command families overlap conceptually, use this boundary: