@elevasis/sdk 1.8.2 → 1.9.0

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

@@ -1,3 +1,5 @@
+<!-- @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.

package/reference/scaffold/reference/glossary.md

@@ -1,105 +1,105 @@
----
-title: Glossary
-description: Terminology disambiguation for Organization OS concepts used in the template scaffold, foundations, and published packages.
----
-
-# Glossary
-
-For canonical (internal) definitions, see the Organization OS glossary in the monorepo architecture docs.
-
-This condensed version covers every ambiguity-prone term a template consumer or agent is likely to encounter. Alphabetical within each section.
-
----
-
-## Terms
-
-**featureId** (on FeatureModule) -- the `id` string a `FeatureModule` declares so the provider knows which entry in `OrganizationModel.features` to check for access gating. Required field on every `FeatureModule`. Must match the `id` of an entry in the features array (e.g. `'crm'`, `'projects'`). Distinct from the nav-item `featureKey` (see below). No aliasing layer -- IDs are direct matches.
-
-**AdminGuard** -- route-level admin wrapper from `@elevasis/ui/features/auth`. Wraps routes restricted to admin members. Must nest inside `ProtectedRoute`. Does not replace `requiresAdmin` on nav entries -- use both when both route access and nav visibility need admin enforcement.
-
-**`/configure`** -- the recurring organization model editor for external projects. A slash skill (not a command) at `.claude/skills/configure/SKILL.md`. Runs a layered QA flow across `identity`, `customers`, `offerings`, `roles`, `goals`, `techStack`, `features`, and `labels`. Can be invoked without an argument (full layered flow) or with a domain argument (`/configure identity`, `/configure customers`, etc.) for targeted edits. Every write is gated through `resolveOrganizationModel()` + `OrganizationModelSchema.parse()` with a TypeScript type-check fallback. The ambient vibe layer delegates Codify and Toggle intents to `/configure` rather than writing directly. Distinct from `/setup` (first-time bootstrap) and `/org-os manage` (monorepo-only feature gating). `/configure` is available in external projects only.
-
-**Contract** -- the publishable I/O boundary: Zod schemas in `foundations/types/index.ts` for workflow inputs/outputs, or the `FeatureModule` TypeScript shape for shell features. Distinct from "manifest": a contract is the structural definition; a manifest is a specific feature instance conforming to that shape.
-
-**DeploymentSpec** -- the complete resource collection for one organization (`workflows`, `agents`, `triggers`, `integrations`, `relationships`, `externalResources`, `humanCheckpoints`). Defined in `@repo/core`. The `operations/src/index.ts` file in each external project exports one `DeploymentSpec`.
-
-**Domain** -- removed concept. What was previously a `SemanticDomain` entry in `OrganizationModel.domains` is now expressed directly as a **Feature** in the `features` array. The `domains` field no longer exists on `OrganizationModel`. Semantic grouping (entity IDs, surface IDs, resource IDs, capability IDs) now lives on each `OrganizationModelFeature` object.
-
-**Domain rename wave (2026-04-20)** -- three legacy top-level domain field names on `OrganizationModel` were renamed to align with user-visible labels: `crm` → `sales`, `leadGen` → `prospecting`, `delivery` → `projects`. Feature ID constants (`CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`) and consumer-facing feature IDs (`'crm'`, `'lead-gen'`) are unchanged. Only the Zod schema field names, domain files, surface IDs, and imports were updated.
-
-**Feature** -- the unified concept replacing the former three-layer system (feature keys, semantic domains, feature modules). Always qualify which layer is in scope:
-
-- **Platform capability** -- a product area (Execution Engine, Workflows, Agents, etc.). Not one-to-one with shell features.
-- **Organization-model feature** (`OrganizationModelFeature`) -- a single entry in `OrganizationModel.features`. Combines access gating (`enabled`), semantic grouping (`entityIds`, `surfaceIds`, `resourceIds`, `capabilityIds`), and display metadata (`label`, `description`, `color`, `icon`). Seven defaults: `crm`, `lead-gen`, `projects`, `operations`, `monitoring`, `settings`, `seo`.
-- **Shell FeatureModule** -- a manifest-backed UI feature registered with `ElevasisFeaturesProvider`. Declares `featureId` matching an org-model feature ID. Seven manifest-backed: `lead-gen`, `crm`, `projects`, `operations`, `monitoring`, `settings`, `seo`. Two utility (no manifest): `auth`, `dashboard`.
-
-**featureKey** (nav-item) -- optional field on `FeatureNavEntry` and `FeatureNavLink` that gates a specific nav item's visibility independently of the module's `featureId`. Must match a feature ID in the org model. May be more specific than the module's `featureId` when a nested link needs a narrower gate.
-
-**FeatureGuard** -- route-level feature gate from `@elevasis/ui/features/auth`. Blocks access to a route when the resolved org model has the relevant feature key disabled. Must nest inside `ProtectedRoute`. Distinct from `AdminGuard` (admin membership) and `ProtectedRoute` (authentication).
-
-**FeatureModule** -- the manifest contract each shell feature provides to `ElevasisFeaturesProvider`. Defined in `@repo/ui`, NOT `@repo/core`. Fields: `key`, `featureId` (required -- replaces the former `accessFeatureKey`), `capabilityIds`, `navEntry`, `sidebar`, `subshellRoutes`, `organizationGraph` (Operations-only). Template consumers build a local manifest array and pass it to `ElevasisFeaturesProvider` in `__root.tsx`.
-
-**Foundations** -- the adapter layer in `foundations/` (two modules: `config/organization-model.ts` and `types/index.ts`). Source package with no build step. Depends only on `@elevasis/core` (npm) and `zod`. Never import `@repo/core` from foundations -- that would break standalone deployment.
-
-**Identity domain** -- legal identity, distinct from `branding` (display identity). Lives at `OrganizationModel.identity`. Fields: `mission`, `vision`, `legalName`, `entityType`, `jurisdiction`, `industryCategory`, `geographicFocus`, `timeZone`, `businessHours`. Agents use identity fields for compliance, localization, and context. Edit via `/configure identity`.
-
-**Customers domain** -- customer segments with jobs-to-be-done, pains, gains, firmographics, and value propositions. Lives at `OrganizationModel.customers`. Each `CustomerSegment` has `id`, `name`, `description`, `jobsToBeDone`, `pains`, `gains`, `valueProp`, and optional `firmographics`. Agents use segments for outreach targeting and sales automation. Edit via `/configure customers`.
-
-**Goals domain** -- organizational goals with period bounds and measurable outcomes. Lives at `OrganizationModel.goals`. User-facing text uses "goals" and "measurable outcomes"; the schema field name `keyResults` is retained for OKR tooling compatibility but is never surfaced to users as "OKR" or "key results". Edit via `/configure goals`.
-
-**Manifest** -- a `FeatureModule` instance that declares what one shell feature contributes at runtime (nav, sidebar, subshell routes, access key, semantic references). The provider registers an array of manifests at startup and validates them against the resolved org model.
-
-**MembershipFeatureConfig** -- per-member-per-org feature overrides stored in `org_memberships.config`. The `features` field is now `Record<string, boolean>` -- any feature ID can be overridden per member. Previously hardcoded to five keys (`operations`, `monitoring`, `acquisition`, `delivery`, `seo`); now open to any feature ID in the org model.
-
-**Offerings domain** -- products and services with pricing model, price, currency, target segment references, and optional delivery-feature references. Lives at `OrganizationModel.offerings`. Each `Product` has `id`, `name`, `description`, `pricingModel` (`one-time | subscription | usage-based | custom`), optional `price` and `currency`, `targetSegmentIds` (cross-ref validated against `customers.segments`), and optional `deliveryFeatureId` (cross-ref validated against `features`). Edit via `/configure offerings`.
-
-**Operations domain** -- catalog of stateful runtime entities. Lives at `OrganizationModel.operations`. Each `OperationEntry` has `id`, `label`, `semanticClass` (one of `queue | executions | sessions | notifications | schedules`), optional `featureId`, and optional `supportedStatusSemanticClass` array. Used by the ambient vibe layer to narrate runtime entity state. Default entries cover HITL queue, executions, sessions, notifications, and schedules.
-
-**OrganizationModel** -- the top-level semantic contract for an organization. Published from `@elevasis/core/organization-model`. In the template, authored in `foundations/config/organization-model.ts` and exported as `canonicalOrganizationModel` (passed to `ElevasisFeaturesProvider`) and `organizationModel` (enriched shape for app-local use). As of the 2026-04-20 expansion, the model contains 14 top-level domains: `features`, `branding`, `navigation`, `sales` (formerly `crm`), `prospecting` (formerly `leadGen`), `projects` (formerly `delivery`), `identity`, `customers`, `offerings`, `roles`, `goals`, `statuses`, `operations`, and `resourceMappings` (with optional `techStack` per entry). Use `/configure` as the entry point for editing reality domains in external projects.
-
-**OrganizationModelFeature** -- the TypeScript type (`z.infer<typeof FeatureSchema>`) for a single entry in `OrganizationModel.features`. Replaces the former `OrganizationModelFeatureKey` (closed enum) and `OrganizationModelSemanticDomain`. Each feature has `id`, `label`, `enabled`, and semantic grouping arrays (`entityIds`, `surfaceIds`, `resourceIds`, `capabilityIds`). Exported from `@elevasis/core/organization-model`. Default feature IDs: `crm`, `lead-gen`, `projects`, `operations`, `monitoring`, `settings`, `submitted-requests`, `seo`. Note: feature IDs `crm` and `lead-gen` are unchanged by the domain rename wave; only the domain field names on `OrganizationModel` were renamed (`crm` → `sales`, `leadGen` → `prospecting`).
-
-**Provider / ElevasisFeaturesProvider** -- the runtime that registers manifests, resolves feature access against the org model, dispatches subshell routing via `FeatureShell`, and exposes resolved state through `useElevasisFeatures()`. Mounted in `__root.tsx`. Accepts `features`, optional `organizationModel`, and optional `appShellOverrides`.
-
-**Resolved types (ResolvedFeatureModule, ResolvedShellNavItem)** -- provider output. `ResolvedFeatureModule` extends `FeatureModule` with `access` (enabled state and `featureId`) and `semantics` (merged capability and surface IDs). `ResolvedShellNavItem` extends `FeatureNavEntry` with `placement`, `source`, and `featureId`. Both from `@elevasis/ui`.
-
-**Resource** -- an entry in `OrganizationModel.resourceMappings` linking a deployable automation resource into the semantic model. At the registry layer, resources are `WorkflowDefinition` or `AgentDefinition` instances in a `DeploymentSpec`. Each resource mapping may carry an optional `techStack` extension with `platform`, `purpose`, `credentialStatus`, and `isSystemOfRecord` fields.
-
-**Roles domain** -- role chart with responsibilities, reporting lines, and role holders. Lives at `OrganizationModel.roles`. Each `Role` has `id`, `title`, `responsibilities` (string array), optional `reportsToId` (cross-ref validated within the same collection), and optional `heldBy` (name or email). All field names are plain-language; no EOS jargon (`seats`, `accountabilities`) is used. Edit via `/configure roles`.
-
-**Statuses domain** -- flat registry of all status entries across delivery, queue, execution, schedule, and request semantic classes. Lives at `OrganizationModel.statuses`. Each `StatusEntry` has `id`, `label`, `semanticClass` (closed enum), and optional `category`. Labels are the canonical plain-language strings the ambient vibe layer reads when narrating status -- never hardcoded strings. `QueueTaskStatus` in the queue domain routes through this registry.
-
-**Settings asymmetry** -- `settings` is a valid feature ID (org-level, present in `OrganizationModel.features` with `enabled: true` by default). `MembershipFeatureConfig.features` is now `Record<string, boolean>`, so `settings` can technically be overridden per member, but the convention is still to gate settings visibility via `requiresAdmin` on the nav entry and `AdminGuard` on routes rather than per-member feature overrides.
-
-**Subshell / Sidebar** -- the feature-scoped UI region rendered when the current route matches a manifest's `subshellRoutes`. Each `FeatureModule.sidebar` is a `ComponentType`. Consumers customize by composing the feature's published sidebar primitives (`CrmSidebar`, `CrmSidebarMiddle`, etc.) and assigning their component to `manifest.sidebar`.
-
-**Surface** -- a navigable view in `OrganizationModel.navigation.surfaces`. Identified by a dotted `id` (e.g., `sales.pipeline`). Has `path`, `surfaceType`, optional `featureId` gate (replaces the former `featureKey` field), and cross-reference arrays (`featureIds`, `entityIds`, `resourceIds`, `capabilityIds`). Distinct from "page": a surface is the org-model declaration; a page is the React component rendered at the route.
-
-**Topology** -- resource relationships (`triggers`, `uses`, `approval`) declared in `DeploymentSpec.relationships` and `HumanCheckpointDefinition.routesTo`. Used for Command View graph edges.
-
----
-
-## Package-Boundary Cheat Sheet
-
-**`@elevasis/core`** (published npm)
-
-- `OrganizationModel`, `OrganizationModelFeature`, `OrganizationModelSurface`, `OrganizationModelResourceMapping`
-- `OrganizationModelIdentity`, `OrganizationModelCustomers`, `OrganizationModelOfferings`, `OrganizationModelRoles`, `OrganizationModelGoals`
-- `OrganizationModelStatuses`, `OrganizationModelOperations`
-- `TechStackEntrySchema`, `OrganizationModelTechStackEntry`
-- `resolveOrganizationModel`, `defineOrganizationModel`, `DEFAULT_ORGANIZATION_MODEL`
-- `MembershipFeatureConfig`
-
-**`@elevasis/ui`** (published npm)
-
-- `FeatureModule`, `FeatureNavEntry`, `FeatureNavLink`
-- `ResolvedFeatureModule`, `ResolvedShellNavItem`
-- `FeatureGuard`, `AdminGuard`, `ProtectedRoute`
-- `ElevasisFeaturesProvider`, `ElevasisCoreProvider`, `useElevasisFeatures`
-- `createFeatureAccessHook`
-
-**`foundations/`** (local source package -- not published)
-
-- `canonicalOrganizationModel` -- passed to `ElevasisFeaturesProvider`
-- `organizationModel` -- enriched shape for app-local code
-- Workflow I/O schemas (`types/index.ts`)
+---
+title: Glossary
+description: Terminology disambiguation for Organization OS concepts used in the template scaffold, foundations, and published packages.
+---
+
+# Glossary
+
+For canonical (internal) definitions, see the Organization OS glossary in the monorepo architecture docs.
+
+This condensed version covers every ambiguity-prone term a template consumer or agent is likely to encounter. Alphabetical within each section.
+
+---
+
+## Terms
+
+**featureId** (on FeatureModule) -- the `id` string a `FeatureModule` declares so the provider knows which entry in `OrganizationModel.features` to check for access gating. Required field on every `FeatureModule`. Must match the `id` of an entry in the features array (e.g. `'crm'`, `'projects'`). Distinct from the nav-item `featureKey` (see below). No aliasing layer -- IDs are direct matches.
+
+**AdminGuard** -- route-level admin wrapper from `@elevasis/ui/features/auth`. Wraps routes restricted to admin members. Must nest inside `ProtectedRoute`. Does not replace `requiresAdmin` on nav entries -- use both when both route access and nav visibility need admin enforcement.
+
+**`/configure`** -- the recurring organization model editor for external projects. A slash skill (not a command) at `.claude/skills/configure/SKILL.md`. Runs a layered QA flow across `identity`, `customers`, `offerings`, `roles`, `goals`, `techStack`, `features`, and `labels`. Can be invoked without an argument (full layered flow) or with a domain argument (`/configure identity`, `/configure customers`, etc.) for targeted edits. Every write is gated through `resolveOrganizationModel()` + `OrganizationModelSchema.parse()` with a TypeScript type-check fallback. The ambient vibe layer delegates Codify and Toggle intents to `/configure` rather than writing directly. Distinct from `/setup` (first-time bootstrap) and `/org-os manage` (monorepo-only feature gating). `/configure` is available in external projects only.
+
+**Contract** -- the publishable I/O boundary: Zod schemas in `foundations/types/index.ts` for workflow inputs/outputs, or the `FeatureModule` TypeScript shape for shell features. Distinct from "manifest": a contract is the structural definition; a manifest is a specific feature instance conforming to that shape.
+
+**DeploymentSpec** -- the complete resource collection for one organization (`workflows`, `agents`, `triggers`, `integrations`, `relationships`, `externalResources`, `humanCheckpoints`). Defined in `@repo/core`. The `operations/src/index.ts` file in each external project exports one `DeploymentSpec`.
+
+**Domain** -- removed concept. What was previously a `SemanticDomain` entry in `OrganizationModel.domains` is now expressed directly as a **Feature** in the `features` array. The `domains` field no longer exists on `OrganizationModel`. Semantic grouping (entity IDs, surface IDs, resource IDs, capability IDs) now lives on each `OrganizationModelFeature` object.
+
+**Domain rename wave (2026-04-20)** -- three legacy top-level domain field names on `OrganizationModel` were renamed to align with user-visible labels: `crm` → `sales`, `leadGen` → `prospecting`, `delivery` → `projects`. Feature ID constants (`CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`) and consumer-facing feature IDs (`'crm'`, `'lead-gen'`) are unchanged. Only the Zod schema field names, domain files, surface IDs, and imports were updated.
+
+**Feature** -- the unified concept replacing the former three-layer system (feature keys, semantic domains, feature modules). Always qualify which layer is in scope:
+
+- **Platform capability** -- a product area (Execution Engine, Workflows, Agents, etc.). Not one-to-one with shell features.
+- **Organization-model feature** (`OrganizationModelFeature`) -- a single entry in `OrganizationModel.features`. Combines access gating (`enabled`), semantic grouping (`entityIds`, `surfaceIds`, `resourceIds`, `capabilityIds`), and display metadata (`label`, `description`, `color`, `icon`). Seven defaults: `crm`, `lead-gen`, `projects`, `operations`, `monitoring`, `settings`, `seo`.
+- **Shell FeatureModule** -- a manifest-backed UI feature registered with `ElevasisFeaturesProvider`. Declares `featureId` matching an org-model feature ID. Seven manifest-backed: `lead-gen`, `crm`, `projects`, `operations`, `monitoring`, `settings`, `seo`. Two utility (no manifest): `auth`, `dashboard`.
+
+**featureKey** (nav-item) -- optional field on `FeatureNavEntry` and `FeatureNavLink` that gates a specific nav item's visibility independently of the module's `featureId`. Must match a feature ID in the org model. May be more specific than the module's `featureId` when a nested link needs a narrower gate.
+
+**FeatureGuard** -- route-level feature gate from `@elevasis/ui/features/auth`. Blocks access to a route when the resolved org model has the relevant feature key disabled. Must nest inside `ProtectedRoute`. Distinct from `AdminGuard` (admin membership) and `ProtectedRoute` (authentication).
+
+**FeatureModule** -- the manifest contract each shell feature provides to `ElevasisFeaturesProvider`. Defined in `@repo/ui`, NOT `@repo/core`. Fields: `key`, `featureId` (required -- replaces the former `accessFeatureKey`), `capabilityIds`, `navEntry`, `sidebar`, `subshellRoutes`, `organizationGraph` (Operations-only). Template consumers build a local manifest array and pass it to `ElevasisFeaturesProvider` in `__root.tsx`.
+
+**Foundations** -- the adapter layer in `foundations/` (two modules: `config/organization-model.ts` and `types/index.ts`). Source package with no build step. Depends only on `@elevasis/core` (npm) and `zod`. Never import `@repo/core` from foundations -- that would break standalone deployment.
+
+**Identity domain** -- legal identity, distinct from `branding` (display identity). Lives at `OrganizationModel.identity`. Fields: `mission`, `vision`, `legalName`, `entityType`, `jurisdiction`, `industryCategory`, `geographicFocus`, `timeZone`, `businessHours`. Agents use identity fields for compliance, localization, and context. Edit via `/configure identity`.
+
+**Customers domain** -- customer segments with jobs-to-be-done, pains, gains, firmographics, and value propositions. Lives at `OrganizationModel.customers`. Each `CustomerSegment` has `id`, `name`, `description`, `jobsToBeDone`, `pains`, `gains`, `valueProp`, and optional `firmographics`. Agents use segments for outreach targeting and sales automation. Edit via `/configure customers`.
+
+**Goals domain** -- organizational goals with period bounds and measurable outcomes. Lives at `OrganizationModel.goals`. User-facing text uses "goals" and "measurable outcomes"; the schema field name `keyResults` is retained for OKR tooling compatibility but is never surfaced to users as "OKR" or "key results". Edit via `/configure goals`.
+
+**Manifest** -- a `FeatureModule` instance that declares what one shell feature contributes at runtime (nav, sidebar, subshell routes, access key, semantic references). The provider registers an array of manifests at startup and validates them against the resolved org model.
+
+**MembershipFeatureConfig** -- per-member-per-org feature overrides stored in `org_memberships.config`. The `features` field is now `Record<string, boolean>` -- any feature ID can be overridden per member. Previously hardcoded to five keys (`operations`, `monitoring`, `acquisition`, `delivery`, `seo`); now open to any feature ID in the org model.
+
+**Offerings domain** -- products and services with pricing model, price, currency, target segment references, and optional delivery-feature references. Lives at `OrganizationModel.offerings`. Each `Product` has `id`, `name`, `description`, `pricingModel` (`one-time | subscription | usage-based | custom`), optional `price` and `currency`, `targetSegmentIds` (cross-ref validated against `customers.segments`), and optional `deliveryFeatureId` (cross-ref validated against `features`). Edit via `/configure offerings`.
+
+**Operations domain** -- catalog of stateful runtime entities. Lives at `OrganizationModel.operations`. Each `OperationEntry` has `id`, `label`, `semanticClass` (one of `queue | executions | sessions | notifications | schedules`), optional `featureId`, and optional `supportedStatusSemanticClass` array. Used by the ambient vibe layer to narrate runtime entity state. Default entries cover HITL queue, executions, sessions, notifications, and schedules.
+
+**OrganizationModel** -- the top-level semantic contract for an organization. Published from `@elevasis/core/organization-model`. In the template, authored in `foundations/config/organization-model.ts` and exported as `canonicalOrganizationModel` (passed to `ElevasisFeaturesProvider`) and `organizationModel` (enriched shape for app-local use). As of the 2026-04-20 expansion, the model contains 14 top-level domains: `features`, `branding`, `navigation`, `sales` (formerly `crm`), `prospecting` (formerly `leadGen`), `projects` (formerly `delivery`), `identity`, `customers`, `offerings`, `roles`, `goals`, `statuses`, `operations`, and `resourceMappings` (with optional `techStack` per entry). Use `/configure` as the entry point for editing reality domains in external projects.
+
+**OrganizationModelFeature** -- the TypeScript type (`z.infer<typeof FeatureSchema>`) for a single entry in `OrganizationModel.features`. Replaces the former `OrganizationModelFeatureKey` (closed enum) and `OrganizationModelSemanticDomain`. Each feature has `id`, `label`, `enabled`, and semantic grouping arrays (`entityIds`, `surfaceIds`, `resourceIds`, `capabilityIds`). Exported from `@elevasis/core/organization-model`. Default feature IDs: `crm`, `lead-gen`, `projects`, `operations`, `monitoring`, `settings`, `submitted-requests`, `seo`. Note: feature IDs `crm` and `lead-gen` are unchanged by the domain rename wave; only the domain field names on `OrganizationModel` were renamed (`crm` → `sales`, `leadGen` → `prospecting`).
+
+**Provider / ElevasisFeaturesProvider** -- the runtime that registers manifests, resolves feature access against the org model, dispatches subshell routing via `FeatureShell`, and exposes resolved state through `useElevasisFeatures()`. Mounted in `__root.tsx`. Accepts `features`, optional `organizationModel`, and optional `appShellOverrides`.
+
+**Resolved types (ResolvedFeatureModule, ResolvedShellNavItem)** -- provider output. `ResolvedFeatureModule` extends `FeatureModule` with `access` (enabled state and `featureId`) and `semantics` (merged capability and surface IDs). `ResolvedShellNavItem` extends `FeatureNavEntry` with `placement`, `source`, and `featureId`. Both from `@elevasis/ui`.
+
+**Resource** -- an entry in `OrganizationModel.resourceMappings` linking a deployable automation resource into the semantic model. At the registry layer, resources are `WorkflowDefinition` or `AgentDefinition` instances in a `DeploymentSpec`. Each resource mapping may carry an optional `techStack` extension with `platform`, `purpose`, `credentialStatus`, and `isSystemOfRecord` fields.
+
+**Roles domain** -- role chart with responsibilities, reporting lines, and role holders. Lives at `OrganizationModel.roles`. Each `Role` has `id`, `title`, `responsibilities` (string array), optional `reportsToId` (cross-ref validated within the same collection), and optional `heldBy` (name or email). All field names are plain-language; no EOS jargon (`seats`, `accountabilities`) is used. Edit via `/configure roles`.
+
+**Statuses domain** -- flat registry of all status entries across delivery, queue, execution, schedule, and request semantic classes. Lives at `OrganizationModel.statuses`. Each `StatusEntry` has `id`, `label`, `semanticClass` (closed enum), and optional `category`. Labels are the canonical plain-language strings the ambient vibe layer reads when narrating status -- never hardcoded strings. `QueueTaskStatus` in the queue domain routes through this registry.
+
+**Settings asymmetry** -- `settings` is a valid feature ID (org-level, present in `OrganizationModel.features` with `enabled: true` by default). `MembershipFeatureConfig.features` is now `Record<string, boolean>`, so `settings` can technically be overridden per member, but the convention is still to gate settings visibility via `requiresAdmin` on the nav entry and `AdminGuard` on routes rather than per-member feature overrides.
+
+**Subshell / Sidebar** -- the feature-scoped UI region rendered when the current route matches a manifest's `subshellRoutes`. Each `FeatureModule.sidebar` is a `ComponentType`. Consumers customize by composing the feature's published sidebar primitives (`CrmSidebar`, `CrmSidebarMiddle`, etc.) and assigning their component to `manifest.sidebar`.
+
+**Surface** -- a navigable view in `OrganizationModel.navigation.surfaces`. Identified by a dotted `id` (e.g., `sales.pipeline`). Has `path`, `surfaceType`, optional `featureId` gate (replaces the former `featureKey` field), and cross-reference arrays (`featureIds`, `entityIds`, `resourceIds`, `capabilityIds`). Distinct from "page": a surface is the org-model declaration; a page is the React component rendered at the route.
+
+**Topology** -- resource relationships (`triggers`, `uses`, `approval`) declared in `DeploymentSpec.relationships` and `HumanCheckpointDefinition.routesTo`. Used for Command View graph edges.
+
+---
+
+## Package-Boundary Cheat Sheet
+
+**`@elevasis/core`** (published npm)
+
+- `OrganizationModel`, `OrganizationModelFeature`, `OrganizationModelSurface`, `OrganizationModelResourceMapping`
+- `OrganizationModelIdentity`, `OrganizationModelCustomers`, `OrganizationModelOfferings`, `OrganizationModelRoles`, `OrganizationModelGoals`
+- `OrganizationModelStatuses`, `OrganizationModelOperations`
+- `TechStackEntrySchema`, `OrganizationModelTechStackEntry`
+- `resolveOrganizationModel`, `defineOrganizationModel`, `DEFAULT_ORGANIZATION_MODEL`
+- `MembershipFeatureConfig`
+
+**`@elevasis/ui`** (published npm)
+
+- `FeatureModule`, `FeatureNavEntry`, `FeatureNavLink`
+- `ResolvedFeatureModule`, `ResolvedShellNavItem`
+- `FeatureGuard`, `AdminGuard`, `ProtectedRoute`
+- `ElevasisFeaturesProvider`, `ElevasisCoreProvider`, `useElevasisFeatures`
+- `createFeatureAccessHook`
+
+**`foundations/`** (local source package -- not published)
+
+- `canonicalOrganizationModel` -- passed to `ElevasisFeaturesProvider`
+- `organizationModel` -- enriched shape for app-local code
+- Workflow I/O schemas (`types/index.ts`)

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

