@elevasis/sdk 1.32.0 → 1.33.0

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/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/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: