@elevasis/sdk 1.6.0 → 1.8.0

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

@@ -14,7 +14,7 @@ The public entry point exposes:
 - `resolveOrganizationModel`
 - `PROJECTS_FEATURE_ID`
 - `PROJECTS_INDEX_SURFACE_ID`
-- `DELIVERY_PROJECTS_VIEW_CAPABILITY_ID`
+- `PROJECTS_VIEW_CAPABILITY_ID`
 - `OrganizationModel` and the supporting domain types
 
 Import it from the published subpath:
@@ -22,7 +22,7 @@ Import it from the published subpath:
 ```ts
 import {
   DEFAULT_ORGANIZATION_MODEL,
-  DELIVERY_PROJECTS_VIEW_CAPABILITY_ID,
+  PROJECTS_VIEW_CAPABILITY_ID,
   defineOrganizationModel,
   PROJECTS_FEATURE_ID,
   PROJECTS_INDEX_SURFACE_ID,
@@ -41,30 +41,34 @@ Top-level fields:
 - `branding` - organization branding defaults and overrides.
 - `features` - unified feature entries that combine enablement, labels, and semantic references.
 - `navigation` - navigation model for the product shell.
-- `crm` - CRM-specific contract data.
-- `leadGen` - lead generation contract data.
-- `delivery` - delivery and project contract data.
-- `resourceMappings` - cross-surface resource mappings.
+- `sales` - sales pipeline and relationship management.
+- `prospecting` - lists, companies, and contacts.
+- `projects` - projects, milestones, and tasks.
+- `identity`, `customers`, `offerings`, `roles`, `goals` - reality domains (2026-04 expansion).
+- `statuses` - unified status registry across delivery / hitl / execution / request / schedule.
+- `operations` - catalog of stateful runtime entities (HITL queue, sessions, executions, notifications, schedules).
+- `resourceMappings` - cross-surface resource mappings (includes techStack subsection).
 
 ## Default Feature Set
 
-The default model includes seven feature IDs:
+The default model includes eight feature IDs:
 
-- `crm` - deal pipeline and relationship management.
-- `lead-gen` - lists, companies, and contacts.
+- `sales` - deal pipeline and relationship management.
+- `prospecting` - lists, companies, and contacts.
 - `projects` - projects, milestones, and tasks.
 - `operations` - organization graph and command-view surfaces.
 - `monitoring` - monitoring surfaces.
 - `settings` - organization settings.
 - `seo` - SEO surfaces (disabled by default).
+- `configure` - `/configure` skill entry point (external projects).
 
 ## Project Bridge Constants
 
-The organization-model surface now exports a narrow set of canonical IDs for the shared Projects bridge:
+The organization-model surface exports a narrow set of canonical IDs for the shared Projects bridge:
 
 - `PROJECTS_FEATURE_ID` -> `projects`
 - `PROJECTS_INDEX_SURFACE_ID` -> `projects.index`
-- `DELIVERY_PROJECTS_VIEW_CAPABILITY_ID` -> `delivery.projects.view`
+- `PROJECTS_VIEW_CAPABILITY_ID` -> `delivery.projects.view`
 
 Use these when wiring shared UI manifests, template adapters, or other consumers that need to agree on the same Projects contract without repeating raw literals.
 
@@ -89,5 +93,5 @@ Use these when wiring shared UI manifests, template adapters, or other consumers
 
 - Use `resolveOrganizationModel()` when you need a runtime-safe model for rendering or policy checks.
 - Use `defineOrganizationModel()` when authoring a static partial model in source.
-- Treat feature IDs such as `crm`, `lead-gen`, and `projects` as the canonical shell-level contract in new organization-model authoring.
+- Treat feature IDs such as `sales`, `prospecting`, and `projects` as the canonical shell-level contract in new organization-model authoring.
 - Keep feature IDs, surface IDs, and capability IDs stable because downstream UI and policy code depend on them.

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

@@ -8,7 +8,7 @@ The hooks barrel is the published headless hook surface for the UI package.
 - Scheduling hooks
 - Monitoring, observability, and notification hooks
 - Session and SSE hooks
-- Operations hooks, including command-view and knowledge-base helpers
+- Operations hooks, including command-view helpers
 - Feature access, table state, and service helpers
 - Acquisition and delivery hooks
 
@@ -21,4 +21,3 @@ The hooks barrel is the published headless hook surface for the UI package.
 ## Notes
 
 - This barrel is intentionally headless. It should not pull in the visual component layer.
-

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

@@ -62,6 +62,7 @@ This means runtime topology is represented as bridged `resource` nodes plus rela
 - Implementation-resource bridging prefers `organizationModel.resourceMappings`.
 - Semantic grouping now comes from the unified `organizationModel.features` array. The builder no longer emits separate `domain` nodes.
 - Command View resource `domains` metadata is currently bridged onto `feature` references, not onto a distinct domain-node layer.
+- The 2026-04-20 reality-domain expansion (identity, customers, offerings, roles, goals, statuses, operations, techStack) does not introduce new graph node kinds. Those domains are model-layer data; they are not independently represented as graph nodes. They can be surfaced as metadata on the organization root node when a consumer needs to expose them through a graph lens.
 - Graph defaults remain valid when produced by `resolveOrganizationModel()`.
 - If the graph needs a concept the model cannot express, extend the model first.
 

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

@@ -5,7 +5,7 @@ description: Organization OS Model layer documentation for the semantic organiza
 
 ## Overview
 
-Within Organization OS, the organization model is the **Model** layer and part of the cross-cutting **Public API** layer. It is the semantic contract that maps an organization's product shape to domains, features, navigation surfaces and groups, domain-specific semantics (CRM pipeline, lead-gen lifecycle, delivery status), and resource mappings. It is schema-first, versioned, and validated.
+Within Organization OS, the organization model is the **Model** layer and part of the cross-cutting **Public API** layer. It is the semantic contract that maps an organization's full organizational reality to domains, features, navigation surfaces and groups, domain-specific semantics (sales pipeline, prospecting lifecycle, projects status), and resource mappings. It is schema-first, versioned, and validated.
 
 The model is authored in `@repo/core` and published as a curated external package `@elevasis/core`. It is consumed by:
 
@@ -21,7 +21,7 @@ The model does **not** replace the shared feature-provider system. It enriches a
 - `packages/core/src/organization-model/types.ts` -- exported TypeScript types
 - `packages/core/src/organization-model/defaults.ts` -- `DEFAULT_ORGANIZATION_MODEL`
 - `packages/core/src/organization-model/resolve.ts` -- `defineOrganizationModel`, `resolveOrganizationModel`
-- `packages/core/src/organization-model/domains/*.ts` -- feature schema, navigation surfaces, CRM/lead-gen/delivery semantics
+- `packages/core/src/organization-model/domains/*.ts` -- feature schema, navigation surfaces, sales/prospecting/projects semantics, and the 8 reality domains (identity, customers, offerings, roles, goals, statuses, operations, shared/techStack)
 - `packages/core/src/published.ts` -- curated root barrel for the published package
 - `packages/core/src/organization-model/published.ts` -- curated organization-model barrel
 - `packages/core/src/__tests__/template-foundations-compatibility.test.ts` -- adapter-baseline guard
@@ -32,12 +32,31 @@ Top-level fields on `OrganizationModel`:
 
 - `version`
 - `features` -- unified feature array (`OrganizationModelFeature[]`); each entry combines access gating, semantic grouping, and display metadata
-- `branding`
+- `branding` -- display identity (org name, product name, logos)
 - `navigation` -- surfaces, groups, `defaultSurfaceId`
-- `crm` -- pipeline stages and stage semantics
-- `leadGen` -- company/contact lifecycle stages
-- `delivery` -- project/milestone/task statuses
-- `resourceMappings`
+- `sales` -- pipeline stages and stage semantics (formerly `crm`)
+- `prospecting` -- company/contact lifecycle stages (formerly `leadGen`)
+- `projects` -- project/milestone/task statuses (formerly `delivery`)
+- `identity` -- legal identity, mission/vision, industry, geography, and temporal anchors
+- `customers` -- customer segments with jobs-to-be-done, firmographics, and value propositions
+- `offerings` -- products and services with pricing model and segment/feature references
+- `roles` -- role chart with responsibilities, reporting lines, and role holders
+- `goals` -- organizational goals with period and measurable outcomes
+- `statuses` -- flat registry of all status entries across delivery, queue, execution, schedule, and request semantic classes
+- `operations` -- catalog of stateful runtime entities (HITL queue, executions, sessions, notifications, schedules)
+- `resourceMappings` -- deployable resource links, each optionally extended with `techStack` metadata
+
+### Domain Rename Wave
+
+Three legacy domain names were renamed in the 2026-04-20 expansion to align developer-facing code with user-visible labels:
+
+| Old name   | New name      | Notes                                                                                |
+| ---------- | ------------- | ------------------------------------------------------------------------------------ |
+| `crm`      | `sales`       | Domain files, feature IDs, surface IDs, imports, and sidebar labels all updated      |
+| `leadGen`  | `prospecting` | Same scope as above                                                                  |
+| `delivery` | `projects`    | Aligns with the "Projects" sidebar label; `projects` feature ID was already in place |
+
+Any reference to `crm`, `leadGen`, or `delivery` in domain files, imports, or surface IDs should be treated as a historical artifact unless explicitly annotated otherwise.
 
 ### Branding Shape
 
@@ -56,22 +75,25 @@ All `id` fields, `parentId`, `defaultSurfaceId`, and reference ID arrays use `Mo
 - Regex: `/^[a-z0-9]+(?:[-._][a-z0-9]+)*$/`
 - Max length: 100 chars
 - Allowed separators: `-`, `_`, `.`
-- Examples: `crm.pipeline`, `lead-gen.lists`, `operations.organization-graph`
+- Examples: `sales.pipeline`, `prospecting.lists`, `operations.organization-graph`
 
 This applies to domain IDs, surface IDs, navigation group IDs, and resource mapping IDs.
 
 ### Default Features
 
-Seven features ship by default in `DEFAULT_ORGANIZATION_MODEL.features`:
+Eight features ship by default in `DEFAULT_ORGANIZATION_MODEL.features`:
 
-- `crm` -- enabled; CRM pipeline and deal management
-- `lead-gen` -- enabled; prospecting, qualification, and outreach
-- `projects` -- enabled; projects, milestones, and client work execution (formerly `delivery`)
+- `crm` -- enabled; sales pipeline and deal management (feature ID unchanged; domain renamed to `sales`)
+- `lead-gen` -- enabled; prospecting, qualification, and outreach (feature ID unchanged; domain renamed to `prospecting`)
+- `projects` -- enabled; projects, milestones, and client work execution
 - `operations` -- enabled; organizational topology and orchestration visibility
 - `monitoring` -- enabled; execution monitoring
 - `settings` -- enabled; organization settings
+- `submitted-requests` -- enabled; submitted-request lifecycle surface
 - `seo` -- disabled by default; SEO surface
 
+Note: the feature IDs (`crm`, `lead-gen`) are consumer-facing identifiers that have not changed. The underlying domain key on `OrganizationModel` was renamed (`crm` → `sales`, `leadGen` → `prospecting`). Adapters that already use the feature ID constants (`CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`) require no change.
+
 Each feature entry (`OrganizationModelFeature`) combines what were previously three separate concepts: an access/gating key (the former `OrganizationModelFeatureKey`), a semantic domain (the former `SemanticDomainSchema` entry), and display metadata. The `features` field is now `z.array(FeatureSchema)` -- there is no separate `domains` array and no separate `enabled`/`labels` map.
 
 `FeatureModule.featureId` on the UI side maps directly to one of these IDs. No alias layer is needed. See [Feature Shell](../ui/feature-shell.mdx) for how the provider resolves feature access from this array.
@@ -88,18 +110,30 @@ Each feature entry (`OrganizationModelFeature`) combines what were previously th
 - `entityIds` -- entities this resource operates on
 - `surfaceIds` -- surfaces this resource is exposed in
 - `capabilityIds` -- capabilities this resource fulfills
+- `techStack` (optional) -- external-SaaS integration metadata; see TechStack Extension below
 
 All four ID arrays are bidirectionally validated against their counterparts (see Referential Integrity).
 
+### TechStack Extension
+
+`techStack` is an optional nested object on `ResourceMappingSchema` defined in `domains/shared.ts`. It captures external-SaaS integration metadata without introducing a tenth top-level domain. Fields:
+
+- `platform` -- name of the external platform (e.g. "HubSpot", "Stripe", "Notion")
+- `purpose` -- free-form description of what this integration does
+- `credentialStatus` -- one of `'configured' | 'pending' | 'expired' | 'missing'`
+- `isSystemOfRecord` -- boolean; whether this integration is the primary source of truth for its domain (defaults to `false`)
+
+Backward-compatible: existing resource mappings without `techStack` parse cleanly. The extension flows through `ResourceMappingSchema` automatically with no changes to `schema.ts` composition.
+
 ### Default Navigation
 
-Surfaces such as `crm.pipeline`, `lead-gen.lists`, `projects.index`, `operations.organization-graph`, and `operations.command-view`. Groups include `primary-workspace` and `primary-operations`. The model can shape shell meaning even when route files stay app-local.
+Surfaces such as `sales.pipeline`, `prospecting.lists`, `projects.index`, `operations.organization-graph`, and `operations.command-view`. Groups include `primary-workspace` and `primary-operations`. The model can shape shell meaning even when route files stay app-local.
 
 ### SurfaceDefinition Shape
 
 `OrganizationModelSurface` (inferred from `SurfaceDefinitionSchema`) defines a navigable view:
 
-- `id` -- ModelId (e.g. `crm.pipeline`)
+- `id` -- ModelId (e.g. `sales.pipeline`)
 - `label` -- display name
 - `path` -- route path, must start with `/`, max 300 chars
 - `surfaceType` -- `'page' | 'dashboard' | 'graph' | 'detail' | 'list' | 'settings'`
@@ -124,14 +158,36 @@ The default groups (`primary-workspace`, `primary-operations`) both use `placeme
 
 ### Feature-Specific Semantics
 
-The top-level `crm`, `leadGen`, and `delivery` fields on `OrganizationModel` remain as named fields (not moved into per-feature config) and carry domain-specific semantic shapes:
+Three renamed top-level domain fields carry feature-specific semantic shapes (pipeline stages, lifecycle stages, project statuses). These are named fields on `OrganizationModel`, not embedded in per-feature config:
 
-- `crm` -- pipeline stages and stage semantics
-- `leadGen` -- company and contact lifecycle stages
-- `delivery` -- project, milestone, and task statuses (used by the `projects` feature)
+- `sales` -- pipeline stages and stage semantics (formerly `crm`)
+- `prospecting` -- company and contact lifecycle stages (formerly `leadGen`)
+- `projects` -- project, milestone, and task statuses (formerly `delivery`)
 
 This is why the organization model is semantic, not just nav config -- it owns product meaning for the business objects the shell surfaces expose.
 
+### Reality Domains (New in 2026-04-20 Expansion)
+
+Five new domains capture organizational reality that was absent from the original model. They sit alongside the existing platform-configuration domains and follow the same `domains/*.ts` pattern:
+
+**`identity`** -- legal identity distinct from `branding` (which is display identity). Fields: `mission`, `vision`, `legalName`, `entityType`, `jurisdiction`, `industryCategory`, `geographicFocus`, `timeZone`, `businessHours`. All fields default to empty strings; `timeZone` defaults to `'UTC'`; `businessHours` defaults to `{}`.
+
+**`customers`** -- customer segments. Each `CustomerSegment` entry has: `id`, `name`, `description`, `jobsToBeDone`, `pains`, `gains`, `valueProp` (all plain-language strings), and `firmographics` (optional object with `companySize`, `industry`, `revenue`, `geography`). Domain defaults to `{ segments: [] }`.
+
+**`offerings`** -- products and services. Each `Product` entry has: `id`, `name`, `description`, `pricingModel` (enum: `'one-time' | 'subscription' | 'usage-based' | 'custom'`), `price` (optional number), `currency` (optional string), `targetSegmentIds` (cross-ref validated against `customers.segments[].id`), `deliveryFeatureId` (optional cross-ref validated against `features[].id`). Domain defaults to `{ products: [] }`.
+
+**`roles`** -- role chart. Each `Role` entry has: `id`, `title`, `responsibilities` (string array, default `[]`), `reportsToId` (optional, cross-ref validated within the same collection), `heldBy` (optional name or email string). All field names are plain-language; no EOS jargon (`seats`, `accountabilities`) survives. Domain defaults to `{ roles: [] }`.
+
+**`goals`** -- organizational goals. Each `Objective` entry has: `id`, `description`, `periodStart` (ISO 8601 date), `periodEnd` (ISO 8601 date, must be strictly after `periodStart`), `keyResults` (array of `{ id, description, targetValue?, currentValue?, unit? }`). User-facing text uses "goals" and "measurable outcomes" -- never "OKR" or "key results". Domain defaults to `{ objectives: [] }`.
+
+### Statuses and Operations Domains (Vibe Layer)
+
+Two domains support the ambient vibe layer's plain-language rendering:
+
+**`statuses`** -- flat registry of `StatusEntry` objects. Each entry: `id`, `label`, `semanticClass` (one of `'delivery.task' | 'delivery.project' | 'delivery.milestone' | 'queue' | 'execution' | 'schedule' | 'schedule.run' | 'request'`), optional `category`. Labels are vibe-readable: the ambient classifier narrates state using `label` from the model, never hardcoded strings. `QueueTaskStatus` in the queue domain routes through this registry. Defaults to a seed set covering all semantic classes.
+
+**`operations`** -- catalog of stateful runtime entities. Each `OperationEntry`: `id`, `label`, `semanticClass` (one of `'queue' | 'executions' | 'sessions' | 'notifications' | 'schedules'`), optional `featureId`, optional `supportedStatusSemanticClass` (ties an operation entry back to which status semantic classes apply). Default entries: `operations.queue` (HITL queue), `operations.executions`, `operations.sessions`, `operations.notifications`, `operations.schedules`.
+
 ## Authoring & Resolution
 
 - `defineOrganizationModel()` -- typed authoring helper; returns the input unchanged but constrains the type.
@@ -179,6 +235,13 @@ Merge semantics:
 
 This bidirectional enforcement is what keeps the organization model semantically consistent rather than loosely structured config.
 
+**Reality domain cross-refs** (validated in the same `superRefine` pass):
+
+- each `offerings.products[].targetSegmentIds[]` must resolve to a `customers.segments[].id`
+- each `offerings.products[].deliveryFeatureId` (when present) must resolve to a `features[].id`
+- each `roles.roles[].reportsToId` (when present) must resolve to another `roles.roles[].id` in the same collection
+- each `goals.objectives[].periodEnd` must be strictly after `periodStart` (ISO 8601 string comparison)
+
 ## Provider Integration
 
 `ElevasisFeaturesProvider` uses the organization model in three ways:
@@ -236,7 +299,9 @@ Exports the foundations module provides to consumers:
 - `FoundationFeatureKey`, `FoundationSurfaceIcon`, `FoundationNavigationSurface`, `FoundationOrganizationModel`
 - `homeLabel`, `quickAccessSurfaceIds`, `getOrganizationSurface(surfaceId)`
 
-Downstream template shells pass `canonicalOrganizationModel` into `ElevasisFeaturesProvider`, preserving host-local dashboard/nav customizations alongside the shared runtime. Feature IDs are now direct matches -- `crm`, `lead-gen`, `projects` in the org model correspond directly to the same IDs on `FeatureModule.featureId`. No alias layer is needed.
+Downstream template shells pass `canonicalOrganizationModel` into `ElevasisFeaturesProvider`, preserving host-local dashboard/nav customizations alongside the shared runtime. Feature IDs are direct matches -- `crm`, `lead-gen`, `projects` in the org model correspond directly to the same IDs on `FeatureModule.featureId`. No alias layer is needed. The domain rename wave (crm→sales, leadGen→prospecting, delivery→projects) affects the schema field names, not the feature ID constants; adapters using `CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`, etc. require no changes.
+
+Adapters that override the new reality domains (`identity`, `customers`, `offerings`, `roles`, `goals`) or add `techStack` metadata to resource mappings should use `/configure` as the structured entry point for those edits in external projects. `/configure` runs a layered QA flow, proposes changes, and gates the write through `resolveOrganizationModel()` + `OrganizationModelSchema.parse()` before committing.
 
 Derivative projects (`external/nirvana-marketing`, `external/ZentaraHQ`) follow the same adapter + provider-wiring baseline with their own project-local customizations.
 

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

@@ -30,11 +30,11 @@ Layer 3: Sync Verification (pnpm sync:verify)
 
 `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/*/manifest.ts`, `packages/core/src/organization-model/domains/features.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`, `external/_template/docs/platform-navigation-map.md` |
+| 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/*/manifest.ts`, `packages/core/src/organization-model/domains/features.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.
 
@@ -55,11 +55,11 @@ Drift is healed at the moment it would otherwise leak downstream. This is cheape
 
 `/external sync` propagates the `external/_template` to downstream projects. It uses a three-tier model:
 
-| Tier                           | Policy                                    | Examples                                                            |
-| ------------------------------ | ----------------------------------------- | ------------------------------------------------------------------- |
+| Tier                           | Policy                                    | Examples                                                              |
+| ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------- |
 | **Tier 1 (Infrastructure)**    | Always replaced from template             | Configs, shared runtime surfaces, `lib/`, `test-utils/`, entry points |
-| **Tier 2 (Standard Features)** | Synced unless project has customized them | Standard UI features, common patterns                               |
-| **Tier 3 (Project-Specific)**  | Never touched                             | `nav-items.ts`, `operations/src/`, `docs/`, `CLAUDE.md`             |
+| **Tier 2 (Standard Features)** | Synced unless project has customized them | Standard UI features, common patterns                                 |
+| **Tier 3 (Project-Specific)**  | Never touched                             | `nav-items.ts`, `operations/src/`, `docs/`, `CLAUDE.md`               |
 
 The sync skill doc (`.claude/skills/external/SKILL.md`) defines the full tier model and phase sequence.
 
@@ -78,8 +78,7 @@ The sync skill doc (`.claude/skills/external/SKILL.md`) defines the full tier mo
 | `org-os`       | Organization model exists, exports canonical symbols, imports from `@elevasis/core/organization-model`, calls `defineOrganizationModel` + `resolveOrganizationModel`, app-config references org model, `__root.tsx` uses `ElevasisFeaturesProvider` + `canonicalOrganizationModel`, `main.tsx` uses `ElevasisUIProvider`, all 3 CSS subpath imports present |
 | `placeholders` | No unresolved `__PROJECT_SLUG__`, `__PROJECT_NAME__`, `__PROJECT_DESCRIPTION__` in key config files                                                                                                                                                                                                                                                         |
 | `scripts`      | `ui` and `operations` `package.json` have required npm scripts                                                                                                                                                                                                                                                                                              |
-| `generated-docs` | `docs/index.md` and `docs/resources.md` are current with `pnpm exec elevasis-sdk generate-docs` and `pnpm exec elevasis-sdk generate-resources`; `pnpm exec elevasis-sdk validate-docs` passes                                                                                                                                                                                                            |
-| `lib`          | `ui/src/lib/`, `lib/`, `test-utils/` exist with minimum file counts                                                                                                                                                                                                                                                                                      |
+| `lib`          | `ui/src/lib/`, `lib/`, `test-utils/` exist with minimum file counts                                                                                                                                                                                                                                                                                         |
 | `tier3`        | `nav-items.ts` has project-specific customization (not overwritten by template)                                                                                                                                                                                                                                                                             |
 | `conflicts`    | No merge conflict markers in source files                                                                                                                                                                                                                                                                                                                   |
 | `git`          | Working tree is clean                                                                                                                                                                                                                                                                                                                                       |

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

@@ -71,7 +71,6 @@ Generated by `scripts/monorepo/generate-reference-artifacts.js`:
 
 - `packages/sdk/reference/_reference-manifest.json` -- machine-readable catalog of all reference entries
 - `packages/sdk/reference/_navigation.md` -- navigation table
-- `external/_template/docs/platform-navigation-map.md` -- cross-package reference map for external projects
 
 ### Running Generators
 
@@ -120,6 +119,4 @@ The output lands in `packages/sdk/reference/` which is included in the npm packa
 
 ## Freshness Validation
 
-External projects validate generated docs with `pnpm check:autogenerated-docs`, which now calls `pnpm exec elevasis-sdk validate-docs`. The legacy `scripts/validate-autogenerated-docs.mjs` file may still exist as a temporary compatibility shim in the template, but the SDK CLI is the canonical path.
-
-At the monorepo level, `pnpm scaffold:sync` followed by `pnpm sync:verify` confirms that all artifacts are current and all downstream projects are consistent.
+At the monorepo level, `pnpm scaffold:sync` followed by `pnpm sync:verify` confirms that all artifacts are current and all downstream projects are consistent. The SDK no longer ships doc validation because external projects no longer carry a `docs/` tree.

package/reference/scaffold/recipes/add-a-feature.md

@@ -34,7 +34,7 @@ Add a new feature object to the `features[]` array passed to `defineOrganization
 import { defineOrganizationModel } from '@elevasis/core/organization-model'
 ```
 
-Use typed constants for the 7 platform features (`CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`, `PROJECTS_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, `MONITORING_FEATURE_ID`, `SETTINGS_FEATURE_ID`, `SEO_FEATURE_ID`); use string literals for project-specific features you invent.
+Use typed constants for the 7 platform features (`SALES_FEATURE_ID`, `PROSPECTING_FEATURE_ID`, `PROJECTS_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, `MONITORING_FEATURE_ID`, `SETTINGS_FEATURE_ID`, `SEO_FEATURE_ID`); use string literals for project-specific features you invent.
 
 ```ts
 const foundationOrganizationModelOverride = defineOrganizationModel({

package/reference/scaffold/recipes/add-a-resource.md

@@ -109,7 +109,7 @@ const org: DeploymentSpec = {
 }
 ```
 
-Full relationship and checkpoint types are defined in `@elevasis/sdk` (`DeploymentSpec`). The generated `docs/resources.md` topology map will reflect these in the Topology Relationships, Triggers, and Human Checkpoints sections after regeneration.
+Full relationship and checkpoint types are defined in `@elevasis/sdk` (`DeploymentSpec`). Resources are discovered live via `pnpm elevasis-sdk project:list` or by globbing `operations/resources/**` directly.
 
 ---
 
@@ -133,18 +133,9 @@ See `OrganizationModelResourceMapping` in [contracts.md](../reference/contracts.
 
 ---
 
-## 5. Regenerate the topology map
+## 5. Verify resource inventory
 
-```bash
-pnpm exec elevasis-sdk generate-resources
-```
-
-Open `docs/resources.md` and confirm:
-
-- Section 1 (Workflows table) lists the new resource with correct `resourceId`, `version`, and `status`.
-- Section 2 (Topology Relationships) shows any declared `relationships` edges.
-- Sections 3-6 (Triggers, Integrations, Human Checkpoints, External Resources) show any relevant declarations.
-- Section 7 (Schema Signatures) includes the new resource's input/output field list.
+Resources are discovered live via `pnpm elevasis-sdk project:list` or by globbing `operations/resources/**` directly. Confirm the new resource appears with the correct `resourceId`, `version`, and `status`.
 
 ---
 

package/reference/scaffold/recipes/customize-organization-model.md

@@ -163,12 +163,12 @@ for the full resource authoring workflow.
 
 ### Domain-specific config
 
-The `crm`, `leadGen`, and `delivery` top-level keys configure pipeline stages, entity ID bindings,
+The `sales`, `prospecting`, and `projects` top-level keys configure pipeline stages, entity ID bindings,
 and status vocabularies for those domains. These are consumed by the platform adapters and UI
 components -- they are not just labels.
 
 ```ts
-crm: {
+sales: {
   entityId: 'crm.deal',
   defaultPipelineId: 'default',
   pipelines: [
@@ -184,7 +184,7 @@ crm: {
     }
   ]
 },
-leadGen: {
+prospecting: {
   listEntityId: 'leadgen.list',
   companyEntityId: 'leadgen.company',
   contactEntityId: 'leadgen.contact',
@@ -197,7 +197,7 @@ leadGen: {
     { id: 'uploaded', label: 'Uploaded', order: 4 }
   ]
 },
-delivery: {
+projects: {
   projectEntityId: 'delivery.project',
   milestoneEntityId: 'delivery.milestone',
   taskEntityId: 'delivery.task',
@@ -207,7 +207,7 @@ delivery: {
 }
 ```
 
-`semanticClass` on CRM stages is significant: the platform uses `closed_won`, `closed_lost`,
+`semanticClass` on sales pipeline stages is significant: the platform uses `closed_won`, `closed_lost`,
 `nurturing`, `open`, and `active` for funnel analytics and workflow triggers. Do not rename these
 to arbitrary strings.
 

package/reference/scaffold/recipes/gate-by-feature-or-admin.md

@@ -30,7 +30,7 @@ Do not substitute one for the other. `FeatureGuard` reads feature flags; `AdminG
 Ensure a feature object with the matching `id` exists in the org model. File: `foundations/config/organization-model.ts`.
 
 ```ts
-import { defineOrganizationModel, OPERATIONS_FEATURE_ID, CRM_FEATURE_ID } from '@elevasis/core/organization-model'
+import { defineOrganizationModel, OPERATIONS_FEATURE_ID, SALES_FEATURE_ID } from '@elevasis/core/organization-model'
 
 // In the features[] array inside defineOrganizationModel:
 features: [
@@ -39,7 +39,7 @@ features: [
 ]
 ```
 
-Use typed constants for the 7 platform features (`CRM_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, etc.); use string literals for project-specific features you invent. In this example, `'analytics'` is a project-local feature and stays as a string literal.
+Use typed constants for the 7 platform features (`SALES_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, etc.); use string literals for project-specific features you invent. In this example, `'analytics'` is a project-local feature and stays as a string literal.
 
 See [add-a-feature.md](add-a-feature.md) step 2 for the full feature object shape.
 
@@ -119,7 +119,7 @@ navEntry: {
 { label: 'Admin',     icon: IconShield,   link: '/admin',     requiresAdmin: true }
 ```
 
-`featureKey` on a nav entry is a display hint only -- it does not protect the route. Always pair with a route-level `FeatureGuard`. See [glossary.md](../reference/glossary.md) under **accessFeatureKey vs featureKey** for the distinction. When the `featureKey` is one of the 7 platform features, prefer the typed constant (e.g., `featureKey: CRM_FEATURE_ID`) over a string literal to catch renames at compile time.
+`featureKey` on a nav entry is a display hint only -- it does not protect the route. Always pair with a route-level `FeatureGuard`. See [glossary.md](../reference/glossary.md) under **accessFeatureKey vs featureKey** for the distinction. When the `featureKey` is one of the 7 platform features, prefer the typed constant (e.g., `featureKey: SALES_FEATURE_ID`) over a string literal to catch renames at compile time.
 
 ---
 

package/reference/scaffold/reference/contracts.md

@@ -1,4 +1,4 @@
-<!-- Auto-generated on 2026-04-20T07:18:04.491Z by scripts/monorepo/generate-scaffold-contracts.js -->
+<!-- Auto-generated on 2026-04-21T05:52:18.229Z by scripts/monorepo/generate-scaffold-contracts.js -->
 ---
 title: Reference Contracts
 description: Auto-generated TypeScript contracts for SDK consumers. Do not edit manually.
@@ -20,22 +20,22 @@ export type OrganizationModel = z.infer<typeof OrganizationModelSchema>
 export type OrganizationModelBranding = z.infer<typeof OrganizationModelBrandingSchema>
 ```
 
-### `OrganizationModelCrm`
+### `OrganizationModelSales`
 
 ```typescript
-export type OrganizationModelCrm = z.infer<typeof OrganizationModelCrmSchema>
+export type OrganizationModelSales = z.infer<typeof OrganizationModelSalesSchema>
 ```
 
-### `OrganizationModelLeadGen`
+### `OrganizationModelProspecting`
 
 ```typescript
-export type OrganizationModelLeadGen = z.infer<typeof OrganizationModelLeadGenSchema>
+export type OrganizationModelProspecting = z.infer<typeof OrganizationModelProspectingSchema>
 ```
 
-### `OrganizationModelDelivery`
+### `OrganizationModelProjects`
 
 ```typescript
-export type OrganizationModelDelivery = z.infer<typeof OrganizationModelDeliverySchema>
+export type OrganizationModelProjects = z.infer<typeof OrganizationModelProjectsSchema>
 ```
 
 ### `OrganizationModelFeature`
@@ -62,6 +62,114 @@ export type OrganizationModelSurface = z.infer<typeof SurfaceDefinitionSchema>
 export type OrganizationModelResourceMapping = z.infer<typeof ResourceMappingSchema>
 ```
 
+### `OrganizationModelTechStackEntry`
+
+```typescript
+export type OrganizationModelTechStackEntry = z.infer<typeof TechStackEntrySchema>
+```
+
+### `OrganizationModelStatuses`
+
+```typescript
+export type OrganizationModelStatuses = z.infer<typeof StatusesDomainSchema>
+```
+
+### `OrganizationModelStatusEntry`
+
+```typescript
+export type OrganizationModelStatusEntry = z.infer<typeof StatusEntrySchema>
+```
+
+### `OrganizationModelStatusSemanticClass`
+
+```typescript
+export type OrganizationModelStatusSemanticClass = z.infer<typeof StatusSemanticClassSchema>
+```
+
+### `OrganizationModelOperations`
+
+```typescript
+export type OrganizationModelOperations = z.infer<typeof OperationsDomainSchema>
+```
+
+### `OrganizationModelOperationEntry`
+
+```typescript
+export type OrganizationModelOperationEntry = z.infer<typeof OperationEntrySchema>
+```
+
+### `OrganizationModelOperationSemanticClass`
+
+```typescript
+export type OrganizationModelOperationSemanticClass = z.infer<typeof OperationSemanticClassSchema>
+```
+
+### `OrganizationModelCustomers`
+
+```typescript
+export type OrganizationModelCustomers = z.infer<typeof CustomersDomainSchema>
+```
+
+### `OrganizationModelCustomerSegment`
+
+```typescript
+export type OrganizationModelCustomerSegment = z.infer<typeof CustomerSegmentSchema>
+```
+
+### `OrganizationModelCustomerFirmographics`
+
+```typescript
+export type OrganizationModelCustomerFirmographics = z.infer<typeof FirmographicsSchema>
+```
+
+### `OrganizationModelOfferings`
+
+```typescript
+export type OrganizationModelOfferings = z.infer<typeof OfferingsDomainSchema>
+```
+
+### `OrganizationModelProduct`
+
+```typescript
+export type OrganizationModelProduct = z.infer<typeof ProductSchema>
+```
+
+### `OrganizationModelPricingModel`
+
+```typescript
+export type OrganizationModelPricingModel = z.infer<typeof PricingModelSchema>
+```
+
+### `OrganizationModelRoles`
+
+```typescript
+export type OrganizationModelRoles = z.infer<typeof RolesDomainSchema>
+```
+
+### `OrganizationModelRole`
+
+```typescript
+export type OrganizationModelRole = z.infer<typeof RoleSchema>
+```
+
+### `OrganizationModelGoals`
+
+```typescript
+export type OrganizationModelGoals = z.infer<typeof GoalsDomainSchema>
+```
+
+### `OrganizationModelObjective`
+
+```typescript
+export type OrganizationModelObjective = z.infer<typeof ObjectiveSchema>
+```
+
+### `OrganizationModelKeyResult`
+
+```typescript
+export type OrganizationModelKeyResult = z.infer<typeof KeyResultSchema>
+```
+
 ### `DeepPartial`
 
 ```typescript