@@ -119,7 +119,7 @@ Consumers using a different router can implement `RouterAdapter` directly and pa
 Every page each feature renders is exported from its feature barrel, so consumers can wrap with custom chrome without forking:
 
 - CRM: `DealsListPage`, `DealDetailPage`
-- Lead-gen: `LeadGenOverviewPage`, `LeadGenDeliverabilityPage`, `LeadGenListsPage`, `LeadGenListDetailPage`, `LeadGenCompaniesPage`, `LeadGenContactsPage`
+- Lead-gen: `LeadGenOverviewPage`, `LeadGenListsPage`, `LeadGenListDetailPage`, `LeadGenCompaniesPage`, `LeadGenContactsPage`
 - Delivery: `AllTasksPage`, `UpcomingMilestonesPage`, `ProjectsListPage`, `ProjectDetailPage`
 - Operations, monitoring, settings -- full page inventories exported from their feature barrels
 

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

@@ -240,7 +240,7 @@ The template's `FeatureGuard` (`@/features/auth/guards/FeatureGuard`) is not the
   array. The provider throws at startup if an unknown ID is declared. To add a brand-new feature
   such as `analytics`, first add it to the `features[]` array in `foundations/config/organization-model.ts`.
 
-- **Using `FeatureGuard` on a nav item instead of a route.** `FeatureGuard` is a React component that redirects on mount. Placing it inside a nav item or link will fire a redirect whenever the sidebar renders. Gate nav visibility with `featureKey` on the nav entry or `accessFeatureKey` on the manifest; gate route access with `FeatureGuard` in the route layout.
+- **Using `FeatureGuard` on a nav item instead of a route.** `FeatureGuard` is a React component that redirects on mount. Placing it inside a nav item or link will fire a redirect whenever the sidebar renders. Gate nav visibility with `featureKey` on the nav entry or `featureId` on the manifest; gate route access with `FeatureGuard` in the route layout.
 
 - **Confusing `requiresAdmin` with `AdminGuard`.** `requiresAdmin` on a `FeatureNavEntry` is a display hint read by the shell nav renderer -- it hides the nav item but does not block the route. `AdminGuard` is a React component that actively redirects. You need both if you want the nav hidden and the route blocked.
 

package/reference/claude-config/commands/submit-request.md

@@ -1,11 +0,0 @@
-# Submit Request
-
-**Usage:** `/submit-request [optional one-line description]`
-
-**Goal:** File a structured request report to the Elevasis platform after agent-driven pre-analysis.
-
-**EXECUTE:** `.claude/skills/submit-request/SKILL.md`
-
-## Env Requirements
-
-- `ELEVASIS_PLATFORM_KEY` (same key used by all `elevasis-sdk` commands — no extra setup if deploy already works)