@elevasis/sdk 1.20.1 → 1.21.0

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

@@ -4,34 +4,23 @@
 <!-- @generated by scripts/monorepo/generate-scaffold-feature-registry.js — DO NOT EDIT -->
 <!-- Regenerate: pnpm scaffold:sync -->
 ---
-title: Feature Registry
-description: Auto-generated catalog of registered feature manifests. Do not edit manually.
+title: System Manifest Registry
+description: Auto-generated catalog of registered system manifests. Do not edit manually.
 ---
 
 > **Auto-generated** from source manifests. Do not edit manually. Run `node scripts/monorepo/generate-scaffold-feature-registry.js` to regenerate.
 
-## Registered Feature Manifests
+## Registered System Manifests
 
-| Feature Key | Feature ID | Nav Label | Domains | Routes |
+| System Key | System ID | Nav Label | Domains | Routes |
 | --- | --- | --- | --- | --- |
 | `crm` | `sales.crm` | — | — | — |
 | `delivery` | `projects` | — | — | — |
-| `knowledge` | `knowledge` | — | — | — |
+| `knowledge` | `—` | — | — | — |
 | `lead-gen` | `sales.lead-gen` | — | — | — |
-| `monitoring` | `monitoring` | — | — | — |
-| `operations` | `operations` | — | — | — |
+| `monitoring` | `—` | — | — | — |
+| `operations` | `—` | — | — | — |
 | `seo` | `seo` | — | — | — |
-| `settings` | `settings` | — | — | — |
+| `settings` | `—` | — | — | — |
 
-> **Note:** `auth` and `dashboard` are not in the registry — they are app-shell concerns, not gated features.
-
-## Default Feature IDs
-
-Feature IDs defined in `DEFAULT_ORGANIZATION_MODEL.features` (`packages/core/src/organization-model/defaults.ts`):
-
-```typescript
-// FeatureSchema: { id, label, enabled, color?, icon?, entityIds, surfaceIds, resourceIds, capabilityIds }
-type DefaultFeatureId = 'dashboard' | 'identity' | 'platform' | 'finance' | 'business' | 'sales' | 'sales.crm' | 'sales.lead-gen' | 'projects' | 'clients' | 'operations' | 'knowledge.command-view' | 'operations.overview' | 'operations.resources' | 'operations.command-queue' | 'operations.sessions' | 'operations.task-scheduler' | 'monitoring' | 'monitoring.calendar' | 'monitoring.activity-log' | 'monitoring.execution-logs' | 'monitoring.execution-health' | 'monitoring.cost-analytics' | 'monitoring.notifications' | 'monitoring.submitted-requests' | 'settings' | 'settings.account' | 'settings.appearance' | 'settings.roles' | 'settings.organization' | 'settings.credentials' | 'settings.api-keys' | 'settings.webhooks' | 'settings.deployments' | 'admin' | 'admin.system-health' | 'admin.organizations' | 'admin.users' | 'admin.design-showcase' | 'admin.debug' | 'archive' | 'archive.agent-chat' | 'archive.execution-runner' | 'seo' | 'knowledge' | 'knowledge.base'
-```
-
-These are the built-in feature IDs. The `featureId` field on a `FeatureModule` manifest must match the `id` of a feature in the organization model to enable access-flag gating.
+> **Note:** `auth` and `dashboard` are not in the registry — they are app-shell concerns, not gated systems.

package/reference/scaffold/reference/glossary.md

@@ -16,31 +16,31 @@ description: Terminology disambiguation for Organization OS concepts used in the
 
 **DeploymentSpec** -- runtime/deploy assembly for one organization: workflows, agents, triggers, integrations, relationships, external resources, and human checkpoints. It assembles executable behavior around Organization Model resource descriptors; it is not the source of resource identity.
 
-**Feature** -- either a platform capability, a shell `FeatureModule`, or an Organization Model feature node. In the current shell contract, Organization Model feature nodes drive sidebar hierarchy and access state.
+**Feature** -- legacy or UI-package wording for a platform capability area. In the current Organization Model, use **System** for semantic ownership and **navigation surface** for shell placement. Keep "feature" only when referring to existing UI package folders, exported manifest names, or legacy compatibility recipes.
 
-**FeatureGuard** -- route-level feature gate from `@elevasis/ui/features/auth`.
+**SystemGuard** -- route-level System gate from `@elevasis/ui/features/auth`.
 
-**FeatureModule** -- manifest contract a shell feature provides to `ElevasisFeaturesProvider`. Key fields are `key`, `featureId`, optional `capabilityIds`, optional `icon`, optional `sidebar`, and optional graph bridge metadata.
+**SystemModule** -- manifest contract a shell module provides to `ElevasisSystemsProvider`. Key fields are `key`, optional `systemId`, optional `routePrefixes`, optional `capabilityIds`, optional `icon`, optional `sidebar`, optional `sidebarWidth`, and optional graph bridge metadata.
 
