@elevasis/sdk 1.6.0 → 1.7.0

package/reference/claude-config/skills/setup/SKILL.md

@@ -1,35 +1,51 @@
 ---
 name: setup
-description: First-time project setup — detect and replace template placeholders, install dependencies, verify build
+description: First-time project setup — detect and replace template placeholders, install dependencies, verify build, then hand off to /configure for org-model configuration
 argument-hint: ""
 ---
 
 # Setup
 
-First-time project setup for projects cloned directly from the template.
+First-time project setup for projects cloned directly from the template. Handles placeholder replacement, dependency install, and build verification. After bootstrap, delegates org-model configuration to `/configure`.
 
 **Usage:** `/setup`
 
-## Process
+---
 
-### Step 1: Detect State
+## State Detection (Run Before Anything Else)
 
-Scan these key files for unresolved placeholders:
+Before collecting any information or running any steps, determine which state the project is in. Read these files:
 
 - `package.json` — look for `__PROJECT_SLUG__` in the `name` field
-- `CLAUDE.md` — look for `TEMPLATE_PROJECT_NAME`
+- `CLAUDE.md` — look for `TEMPLATE_PROJECT_NAME` AND check whether `{CLIENT_CONTEXT}` and `{USER_PREFERENCES}` are still literal placeholder strings
 - `ui/package.json` — look for `__PROJECT_SLUG__`
 - `ui/index.html` — look for `__PROJECT_NAME__`
 
-If NO placeholders are found, the project is already configured. Print:
+**State A — Virgin (placeholders present):** One or more of the above placeholder strings is found. Run the full bootstrap flow (Steps 1–7 below), then hand off to `/configure`.
+
+**State B — Already bootstrapped, org-model at defaults:** No placeholders found, but `foundations/config/organization-model.ts` contains only the default branding override (just `branding.organizationName`, `branding.productName`, `branding.shortName` — no identity, customers, offerings, roles, goals, or techStack overrides). Print:
+
+```
+This project is already set up. The organization model has not been configured yet.
+Running /configure to set up your organization profile...
+```
+
+Then execute `/configure` (the full layered flow) and stop.
+
+**State C — Fully configured:** No placeholders found AND `foundations/config/organization-model.ts` has at least one non-branding domain populated (identity, customers, offerings, roles, goals, or techStack present). Print:
 
 ```
-Project is already configured. Running verification...
+This project is already configured. To update your organization profile, run /configure.
+To re-verify the build, run the checks below.
 ```
 
-Then skip directly to Step 4 (Install) or Step 5 (Verify) as appropriate.
+Offer to run the verification checks (Steps 6b–6e) if the user wants them. Do not re-ask any questions. Do not re-run placeholder replacement. Stop after verification.
+
+---
+
+## Full Bootstrap Flow (State A Only)
 
-### Step 2: Collect Info
+### Step 1: Collect Project Info
 
 Ask the user for three values:
 
@@ -49,7 +65,7 @@ Configuring project with:
 Proceed? (yes/no)
 ```
 
-### Step 3: Get to Know the User and Client
+### Step 2: Get to Know the User and Client
 
 Transition naturally after confirming the project values: "Now let me learn a bit about you and the client so I can be more helpful going forward."
 
@@ -86,7 +102,7 @@ Client: {company}
 Look good?
 ```
 
-### Step 4: Replace Placeholders
+### Step 3: Replace Placeholders
 
 Search ALL files in the project matching these extensions: `.ts`, `.tsx`, `.js`, `.mjs`, `.json`, `.md`, `.mdx`, `.html`, `.yaml`, `.yml`, `.css`, `.env.example`
 
@@ -105,21 +121,19 @@ For each matching file, replace all occurrences of:
 
 Use the Read tool to read each file, then the Edit tool (with `replace_all: true`) or Write tool to apply the replacements. Read each file before writing.
 
-After all replacements, re-scan the four key files from Step 1 to verify zero placeholders remain. If any are still present, report them by file and fix immediately.
+After all replacements, re-scan the four key files from State Detection to verify zero placeholders remain. If any are still present, report them by file and fix immediately.
 
-### Step 5: Populate Knowledge
+### Step 4: Populate CLAUDE.md Knowledge Sections
 
-Knowledge is split between `CLAUDE.md` (essentials loaded every turn) and `docs/knowledge/client.md` (detailed context loaded on demand).
+**Idempotency check (MANDATORY before writing):** Read `CLAUDE.md` and check whether `{CLIENT_CONTEXT}` and `{USER_PREFERENCES}` are still literal placeholder strings. Only write if they are still placeholders. If either section is already filled in (user or a previous run already populated it), skip that section entirely — do not overwrite.
 
-#### 5a: CLAUDE.md — lightweight summary
-
-**`{CLIENT_CONTEXT}`** -- replace with a single line:
+**`{CLIENT_CONTEXT}`** -- replace with a single line (only if still a placeholder):
 
 ```markdown
 **{company name}** — {what they do, one sentence}
 ```
 
