@elevasis/sdk 1.5.5 → 1.7.0

package/reference/claude-config/skills/{submit-issue → submit-request}/SKILL.md

@@ -1,13 +1,13 @@
 ---
-name: submit-issue
-description: Submit a structured issue report to the Elevasis platform via CLI — enforces pre-analysis before posting
+name: submit-request
+description: Submit a structured request report to the Elevasis platform via CLI — enforces pre-analysis before posting
 ---
 
-# Submit Issue
+# Submit Request
 
-Submit a structured issue report to the Elevasis platform. The agent performs a six-phase analysis before posting so that every submitted issue includes meaningful context, not just a one-liner.
+Submit a structured request report to the Elevasis platform. The agent performs a six-phase analysis before posting so that every submitted request includes meaningful context, not just a one-liner.
 
-**Usage:** `/submit-issue [optional description]`
+**Usage:** `/submit-request [optional description]`
 
 If a description is provided, it is the primary signal for Phase 1. Otherwise the agent analyzes recent conversation context plus any active error context.
 
@@ -31,7 +31,7 @@ Gather available context:
 
 ### Phase 2: Identify Source
 
-Pinpoint where the issue originates:
+Pinpoint where the request originates:
 
 - File paths (if a code or config file is involved)
 - Workflow or agent resource IDs (if a platform execution failed)
@@ -42,18 +42,27 @@ Record these for the `evidence` and `affected_page` fields.
 
 ### Phase 3: Gather Errors
 
-Extract concrete error signals:
+Extract concrete error signals (if applicable):
 
 - Full error messages and stack traces (truncated to the relevant portion)
 - HTTP status codes and response bodies
 - Log lines with timestamps if available
 - Screenshots or screenshot file references if the user provided them
 
-These go into the `evidence` object.
+These go into the `evidence` object. For feature requests or questions, this phase may produce an empty `evidence` object — that is expected.
 
-### Phase 4: Classify Severity and Category
+### Phase 4: Select Type and Classify Severity and Category
 
-Select exactly one value for each:
+Select exactly one value for **type first**, then **severity**, then **category**:
+
+**Type:**
+
+| Value      | When to use                                        |
+| ---------- | -------------------------------------------------- |
+| `bug`      | Something is broken or behaving incorrectly        |
+| `feature`  | A new capability or enhancement request            |
+| `question` | Asking for clarification, guidance, or explanation |
+| `other`    | Doesn't fit the above                              |
 
 **Severity:**
 
@@ -65,14 +74,18 @@ Select exactly one value for each:
 
 **Category:**
 
-| Value                | When to use                                            |
-| -------------------- | ------------------------------------------------------ |
-| `ui_bug`             | Frontend rendering or interaction problem              |
-| `data_inconsistency` | DB records, API responses, or UI state don't match     |
-| `performance`        | Slow load, timeout, high resource usage                |
-| `error_pattern`      | Recurring or systematic error across executions        |
-| `configuration`      | Misconfigured resource, credential, env var, or policy |
-| `other`              | Doesn't fit above                                      |
+| Value                 | When to use                                            |
+| --------------------- | ------------------------------------------------------ |
+| `ui_bug`              | Frontend rendering or interaction problem              |
+| `data_inconsistency`  | DB records, API responses, or UI state don't match     |
+| `performance`         | Slow load, timeout, high resource usage                |
+| `error_pattern`       | Recurring or systematic error across executions        |
+| `configuration`       | Misconfigured resource, credential, env var, or policy |
+| `feature_request`     | New feature or enhancement being requested             |
+| `api_design`          | Feedback on API contract, naming, or behavior          |
+| `documentation`       | Missing, incorrect, or unclear documentation           |
+| `integration_request` | Request for a new integration or adapter               |
+| `other`               | Doesn't fit above                                      |
 
 ### Phase 5: Build Structured Report
 
@@ -82,6 +95,7 @@ Assemble the report body from phases 1–4:
 {
   "title": "One-line summary — specific, not vague",
   "description": "What happened. What was expected. Steps to reproduce if applicable.",
+  "type": "<bug|feature|question|other>",
   "severity": "<critical|warning|info>",
   "category": "<category value>",
   "affected_page": "<route or page path, omit if not a UI issue>",
@@ -99,7 +113,7 @@ Assemble the report body from phases 1–4:
 }
 ```
 
-Omit any field that has nothing meaningful to record. `project_id` and `task_id` are optional UUID fields — include them only if the issue is clearly scoped to a specific project or task visible in context.
+Omit any field that has nothing meaningful to record. `project_id` and `task_id` are optional UUID fields — include them only if the request is clearly scoped to a specific project or task visible in context.
 
 Do NOT include `source` or `organization_id` — the server sets both automatically.
 
@@ -108,9 +122,10 @@ Do NOT include `source` or `organization_id` — the server sets both automatica
 Unless the command was invoked with `--auto`, present the assembled report to the user before submitting:
 
 ```
-Issue Report (ready to submit)
+Request Report (ready to submit)
 ================================
 Title:    <title>
+Type:     <type>
 Severity: <severity>
 Category: <category>
 Page:     <affected_page or "—">
@@ -137,20 +152,20 @@ Once confirmed (or `--auto`), write the assembled JSON body to a temp file then
 
 ```bash
 # Write the report body to a temp file
-# (Use the Write tool to create issue-report.json at the project root)
+# (Use the Write tool to create request-report.json at the project root)
 
-pnpm exec elevasis-sdk issue:submit --input-file ./issue-report.json --pretty
+pnpm exec elevasis-sdk request:submit --input-file ./request-report.json --pretty
 ```
 
 Delete the temp file after submission succeeds or fails.
 
 ## Report Back
 
-On success, the CLI prints the issue ID. Surface it to the user:
+On success, the CLI prints the request ID. Surface it to the user:
 
 ```
 Submitted — id: <uuid>
-Track it in Command Center > Issues.
+Track it in Command Center > Requests.
 ```
 
 ## Troubleshooting
@@ -159,7 +174,7 @@ Track it in Command Center > Issues.
 | ------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
 | `ELEVASIS_PLATFORM_KEY` missing | Key not set in root `.env`                                        | Add `ELEVASIS_PLATFORM_KEY=sk_...` to `.env`. Provision from Command Center > Settings > API Keys.            |
 | `401 Unauthorized`              | Key is malformed or revoked                                       | Verify the key starts with `sk_` and is 67 chars. Re-provision if needed.                                     |
-| `403 Forbidden`                 | Key's org lacks access to issue reporting                         | Contact the platform operator to verify the key's org permissions.                                            |
-| `Invalid issue body`            | Report failed CLI-side Zod validation before the request was sent | Read the field errors printed by the CLI. Common causes: missing `title`/`description`, invalid enum.         |
+| `403 Forbidden`                 | Key's org lacks access to request reporting                       | Contact the platform operator to verify the key's org permissions.                                            |
+| `Invalid request body`          | Report failed CLI-side Zod validation before the request was sent | Read the field errors printed by the CLI. Common causes: missing `title`/`description`/`type`, invalid enum.  |
 | `400 Bad Request`               | Body passed CLI validation but failed server-side validation      | Read the response body for the specific field error.                                                          |
 | Connection refused              | API server unreachable                                            | Default target is `https://api.elevasis.io` — check network. For local dev, set `ELEVASIS_API_URL` in `.env`. |

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/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/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/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-19T10:47:49.477Z by scripts/monorepo/generate-scaffold-contracts.js -->
+<!-- Auto-generated on 2026-04-20T23:27:16.482Z 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