-**featureId** -- the `FeatureModule` field that must match an `OrganizationModel.features[].id`.
+**systemId** -- the `SystemModule` field that points to an `OrganizationModel.systems` entry. Navigation-only app modules may omit it and use route prefixes/surface metadata instead.
 
 **Foundations** -- local adapter layer in external projects that exports `canonicalOrganizationModel`, `organizationModel`, and workflow I/O schemas.
 
-**Graph node ID** -- kind-prefixed cross-collection identifier such as `feature:sales.crm`, `integration:instantly`, or `resource:lead-import`.
+**Graph node ID** -- kind-prefixed cross-collection identifier such as `system:sales.crm`, `integration:instantly`, or `resource:lead-import`.
 
 **Manifest** -- a runtime declaration for a feature or resource collection.
 
-**MembershipFeatureConfig** -- per-member feature override config: `{ features?: Record<string, boolean> }`.
+**MembershipFeatureConfig** -- legacy per-member feature override config. Current System visibility is resolved through Organization Model lifecycle/access metadata and provider compatibility layers.
 
-**OrganizationModel** -- top-level semantic contract for an organization. Current primary fields include `features`, `branding`, `navigation`, `sales`, `prospecting`, `projects`, `identity`, `customers`, `offerings`, `roles`, `goals`, `systems`, `resources`, `statuses`, `operations`, and `knowledge`.
+**OrganizationModel** -- top-level semantic contract for an organization. Current primary fields include `version`, `domainMetadata`, `branding`, `navigation`, `sales`, `prospecting`, `projects`, `identity`, `customers`, `offerings`, `roles`, `goals`, `systems`, `resources`, `actions`, `entities`, `policies`, `statuses`, and `knowledge`.
 
-**OrganizationModelFeature** -- feature node in `OrganizationModel.features`. Fields include `id`, `label`, `description`, `enabled`, `path`, `icon`, `color`, `uiPosition`, `requiresAdmin`, and `devOnly`.
+**OrganizationModelSystemEntry** -- System node in `OrganizationModel.systems`. Fields include `id`, `label`, `description`, `parentSystemId`, `subsystems`, `lifecycle`, `ui`, `requiresAdmin`, `devOnly`, `responsibleRoleId`, `governedByKnowledge`, `drivesGoals`, `actions`, `content`, and `order`.
 
-**Provider / ElevasisFeaturesProvider** -- runtime that registers manifests, resolves feature access against the org model, and exposes shell helpers through `useElevasisFeatures()`.
+**Provider / ElevasisSystemsProvider** -- runtime that registers System modules, resolves System access against the org model, projects sidebar navigation, and exposes shell helpers through `useElevasisSystems()`.
 
-**Resource** -- governance-only descriptor in `OrganizationModel.resources.entries` for a workflow, agent, or integration. Runtime code derives `resourceId` and kind from the descriptor, then attaches executable behavior in operations.
+**Resource** -- governance-only descriptor in `OrganizationModel.resources` for a workflow, agent, integration, or script. Runtime code derives `resourceId` and kind from the descriptor, then attaches executable behavior in operations.
 
-**Resource descriptor** -- OM entry with canonical `id`, required `systemId`, governance `status`, and optional role ownership. Workflow descriptors may mirror `capabilityKey`; agent descriptors carry `agentKind`, `sessionCapable`, and optional `actsAsRoleId`; integration descriptors name a provider.
+**Resource descriptor** -- OM entry with canonical `id`, required `systemPath`, governance `status`, and optional role ownership. Workflow descriptors may mirror `actionKey`; agent descriptors carry `agentKind`, `sessionCapable`, and optional `actsAsRoleId`; integration descriptors name a provider.
 
 **System** -- tenant-defined bounded context in `OrganizationModel.systems.systems` that groups operational resources and carries governance metadata such as responsible role, governing knowledge, driven goals, kind, and status.
 
@@ -48,11 +48,11 @@ description: Terminology disambiguation for Organization OS concepts used in the
 
 **ResourceLink** -- graph binding on resource metadata: `{ nodeId, kind }`.
 
-**Settings asymmetry** -- settings is a feature node, but individual access is normally governed by admin checks rather than user-facing feature toggles.
+**Settings asymmetry** -- Settings is a navigation/app surface whose individual pages are normally governed by admin checks rather than user-facing System toggles.
 
-**Shell model** -- provider output used by sidebars and breadcrumbs. Includes `features`, `childrenOf`, `ancestorsOf`, `parentOf`, `topLevel`, `findByPath`, `uiPositionFor`, `requiresAdminFor`, and `devOnlyFor`.
+**Shell model** -- provider output used by sidebars and breadcrumbs. Includes `systems`, `childrenOf`, `ancestorsOf`, `parentOf`, `topLevel`, `findByPath`, `requiresAdminFor`, and `devOnlyFor`.
 