-**`{USER_PREFERENCES}`** -- replace with a table:
+**`{USER_PREFERENCES}`** -- replace with a table (only if still a placeholder):
 
 ```markdown
 | Name   | Role   | Technical Level | Communication |
@@ -129,9 +143,11 @@ Knowledge is split between `CLAUDE.md` (essentials loaded every turn) and `docs/
 
 If the user skipped any knowledge questions, fill in what was provided and omit what wasn't -- don't leave placeholder text behind.
 
-#### 5b: docs/knowledge/client.md — full client context
+### Step 5: Create Client Knowledge Doc
+
+**Idempotency check:** Check whether `docs/knowledge/client.md` already exists. If it exists and is non-empty, skip this step entirely -- do not overwrite.
 
-Create `docs/knowledge/client.md` with the detailed info:
+If it does not exist, create `docs/knowledge/client.md`:
 
 ```markdown
 ---
@@ -150,7 +166,9 @@ description: Company background, industry, stakeholders, and business goals
 {any additional context shared -- key stakeholders, business goals, constraints, etc. If nothing was shared, write "No additional context provided yet. Update this as the project evolves."}
 ```
 
-### Step 6: Install Dependencies
+### Step 6: Install and Verify
+
+#### Step 6a: Install Dependencies
 
 ```bash
 pnpm install
@@ -158,7 +176,7 @@ pnpm install
 
 This generates the project's own `pnpm-lock.yaml`. Report success or any errors.
 
-### Step 7: Verify
+#### Step 6b–6e: Verify Build
 
 Run all checks sequentially (stop and report on first failure, but attempt all):
 
@@ -171,7 +189,7 @@ pnpm -C operations check-types
 
 For each check, record PASS or FAIL. If a check fails, read the output and report the error clearly. Do not silently skip failures.
 
-### Step 8: Report
+### Step 7: Bootstrap Report
 
 ```
 You're all set, {name}!
@@ -185,16 +203,23 @@ Verification:
   [PASS/FAIL] Production build (ui)
   [PASS/FAIL] Resource validation (operations)
   [PASS/FAIL] Type-check (operations)
+```
+
+If any verification step failed, add an Errors section listing each failure with its output.
+
+### Step 8: Hand Off to /configure
 
-Next steps:
-1. Copy root .env.example to .env and fill in ELEVASIS_PLATFORM_KEY
-2. Copy ui/.env.example to ui/.env and fill in VITE_WORKOS_CLIENT_ID
-3. See TODO.md for WorkOS dashboard setup and branding
-4. pnpm -C ui dev  (start dev server on port 4300)
-5. (If client-workspace/ exists) Open it in Claude Code and run /setup
+After a successful bootstrap, transition to the org-model configuration flow. Print:
+
+```
+Bootstrap complete. Now let's set up your organization profile.
 ```
 
-If any verification step failed, add an Errors section listing each failure with its output before the Next steps.
+Then execute `/configure` (the full layered flow, no argument). This is where identity, customers, offerings, roles, goals, and techStack are configured. Do not attempt to collect or write org-model data here — that ceremony belongs entirely to /configure.
+
+If the user wants to skip org-model setup for now, they can stop here and run `/configure` later.
+
+---
 
 ## Error Recovery
 
@@ -207,4 +232,28 @@ Remaining: <list files and placeholders>
 Action: Re-applying replacements to affected files...
 ```
 
-Fix each remaining occurrence before proceeding to Step 6.
+Fix each remaining occurrence before proceeding to Step 6a.
+
+---
+
+## Idempotency Guarantees
+
+Running `/setup` more than once is safe:
+
+- **Placeholder replacement** only runs when placeholders are detected (State A). It is skipped entirely in States B and C.
+- **CLAUDE.md knowledge sections** (`{CLIENT_CONTEXT}`, `{USER_PREFERENCES}`) are checked before writing. If already replaced, the write is skipped.
+- **`docs/knowledge/client.md`** is only created if it does not exist. An existing file is never overwritten by `/setup`.
+- **Org-model fields** (`foundations/config/organization-model.ts`) are never written by `/setup`. All org-model edits go through `/configure`, which has its own diff-preview and confirm ceremony.
+
+---
+
+## Relationship to /configure
+
+`/setup` is a thin bootstrap wrapper. It:
+
+1. Replaces scaffold placeholders (project name, slug, description)
+2. Fills lightweight CLAUDE.md knowledge sections (user and client basics, idempotent)
+3. Installs dependencies and verifies the build
+4. Hands off to `/configure` for org-model configuration
+
+`/configure` owns all structural org-model editing (identity, customers, offerings, roles, goals, techStack, features, labels). It is idempotent, confirm-before-overwrite, and includes a runtime validation gate. Re-run `/configure` any time organizational reality changes — no need to re-run `/setup`.

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.
 
 ---