-**Subshell / Sidebar** -- feature-scoped UI region rendered when the current route matches a feature whose manifest supplies a sidebar.
+**Subshell / Sidebar** -- System- or route-prefix-scoped UI region rendered when the current route matches a module whose manifest supplies a sidebar.
 
 **Topology** -- runtime resource relationships declared in `DeploymentSpec.relationships`.
 
@@ -60,7 +60,7 @@ description: Terminology disambiguation for Organization OS concepts used in the
 
 **`@elevasis/core`**
 
-- `OrganizationModel`, `OrganizationModelFeature`
+- `OrganizationModel`, `OrganizationModelSystemEntry`
 - `SystemEntry`, `ResourceEntry`
 - `resolveOrganizationModel`, `defineOrganizationModel`, `DEFAULT_ORGANIZATION_MODEL`
 - `MembershipFeatureConfig`
@@ -68,9 +68,9 @@ description: Terminology disambiguation for Organization OS concepts used in the
 
 **`@elevasis/ui`**
 
-- `FeatureModule`
-- `FeatureGuard`, `AdminGuard`, `ProtectedRoute`
-- `ElevasisFeaturesProvider`, `ElevasisCoreProvider`, `useElevasisFeatures`
+- `SystemModule`
+- `SystemGuard`, `AdminGuard`, `ProtectedRoute`
+- `ElevasisSystemsProvider`, `ElevasisCoreProvider`, `useElevasisSystems`
 
 **External project source**
 

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

@@ -1,6 +1,6 @@
 ---
 title: Composition & Extensibility
-description: Organization OS Toolkit layer guidance for customizing shared shell features without forking, including exported nav arrays, optional sidebar props, composable layout primitives, and the manifest.sidebar override pattern.
+description: Organization OS Toolkit layer guidance for customizing shared shell systems without forking, including exported nav arrays, optional sidebar props, composable layout primitives, and the manifest.sidebar override pattern.
 ---
 <!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
 <!-- Regenerate: pnpm scaffold:sync -->
@@ -8,20 +8,20 @@ description: Organization OS Toolkit layer guidance for customizing shared shell
 
 ## Overview
 
-Within Organization OS, this doc covers the **Toolkit** layer: the primitives consumers use to customize shared shell features by composition instead of fork. Consumers extend nav items, inject panels, or wrap pages by combining published primitives and assigning a custom component to `manifest.sidebar`. Copying source is physically possible but unsupported -- a fork owns upstream drift forever.
+Within Organization OS, this doc covers the **Toolkit** layer: the primitives consumers use to customize shared shell systems by composition instead of fork. Consumers extend nav items, inject panels, or wrap pages by combining published primitives and assigning a custom component to `manifest.sidebar`. Copying source is physically possible but unsupported -- a fork owns upstream drift forever.
 
-The core pattern: set `sidebar` on your manifest to a component that composes the feature's published pieces. If the published pieces can't express what you need, the missing export is a bug. File an issue instead of forking.
+The core pattern: set `sidebar` on your manifest to a component that composes the system's published pieces. If the published pieces can't express what you need, the missing export is a bug. File an issue instead of forking.
 
 Shipped in `@elevasis/ui >= 2.8.1`.
 
 ## The Override Pattern
 
-Every `FeatureModule.sidebar` is a `ComponentType`. Consumers customize by:
+Every `SystemModule.sidebar` is a `ComponentType`. Consumers customize by:
 
-1. Importing the feature's published sidebar wrapper and middle component.
+1. Importing the system's published sidebar wrapper and middle component.
 2. Wrapping or replacing the middle with custom content.
 3. Spreading the stock manifest and setting `sidebar` to their component.
-4. Passing the customized manifest to `ElevasisFeaturesProvider`.
+4. Passing the customized manifest to `ElevasisSystemsProvider`.
 
 No new manifest fields. No discriminated unions. No runtime machinery.
 
@@ -29,14 +29,14 @@ No new manifest fields. No discriminated unions. No runtime machinery.
 
 - **Adding or changing nav items?** -> Extend the exported item array and pass to `<*SidebarMiddle items={...}>`.
 - **Structural changes (injecting panels, wrapping sections)?** -> Compose `SidebarTop`, `SidebarMiddle`, and exported panels directly in your own component.
-- **Wrapping pages?** -> Import the feature's page component and wrap with custom chrome in a route file.
+- **Wrapping pages?** -> Import the system's page component and wrap with custom chrome in a route file.
 - **None of these fits?** -> Missing export is the bug. File an issue.
 
 ## Exported Primitives
 
 ### Nav item arrays
 
-Re-exported from each feature's sidebar barrel:
+Re-exported from each system sidebar barrel:
 
 - `CRM_ITEMS` from `@elevasis/ui/features/crm`
 - `LEAD_GEN_ITEMS` from `@elevasis/ui/features/lead-gen`
@@ -71,16 +71,16 @@ From `@elevasis/ui/layout`:
 - `SubshellContentContainer` -- scrollable content area with standard `md` padding and automatic topbar offset applied via `paddingTop`
 - `SubshellLoader` -- loading placeholder centered in the subshell viewport; reads the active loader from `AppearanceContext`
 
-`FeatureShell` wires these together at `width={250}` as the default sidebar width. Consumers composing their own shell layout can pass a different `width` prop to `SubshellSidebar`.
+`SystemShell` wires these together at `width={250}` as the default sidebar width. Consumers composing their own shell layout can pass a different `width` prop to `SubshellSidebar`.
 
-### SubshellSidebar features
+### SubshellSidebar behavior
 
 `SubshellSidebar` is more than a thin wrapper. Key behaviors verified in source:
 
 - **Collapsible** -- controlled by `collapsible` prop (defaults to `true`) and `defaultOpen` prop (defaults to `true`). When collapsed, the sidebar animates to zero width and a small toggle button remains visible at the bottom-right edge.
 - **Glass morphism** -- applies `color-mix(in srgb, var(--glass-background) 80%, transparent)` as background and `var(--glass-blur)` as `backdropFilter`, consistent with the theme token system.
 - **Animated transitions** -- width and opacity animate on collapse/expand using `sidebarTransitionDuration` from the layout constants.
-- **Width** -- no built-in default; the caller supplies `width`. `FeatureShell` passes `250` and this is the canonical default for stock feature sidebars.
+- **Width** -- no built-in default; the caller supplies `width`. `SystemShell` passes `250` and this is the canonical default for stock system sidebars.
 
 From `@elevasis/ui/router/context`:
 
@@ -105,26 +105,26 @@ It wraps `RouterProvider` and supplies the adapter by reading `useLocation` and
 
 ```tsx
 <TanStackRouterBridge>
-  <ElevasisFeaturesProvider ...>
-    <FeatureShell>...</FeatureShell>
-  </ElevasisFeaturesProvider>
+  <ElevasisSystemsProvider ...>
+    <SystemShell>...</SystemShell>
+  </ElevasisSystemsProvider>
 </TanStackRouterBridge>
 ```
 
 Consumers using a different router can implement `RouterAdapter` directly and pass it to `RouterProvider` instead of using this bridge.
 
-### Feature panels (CRM)
+### System panels (CRM)
 
 - `MyTasksPanel`, `QuickCreateActions` -- exported from `@elevasis/ui/features/crm`, included by default in `CrmSidebarMiddle`; consumers composing their own middle can re-include them explicitly.
 
-### Feature pages
+### System pages
 
-Every page each feature renders is exported from its feature barrel, so consumers can wrap with custom chrome without forking:
+Every page each system renders is exported from its system barrel, so consumers can wrap with custom chrome without forking:
 
 - CRM: `DealsListPage`, `DealDetailPage`
 - Lead-gen: `LeadGenOverviewPage`, `LeadGenListsPage`, `LeadGenListDetailPage`, `LeadGenCompaniesPage`, `LeadGenContactsPage`
 - Delivery: `AllTasksPage`, `UpcomingMilestonesPage`, `ProjectsListPage`, `ProjectDetailPage`
-- Operations, monitoring, settings -- full page inventories exported from their feature barrels
+- Operations, monitoring, settings -- full page inventories exported from their system barrels
 
 ## Consumer Patterns
 
@@ -199,7 +199,7 @@ export default function CustomDealsRoute() {
 }
 ```
 
-## Operations & Unmodified Features
+## Operations & Unmodified Systems
 
 - **Operations** -- uses `sidebar?: ComponentType` with route-aware dispatch; the items-prop pattern does not apply.
 - **Monitoring, Settings** -- no subshell sidebar. No customization surface needed.
@@ -207,7 +207,7 @@ export default function CustomDealsRoute() {
 
 ## Publish-Surface Discipline
 
-All primitives above flow through published subpaths (`@elevasis/ui/features/<feature>`, `@elevasis/ui/layout`, `@elevasis/ui/router/context`). Any new primitive must sync four files per `.claude/rules/ui-package.md`: `package.json` `exports`, `publishConfig.exports`, `rollup.dts.config.mjs`, and `tsup.config.ts`.
+All primitives above flow through published subpaths (`@elevasis/ui/features/<system>`, `@elevasis/ui/layout`, `@elevasis/ui/router/context`). Any new primitive must sync four files per `.claude/rules/ui-package.md`: `package.json` `exports`, `publishConfig.exports`, `rollup.dts.config.mjs`, and `tsup.config.ts`.
 
 The published barrel (`packages/ui/src/provider/published.ts`) remains headless -- no Mantine-dependent visual pieces leak into the external contract.
 
@@ -215,9 +215,9 @@ The published barrel (`packages/ui/src/provider/published.ts`) remains headless
 
 The Knowledge Browser follows the same pattern described in this document. The three tiers map directly:
 
-- **Tier 1** -- import `knowledgeManifest` from `@elevasis/ui/features/knowledge` and pass it to `ElevasisFeaturesProvider`. No further code required.
+- **Tier 1** -- import `knowledgeManifest` from `@elevasis/ui/features/knowledge` and pass it to `ElevasisSystemsProvider`. No further code required.
 - **Tier 2** -- spread the manifest, override `sidebar` to a component that composes `KnowledgeSidebar` + `KnowledgeSidebarMiddle items={customItems}`. Same shape as the CRM example above.
-- **Tier 3** -- skip the manifest, own the route, call `byFeature` / `byKind` / `byOwner` from `@elevasis/core/knowledge` directly.
+- **Tier 3** -- skip the manifest, own the route, call `bySystem` / `byKind` / `byOwner` from `@elevasis/core/knowledge` directly.
 
 One additional wiring step is required for Knowledge Browser that does not apply to CRM or Lead Gen: add `knowledgePlugin()` from `@elevasis/ui/vite-plugin-knowledge` to `vite.config.ts`. The plugin runs build-time MDX codegen so rendered body components are available at runtime.
 
@@ -232,5 +232,5 @@ Phase 1.5 adds two further extension surfaces documented in the same recipe file
 
 - **Don't fork sidebar files into your app tree.** You own upstream drift forever.
 - **Don't redefine `NavItem` locally.** Import it from `@elevasis/ui/layout` so future shape changes stay coherent.
-- **Don't monkey-patch `FEATURE_MANIFESTS`.** It's a published convenience constant; consumers build their own manifest array and pass it to the provider.
+- **Don't monkey-patch `SYSTEM_MANIFESTS`.** It's a published convenience constant; consumers build their own manifest array and pass it to the provider.
 - **Don't add discriminated-union sidebar configuration to manifests.** The single pattern (assign a component to `manifest.sidebar`) is intentional.

package/reference/scaffold/ui/customization.md

@@ -1,18 +1,18 @@
 ---
-title: Customizing Features
-description: One pattern for customizing feature sidebars and pages -- set manifest.sidebar to a component composing the feature's published pieces. Decision tree + three worked examples.
+title: Customizing Systems
+description: One pattern for customizing system sidebars and pages -- set manifest.sidebar to a component composing the system's published pieces. Decision tree + three worked examples.
 ---
 <!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
 <!-- Regenerate: pnpm scaffold:sync -->
 
 
-# Customizing Features
+# Customizing Systems
 
 **Status:** 🟢 Stable
 
 > **Requires `@elevasis/ui` >= 2.8.1.**
 
-There is one pattern for customizing a feature's sidebar or pages: set `sidebar` on your manifest override to a component that composes the feature's published pieces. Pass custom `items` to swap the nav array, or compose `SidebarTop` + `SidebarMiddle` + exported panels directly for structural changes. Never fork a source file as a first resort -- if you copy source you own upstream drift forever.
+There is one pattern for customizing a system's sidebar or pages: set `sidebar` on your manifest override to a component that composes the system's published pieces. Pass custom `items` to swap the nav array, or compose `SidebarTop` + `SidebarMiddle` + exported panels directly for structural changes. Never fork a source file as a first resort -- if you copy source you own upstream drift forever.
 
 ## Decision Tree
 
@@ -20,7 +20,7 @@ There is one pattern for customizing a feature's sidebar or pages: set `sidebar`
 
 **Structural changes (injecting panels, reordering sections, wrapping sections)?** Compose `SidebarTop`, `SidebarMiddle`, and exported panels (`MyTasksPanel`, `QuickCreateActions`) directly into your own component and assign it to the manifest's `sidebar` field.
 
-**Wrapping pages?** Import the feature's page component and wrap with custom chrome in a route file.
+**Wrapping pages?** Import the system's page component and wrap with custom chrome in a route file.
 
 **Neither fits?** The missing export is a bug in `@elevasis/ui` -- file an issue. Copying source is physically possible but unsupported. You own upstream drift forever.
 
@@ -28,7 +28,7 @@ There is one pattern for customizing a feature's sidebar or pages: set `sidebar`
 
 Extend CRM's nav by spreading `CRM_ITEMS` and appending a Reports entry. Pass the extended array to `CrmSidebarMiddle`.
 
-Wire the override in `ui/src/routes/__root.tsx`, where feature manifests are assembled before being passed to `ElevasisFeaturesProvider`.
+Wire the override in `ui/src/routes/__root.tsx`, where system manifests are assembled before being passed to `ElevasisSystemsProvider`.
 
 ```tsx
 // ui/src/routes/__root.tsx (excerpt -- add after existing imports)
@@ -54,11 +54,11 @@ const MyCrmSidebar = () => (
 const customCrmManifest = { ...crmManifest, sidebar: MyCrmSidebar }
 ```
 
-Then swap `crmManifest` for `customCrmManifest` in the `FEATURE_MANIFESTS` array:
+Then swap `crmManifest` for `customCrmManifest` in the `SYSTEM_MANIFESTS` array:
 
 ```tsx
-// In the FEATURE_MANIFESTS array (same file)
-const FEATURE_MANIFESTS: FeatureModule[] = [
+// In the SYSTEM_MANIFESTS array (same file)
+const SYSTEM_MANIFESTS: SystemModule[] = [
   leadGenManifest,
   customCrmManifest,   // <-- replaces crmManifest
   deliveryManifest,
@@ -120,7 +120,7 @@ const customCrmManifest = { ...crmManifest, sidebar: MyCrmSidebar }
 
 ## Worked Example 3: Page Wrapping
 
-Import a feature's page component and wrap it with custom chrome in a route file. This keeps the feature's business logic intact while adding project-specific framing (banners, secondary nav, analytics context, etc.).
+Import a system's page component and wrap it with custom chrome in a route file. This keeps the system's business logic intact while adding project-specific framing (banners, secondary nav, analytics context, etc.).
 
 The exported CRM page components are `DealsListPage` and `DealDetailPage`:
 
@@ -241,6 +241,6 @@ For broader lead-gen extension work across pages, hooks, list/member state, arti
 | `LEAD_GEN_ITEMS`, `LeadGenSidebar`, `LeadGenSidebarTop`, `LeadGenSidebarMiddle`, `leadGenManifest`                                                                    | `@elevasis/ui/features/lead-gen` |
 | `DELIVERY_PROJECT_ITEMS`, `DELIVERY_WORK_ITEMS`, `DELIVERY_COMMUNICATION_ITEMS`, `ProjectsSidebar`, `ProjectsSidebarTop`, `ProjectsSidebarMiddle`, `deliveryManifest` | `@elevasis/ui/features/delivery` |
 | `SubshellNavList`, `SubshellNavItem`, `SubshellSidebarSection`, `NavItem`                                                                                             | `@elevasis/ui/layout`            |
-| `FeatureModule`                                                                                                                                                       | `@elevasis/ui/provider`          |
+| `SystemModule`                                                                                                                                                        | `@elevasis/ui/provider`          |
 
 Operations, monitoring, and settings have no customizable sidebar items. Operations sidebar is route-aware dispatch and not extended via the `items` pattern.

package/reference/scaffold/ui/feature-flags-and-gating.md

@@ -1,14 +1,14 @@
 <!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
 <!-- Regenerate: pnpm scaffold:sync -->
 
-# Feature Flags And Gating
+# System Flags And Gating
 
-Feature visibility is keyed by Organization Model feature ID.
+System visibility is keyed by Organization Model system ID.
 
 ## Where Visibility Comes From
 
-- `features[].enabled` in the organization model defines the baseline.
-- Membership feature config can override individual feature IDs.
+- `systems.systems[].enabled` in the organization model defines the baseline.
+- Membership system config can override individual system IDs.
 - `requiresAdmin` hides sidebar entries from non-admins.
 - `devOnly` hides sidebar entries outside development mode.
 
@@ -20,9 +20,9 @@ Navigation visibility is cosmetic. Always guard routes directly:
 
 ```tsx
 <ProtectedRoute>
-  <FeatureGuard featureKey="sales.crm">
+  <SystemGuard systemKey="sales.crm">
     <Outlet />
-  </FeatureGuard>
+  </SystemGuard>
 </ProtectedRoute>
 ```
 
@@ -34,7 +34,7 @@ For admin-only routes:
 </AdminGuard>
 ```
 
-## Adding A Gated Feature
+## Adding A Gated System
 
 ```ts
 {
@@ -46,4 +46,4 @@ For admin-only routes:
 }
 ```
 
-Use the same ID in `FeatureGuard featureKey` and `FeatureModule.featureId`.
+Use the same ID in `SystemGuard systemKey` and `SystemModule.systemId`.

package/reference/scaffold/ui/feature-shell.mdx

@@ -1,6 +1,6 @@
 ---
-title: Feature Shell & Provider Runtime
-description: Current feature shell contract for flat Organization Model features, manifests, route matching, sidebars, and breadcrumbs.
+title: System Shell & Provider Runtime
+description: Current system shell contract for Organization Model systems, manifests, route matching, sidebars, and breadcrumbs.
 ---
 <!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
 <!-- Regenerate: pnpm scaffold:sync -->
@@ -8,38 +8,38 @@ description: Current feature shell contract for flat Organization Model features
 
 ## Overview
 
-The feature shell derives app navigation from `OrganizationModel.features`. Feature manifests provide implementation hooks such as icons and sidebars; they no longer own structural navigation.
+The system shell derives app navigation from `OrganizationModel.systems`. System manifests provide implementation hooks such as icons and sidebars; they do not own structural navigation.
 
 ## Source Of Truth
 
-- `packages/core/src/organization-model/defaults.ts` -- default flat feature list
+- `packages/core/src/organization-model/defaults.ts` -- default system list
 - `packages/core/src/organization-model/helpers.ts` -- `childrenOf`, `ancestorsOf`, `parentOf`, `topLevel`, `findByPath`
-- `packages/ui/src/features/registry/types.ts` -- `FeatureModule`
-- `packages/ui/src/provider/ElevasisFeaturesProvider.tsx` -- runtime resolver
+- `packages/ui/src/features/registry/types.ts` -- `SystemModule`
+- `packages/ui/src/provider/ElevasisSystemsProvider.tsx` -- runtime resolver
 - `packages/ui/src/components/navigation/useBreadcrumbs.ts` -- breadcrumb derivation
 
-## FeatureModule
+## SystemModule
 
 ```ts
-export interface FeatureModule {
+export interface SystemModule {
   key: string
-  featureId: string
+  systemId: string
   capabilityIds?: string[]
-  icon?: FeatureIconComponent
-  sidebar?: FeatureSidebarComponent
-  organizationGraph?: { featureId: string }
+  icon?: SystemIconComponent
+  sidebar?: SystemSidebarComponent
+  organizationGraph?: { systemId: string }
 }
 ```
 
-`featureId` must match an Organization Model feature ID. Structural fields such as route lists, nav labels, and nested links belong on `OrganizationModel.features`.
+`systemId` must match an Organization Model system ID. Structural fields such as route lists, nav labels, and nested links belong on `OrganizationModel.systems`.
 
 ## Shell Model
 
-`useElevasisFeatures()` exposes `shellModel`:
+`useElevasisSystems()` exposes `shellModel`:
 
 ```ts
 {
-  features,
+  systems,
   findByPath,
   findById,
   childrenOf,
@@ -56,15 +56,15 @@ Sidebar rendering walks `topLevel()` and `childrenOf(id)`. Breadcrumbs resolve `
 
 ## Access
 
-Feature access is keyed by Organization Model feature ID. `requiresAdmin` and `devOnly` inherit from ancestor feature nodes and are applied when deriving visible sidebar entries.
+System access is keyed by Organization Model system ID. `requiresAdmin` and `devOnly` inherit from ancestor system nodes and are applied when deriving visible sidebar entries.
 
 Routes still need guards:
 
 ```tsx
 <ProtectedRoute>
-  <FeatureGuard featureKey="sales.crm">
+  <SystemGuard systemKey="sales.crm">
     <Outlet />
-  </FeatureGuard>
+  </SystemGuard>
 </ProtectedRoute>
 ```
 
@@ -72,4 +72,4 @@ Use `AdminGuard` for pages that require platform-admin privileges.
 
 ## External Shells
 
-External templates pass `canonicalOrganizationModel` into `ElevasisFeaturesProvider` and derive sidebar links locally from `shellModel`. There is no separate nav config file to keep in sync.
+Host apps pass `SYSTEM_MANIFESTS` or their own `SystemModule[]` into `ElevasisSystemsProvider` and derive sidebar links locally from `shellModel`. There is no separate nav config file to keep in sync.

package/reference/scaffold/ui/recipes.md

@@ -1,6 +1,6 @@
 ---
 title: UI Recipes
-description: Current recipes for adding pages, feature-gated routes, feature components, theme tokens, Organization Model sidebar entries, and executable resources.
+description: Current recipes for adding pages, system-gated routes, system components, theme tokens, Organization Model sidebar entries, and executable resources.
 ---
 <!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
 <!-- Regenerate: pnpm scaffold:sync -->
@@ -10,25 +10,25 @@ description: Current recipes for adding pages, feature-gated routes, feature com
 
 ## 1. Add a Top-Level Page
 
-Create `ui/src/routes/my-feature.index.tsx`:
+Create `ui/src/routes/my-system.index.tsx`:
 
 ```tsx
 import { createFileRoute } from '@tanstack/react-router'
 import { ProtectedRoute } from '@/features/auth'
 import { AppShellContentContainer, AppTopbarAdjusterWrapper, PageContainer } from '@elevasis/ui/layout'
-import { MyFeaturePage } from '@/features/my-feature/components/MyFeaturePage'
+import { MySystemPage } from '@/features/my-system/components/MySystemPage'
 
-export const Route = createFileRoute('/my-feature/')({
-  component: MyFeatureRouteComponent
+export const Route = createFileRoute('/my-system/')({
+  component: MySystemRouteComponent
 })
 
-function MyFeatureRouteComponent() {
+function MySystemRouteComponent() {
   return (
     <ProtectedRoute>
       <AppTopbarAdjusterWrapper>
         <AppShellContentContainer>
           <PageContainer>
-            <MyFeaturePage />
+            <MySystemPage />
           </PageContainer>
         </AppShellContentContainer>
       </AppTopbarAdjusterWrapper>
@@ -37,48 +37,50 @@ function MyFeatureRouteComponent() {
 }
 ```
 
-Add the sidebar entry as a feature node in `core/config/organization-model.ts`:
+Add the sidebar entry as a system node in `core/config/organization-model.ts`:
 
 ```ts
-features: [
+systems: {
+  systems: [
   {
-    id: 'my-feature',
-    label: 'My Feature',
+    id: 'my-system',
+    label: 'My System',
     enabled: true,
-    path: '/my-feature',
+    path: '/my-system',
     icon: 'star',
     uiPosition: 'sidebar-primary'
   }
-]
+  ]
+}
 ```
 
-TanStack Router derives the path from the filename. The sidebar is derived from `OrganizationModel.features`.
+TanStack Router derives the path from the filename. The sidebar is derived from `OrganizationModel.systems`.
 
-## 2. Add a Feature-Gated Page
+## 2. Add a System-Gated Page
 
-Wrap the route with `FeatureGuard` and use the same feature ID as the org model node.
+Wrap the route with `SystemGuard` and use the same system ID as the org model node.
 
 ```tsx
-import { FeatureGuard } from '@/features/auth/guards/FeatureGuard'
+import { SystemGuard } from '@elevasis/ui/features/auth'
 
-function MyFeatureRouteComponent() {
+function MySystemRouteComponent() {
   return (
     <ProtectedRoute>
-      <FeatureGuard featureKey="my-feature">
+      <SystemGuard systemKey="my-system">
         <AppTopbarAdjusterWrapper>
           <AppShellContentContainer>
             <PageContainer>
-              <MyFeaturePage />
+              <MySystemPage />
             </PageContainer>
           </AppShellContentContainer>
         </AppTopbarAdjusterWrapper>
-      </FeatureGuard>
+      </SystemGuard>
     </ProtectedRoute>
   )
 }
 ```
 
-Set `enabled: false` in the feature node to hide it by default. Use `requiresAdmin: true` on the feature node plus `AdminGuard` in the route for admin-only pages.
+Set `enabled: false` in the system node to hide it by default. Use `requiresAdmin: true` on the system node plus `AdminGuard` in the route for admin-only pages.
 
 ## 3. Add a Nested Page
 
@@ -101,7 +103,7 @@ function ReportingLayoutComponent() {
 }
 ```
 
-Add dotted feature nodes for the sidebar hierarchy:
+Add dotted system nodes for the sidebar hierarchy:
 
 ```ts
 { id: 'reporting', label: 'Reporting', enabled: true, uiPosition: 'sidebar-primary' },
@@ -111,7 +113,7 @@ Add dotted feature nodes for the sidebar hierarchy:
 
 Containers omit `path`; leaves provide `path`.
 
-## 4. Add a Feature-Scoped Component
+## 4. Add a System-Scoped Component
 
 Use `ui/src/features/<name>/` when logic is shared across routes or owns local state.
 
@@ -127,7 +129,7 @@ ui/src/features/reporting/
   types.ts
 ```
 
-Use `@/*` imports for app-local cross-feature imports and keep route layout concerns in route files.
+Use `@/*` imports for app-local cross-system imports and keep route layout concerns in route files.
 
 ## 5. Change Theme Tokens
 
@@ -180,7 +182,6 @@ config: {
   type: resourceDescriptors.writeNote.kind,
   version: '1.0.0',
   status: 'prod',
-  links: [{ nodeId: 'feature:sales.crm', kind: 'operates-on' }],
   category: 'production'
 }
 ```
@@ -210,7 +211,7 @@ export function DealPanel({ dealId }: { dealId: string }) {
 
 ## Cross-References
 
-- `./feature-flags-and-gating.md` -- feature and admin access model
+- `./feature-flags-and-gating.md` -- system and admin access model
 - `./feature-shell.mdx` -- provider and sidebar derivation
-- `./customization.md` -- feature sidebar customization
+- `./customization.md` -- system sidebar customization
 - `ui/src/config/README.md` -- theme, background, and loader config