@elevasis/sdk 1.22.1 → 1.23.0

package/dist/index.d.ts

@@ -4533,6 +4533,7 @@ declare const ProspectingBuildTemplateStepSchema: z.ZodObject<{
         crm: "crm";
         "lead-gen": "lead-gen";
         projects: "projects";
+        clients: "clients";
         operations: "operations";
         monitoring: "monitoring";
         knowledge: "knowledge";
@@ -4669,6 +4670,7 @@ declare const ProspectingBuildTemplateSchema: z.ZodObject<{
         crm: "crm";
         "lead-gen": "lead-gen";
         projects: "projects";
+        clients: "clients";
         operations: "operations";
         monitoring: "monitoring";
         knowledge: "knowledge";
@@ -4735,6 +4737,7 @@ declare const ProspectingBuildTemplateSchema: z.ZodObject<{
             crm: "crm";
             "lead-gen": "lead-gen";
             projects: "projects";
+            clients: "clients";
             operations: "operations";
             monitoring: "monitoring";
             knowledge: "knowledge";
@@ -11021,6 +11024,7 @@ declare const OrganizationModelSchema: z.ZodObject<{
             crm: "crm";
             "lead-gen": "lead-gen";
             projects: "projects";
+            clients: "clients";
             operations: "operations";
             monitoring: "monitoring";
             knowledge: "knowledge";

package/dist/index.js

@@ -68,6 +68,7 @@ var ORGANIZATION_MODEL_ICON_TOKENS = [
   "crm",
   "lead-gen",
   "projects",
+  "clients",
   "operations",
   "monitoring",
   "knowledge",
@@ -7290,7 +7291,7 @@ var DEFAULT_ORGANIZATION_MODEL_NAVIGATION = {
       business: {
         type: "group",
         label: "Business",
-        icon: "business",
+        icon: "briefcase",
         order: 20,
         children: {
           sales: {
@@ -7307,7 +7308,7 @@ var DEFAULT_ORGANIZATION_MODEL_NAVIGATION = {
             label: "Clients",
             path: "/clients",
             surfaceType: "list",
-            icon: "projects",
+            icon: "clients",
             order: 20,
             targets: { systems: ["clients"] }
           },
@@ -7681,7 +7682,7 @@ var DEFAULT_ORGANIZATION_MODEL = {
       enabled: true,
       lifecycle: "active",
       color: "orange",
-      icon: "projects",
+      icon: "clients",
       path: "/clients"
     },
     operations: {

package/dist/test-utils/index.d.ts

@@ -10261,6 +10261,7 @@ declare const OrganizationModelSchema: z.ZodObject<{
             crm: "crm";
             "lead-gen": "lead-gen";
             projects: "projects";
+            clients: "clients";
             operations: "operations";
             monitoring: "monitoring";
             knowledge: "knowledge";

package/dist/test-utils/index.js

@@ -6519,6 +6519,7 @@ var ORGANIZATION_MODEL_ICON_TOKENS = [
   "crm",
   "lead-gen",
   "projects",
+  "clients",
   "operations",
   "monitoring",
   "knowledge",
@@ -9671,7 +9672,7 @@ var DEFAULT_ORGANIZATION_MODEL_NAVIGATION = {
       business: {
         type: "group",
         label: "Business",
-        icon: "business",
+        icon: "briefcase",
         order: 20,
         children: {
           sales: {
@@ -9688,7 +9689,7 @@ var DEFAULT_ORGANIZATION_MODEL_NAVIGATION = {
             label: "Clients",
             path: "/clients",
             surfaceType: "list",
-            icon: "projects",
+            icon: "clients",
             order: 20,
             targets: { systems: ["clients"] }
           },
@@ -10062,7 +10063,7 @@ var DEFAULT_ORGANIZATION_MODEL = {
       enabled: true,
       lifecycle: "active",
       color: "orange",
-      icon: "projects",
+      icon: "clients",
       path: "/clients"
     },
     operations: {

package/dist/worker/index.js

@@ -4611,6 +4611,7 @@ var ORGANIZATION_MODEL_ICON_TOKENS = [
   "crm",
   "lead-gen",
   "projects",
+  "clients",
   "operations",
   "monitoring",
   "knowledge",
@@ -7763,7 +7764,7 @@ var DEFAULT_ORGANIZATION_MODEL_NAVIGATION = {
       business: {
         type: "group",
         label: "Business",
-        icon: "business",
+        icon: "briefcase",
         order: 20,
         children: {
           sales: {
@@ -7780,7 +7781,7 @@ var DEFAULT_ORGANIZATION_MODEL_NAVIGATION = {
             label: "Clients",
             path: "/clients",
             surfaceType: "list",
-            icon: "projects",
+            icon: "clients",
             order: 20,
             targets: { systems: ["clients"] }
           },
@@ -8154,7 +8155,7 @@ var DEFAULT_ORGANIZATION_MODEL = {
       enabled: true,
       lifecycle: "active",
       color: "orange",
-      icon: "projects",
+      icon: "clients",
       path: "/clients"
     },
     operations: {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elevasis/sdk",
-  "version": "1.22.1",
+  "version": "1.23.0",
   "description": "SDK for building Elevasis organization resources",
   "type": "module",
   "bin": {
@@ -57,7 +57,7 @@
     "tsup": "^8.0.0",
     "typescript": "5.9.2",
     "zod": "^4.1.0",
-    "@repo/core": "0.24.1",
+    "@repo/core": "0.25.0",
     "@repo/typescript-config": "0.0.0",
     "@repo/eslint-config": "0.0.0"
   },

package/reference/claude-config/rules/organization-model.md

@@ -1,32 +1,32 @@
----
-description: Edits to the canonical organization model go through /knowledge
-paths:
-  - core/config/organization-model.ts
-  - core/config/extensions/**/*.ts
----
-
-# Organization Model Edit Guide
-
-`core/config/organization-model.ts` is the single source of truth for this
-project's organizational identity -- it encodes customers, offerings, roles, goals,
+---
+description: Edits to the canonical organization model go through /om
+paths:
+  - core/config/organization-model.ts
+  - core/config/extensions/**/*.ts
+---
+
+# Organization Model Edit Guide
+
+`core/config/organization-model.ts` is the single source of truth for this
+project's organizational identity -- it encodes customers, offerings, roles, goals,
 Systems, ontology, Policies, Knowledge, config, and Resources
 descriptors that agents, workflows, and the UI shell all consume at runtime.
 New semantic authoring should start in system-colocated `ontology` scopes. Top-level
 `entities`, top-level `actions`, and `System.content` remain compatibility mirrors while
 published consumers finish moving to compiled ontology indexes.
-
-## Preferred Entry Point: `/knowledge`
-
-Direct edits to `organization-model.ts` are discouraged. Instead, use `/knowledge` (or
-`/knowledge <domain>`) to run the read → propose → confirm → write → validate ceremony:
-
-1. The skill reads the current model so proposals start from ground truth.
-2. It drafts only the specific block being changed, leaving everything else intact.
-3. The user confirms before any file is written.
-4. After writing, `pnpm -C operations check-types` runs and `OrganizationModelSchema.parse()`
-   is verified. On failure the file is rolled back automatically.
-
-Use `/knowledge <domain>` for targeted edits: `identity`, `customers`, `offerings`,
+
+## Preferred Entry Point: `/om`
+
+Direct edits to `organization-model.ts` are discouraged. Instead, use `/om` (or
+`/om <domain>`) to run the read → propose → confirm → write → validate ceremony:
+
+1. The skill reads the current model so proposals start from ground truth.
+2. It drafts only the specific block being changed, leaving everything else intact.
+3. The user confirms before any file is written.
+4. After writing, `pnpm -C operations check-types` runs and `OrganizationModelSchema.parse()`
+   is verified. On failure the file is rolled back automatically.
+
+Use `/om <domain>` for targeted edits: `identity`, `customers`, `offerings`,
 `roles`, `goals`, `techStack`, `systems`, `actions`, or `labels`. Resource identity and
 governance metadata belong in the id-keyed `resources` map; operations code derives runtime
 `resourceId` / `type` from those descriptors.
@@ -43,62 +43,62 @@ Author system-local semantics by boundary:
 - `System.content`, top-level `entities`, and top-level `actions` are compatibility mirrors only. Keep them aligned when current published consumers still need them, but do not treat them as the primary authoring surface.
 
 Do not author Resource `actionKey` in the target contract. Runtime/UI routing that needs a single selectable action should read `resource.ontology.primaryAction`.
-
-## Runtime Validation
-
-The model is validated at startup via `resolveOrganizationModel()` followed by
-`OrganizationModelSchema.parse()`. Cross-reference checks (segment ID refs in offerings,
-role reporting lines, period ordering in goals) are runtime-only and not caught by tsc
-alone -- always let the ceremony run both checks before treating a change as complete.
-
-## Extension Files
-
-New Zod extension files under `core/config/extensions/` are Level B codify
-operations. Route these through `/knowledge <domain>` as well -- the skill gates Level B
-to explicit user confirmation before scaffolding a new `.ts` file.
-
-This is a soft guide, not a hard block. The ceremony exists to prevent silent schema
-drift and to keep the model's editorial history visible.
-
-## Resource System Attachment
-
-Every resource in the id-keyed `organizationModel.resources` map declares which System it belongs to
-via `systemPath` -- a dot-separated path that resolves against the OM system tree
-(e.g. `"sys.operations"`, `"sales.crm"`):
-
-```ts
-{
-  id: 'apify-website-crawl',
-  systemPath: 'sys.operations',   // canonical system attachment
-  kind: 'workflow',
-  ...
-}
-```
-
-`systemPath` is validated at parse time by `SystemPathSchema` and cross-checked by
-`OrganizationModelSchema.superRefine` -- an unresolvable path causes a Zod error at
-schema validation. Use `getResourcesForSystem(model, path)` (from `@elevasis/core`) to
-query resources for a system at runtime. Pass `{ includeDescendants: true }` to include
-all descendant systems (segment-aware -- `'sales'` does NOT match `'salesforce.foo'`).
-
+
+## Runtime Validation
+
+The model is validated at startup via `resolveOrganizationModel()` followed by
+`OrganizationModelSchema.parse()`. Cross-reference checks (segment ID refs in offerings,
+role reporting lines, period ordering in goals) are runtime-only and not caught by tsc
+alone -- always let the ceremony run both checks before treating a change as complete.
+
+## Extension Files
+
+New Zod extension files under `core/config/extensions/` are Level B codify
+operations. Route these through `/om <domain>` as well -- the skill gates Level B
+to explicit user confirmation before scaffolding a new `.ts` file.
+
+This is a soft guide, not a hard block. The ceremony exists to prevent silent schema
+drift and to keep the model's editorial history visible.
+
+## Resource System Attachment
+
+Every resource in the id-keyed `organizationModel.resources` map declares which System it belongs to
+via `systemPath` -- a dot-separated path that resolves against the OM system tree
+(e.g. `"sys.operations"`, `"sales.crm"`):
+
+```ts
+{
+  id: 'apify-website-crawl',
+  systemPath: 'sys.operations',   // canonical system attachment
+  kind: 'workflow',
+  ...
+}
+```
+
+`systemPath` is validated at parse time by `SystemPathSchema` and cross-checked by
+`OrganizationModelSchema.superRefine` -- an unresolvable path causes a Zod error at
+schema validation. Use `getResourcesForSystem(model, path)` (from `@elevasis/core`) to
+query resources for a system at runtime. Pass `{ includeDescendants: true }` to include
+all descendant systems (segment-aware -- `'sales'` does NOT match `'salesforce.foo'`).
+
 Some external templates may carry a `systemId` compatibility mirror while published
 `@elevasis/core` releases catch up to the current source contract. Treat that field as
 legacy adapter data only; author new resource relationships against `systemPath`.
-
-Do not fetch resources for every system-oriented read by default. For agent workflows, start
-with the user's requested OM/knowledge context and query resources only when the task involves
-runtime ownership, executable implementation, observability, deployment, or resource governance.
-Use the descendant rollup only when parent-system scope is intended.
-
-`resource.category` and `resource.links[].nodeId` are **runtime filter overlays** -- they
-drive UI faceted filtering in the Command Center but do NOT define system membership.
-System membership is `systemPath` only.
-
-```ts
-// category and links power UI filter chips; systemPath is the
-// canonical OM attachment used for graph edges and getResourcesForSystem queries.
-```
-
+
+Do not fetch resources for every system-oriented read by default. For agent workflows, start
+with the user's requested OM/om context and query resources only when the task involves
+runtime ownership, executable implementation, observability, deployment, or resource governance.
+Use the descendant rollup only when parent-system scope is intended.
+
+`resource.category` and `resource.links[].nodeId` are **runtime filter overlays** -- they
+drive UI faceted filtering in the Command Center but do NOT define system membership.
+System membership is `systemPath` only.
+
+```ts
+// category and links power UI filter chips; systemPath is the
+// canonical OM attachment used for graph edges and getResourcesForSystem queries.
+```
+
 `resource.codeRefs[]` are repo-relative implementation breadcrumbs for agents and
 operators. Use them to point from a governed OM Resource descriptor to the operations
 entrypoint, handler, schema, test, docs, or config files that implement it. They do
@@ -114,6 +114,3 @@ types, link types, event types, and surfaces. `System.config` owns local setting
 defaults. If current UI or runtime code still needs legacy mirrors, keep `entities`,
 `actions`, or `System.content` aligned with the ontology/config record instead of
 inventing a separate source of truth.
-
-See `.claude/rules/system-shaping.md` (in the monorepo) for the substrate-shaping
-propagation checklist that governs renames of this shape.

package/reference/claude-config/rules/organization-os.md

@@ -1,115 +1,115 @@
-# Organization OS
-
+# Organization OS
+
 Organization OS is the semantic contract layer defining how organizations, Systems, Actions, ontology, resources, policies, roles, goals, knowledge, and runtime surfaces relate. This project consumes Organization OS through published `@elevasis/core` / `@elevasis/sdk` configuration and does not maintain the monorepo schema.
 
 This rule is an orientation and reference map. Concrete edit rules for `core/config/organization-model.ts`, `systemPath`, resources, ontology, knowledge, and validation live in `.claude/rules/organization-model.md`.
-
-## Key Files in This Project
-
+
+## Key Files in This Project
+
 - `core/config/organization-model.ts` -- project-specific org model definition, Systems, system-local ontology/config, Knowledge, and Resources descriptor catalog (`organizationModel.resources`)
-- `core/config/extensions/` -- project-owned entity extension schemas
-- `core/types/entities.ts` -- typed entity contracts (Project, Deal, etc.). Extends `BaseProject`, `BaseDeal` from `@elevasis/core/entities` with project-specific metadata. Read this when authoring workflows that operate on these entities.
-- `ui/src/routes/__root.tsx` -- wires `ElevasisSystemsProvider` with `canonicalOrganizationModel`
-- `ui/src/app-config.ts` -- references the org model
-- `operations/src/index.ts` -- `DeploymentSpec` registry for workflows and agents
-
-## Domain Overview
-
-As of the 2026-05 resource-governance expansion, `OrganizationModel` includes platform configuration, organizational reality, governance, and knowledge domains:
-
+- `core/config/extensions/` -- project-owned entity extension schemas
+- `core/types/entities.ts` -- typed entity contracts (Project, Deal, etc.). Extends `BaseProject`, `BaseDeal` from `@elevasis/core/entities` with project-specific metadata. Read this when authoring workflows that operate on these entities.
+- `ui/src/routes/__root.tsx` -- wires `ElevasisSystemsProvider` with `canonicalOrganizationModel`
+- `ui/src/app-config.ts` -- references the org model
+- `operations/src/index.ts` -- `DeploymentSpec` registry for workflows and agents
+
+## Domain Overview
+
+As of the 2026-05 resource-governance expansion, `OrganizationModel` includes platform configuration, organizational reality, governance, and knowledge domains:
+
 **Platform configuration:** `systems`, `branding`, `navigation`
-
-**Organizational reality:** `identity`, `customers`, `offerings`, `roles`, `goals`
-
+
+**Organizational reality:** `identity`, `customers`, `offerings`, `roles`, `goals`
+
 **Governance:** `resources`, `policies`, and resource-to-System relationships
 
 **Ontology, config, and knowledge:** `System.ontology` owns durable semantic contracts such as object types, action types, catalog types, link types, event types, and surfaces. `System.config` owns system-local JSON settings and defaults. `knowledge` is a flat id-keyed map of playbooks, strategies, and references that explain or govern systems and ontology records.
 
 Resource identity is authored once in the id-keyed `resources` map. Each resource attaches to a System via `systemPath` and can declare ontology relationships through `resource.ontology`. Operations imports those descriptors and derives runtime `resourceId` / `type` while assembling the `DeploymentSpec`.
-
-### Domain Rename Note
-
-Some legacy UI feature constants and consumer-facing route keys are intentionally unchanged for compatibility:
-
-| Old field  | New field     | Legacy key (unchanged) | UI constant (unchanged) |
-| ---------- | ------------- | ---------------------- | --------------------- |
-| `crm`      | `sales`       | `'crm'`                | `CRM_FEATURE_ID`      |
-| `leadGen`  | `prospecting` | `'lead-gen'`           | `LEAD_GEN_FEATURE_ID` |
-| `delivery` | `projects`    | `'projects'`           | `PROJECTS_FEATURE_ID` |
-
-## Reference Documentation
-
-Full Organization OS documentation ships with the SDK and is available locally after `pnpm install`:
-
-### Scaffold Reference (via SDK)
-
-All paths under `node_modules/@elevasis/sdk/reference/scaffold/`:
-
-- `node_modules/@elevasis/sdk/reference/scaffold/index.mdx` -- scaffold root and navigation
-- `node_modules/@elevasis/sdk/reference/scaffold/core/organization-model.mdx` -- semantic contract, domains, adapter authoring, validation gate, `/knowledge` entry point
-- `node_modules/@elevasis/sdk/reference/scaffold/core/organization-graph.mdx` -- graph derivation, node/edge taxonomy, lenses
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-shell.mdx` -- SystemModule manifest, provider runtime
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/composition-extensibility.mdx` -- layout primitives, router abstraction
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/recipes.md` -- copy-paste UI recipes for pages, nav items, components
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-flags-and-gating.md` -- three-concept gating model
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/customization.md` -- sidebar composition via manifest overrides
-- `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-feature.md` -- end-to-end OM-backed System recipe through manifest, routes, and gating
-- `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-resource.md` -- author and deploy a workflow or agent
-- `node_modules/@elevasis/sdk/reference/scaffold/recipes/gate-by-feature-or-admin.md` -- decision table for access control patterns
-- `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md` -- build or extend lead-gen pages, sidebars, hooks, list/member state, artifacts, workflow adapters, and prospecting semantics
-- `node_modules/@elevasis/sdk/reference/scaffold/operations/workflow-recipes.md` -- workflow anatomy, adapter patterns, trigger patterns
-- `node_modules/@elevasis/sdk/reference/scaffold/operations/propagation-pipeline.md` -- how sync and verification work across projects
-- `node_modules/@elevasis/sdk/reference/scaffold/operations/scaffold-maintenance.md` -- content placement and auto-generation pipeline
-- `node_modules/@elevasis/sdk/reference/scaffold/reference/glossary.md` -- Organization OS term definitions
-- `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` -- auto-generated TypeScript contract shapes
-- `node_modules/@elevasis/sdk/reference/scaffold/reference/feature-registry.md` -- auto-generated feature manifest catalog
-
-### Local Project Docs
-
-- `.claude/rules/agent-start-here.md` -- canonical first-read for agents (includes task-class routing)
-
-## Published Subpaths and Constants
-
-- `@elevasis/core/organization-model` -- the curated organization-model barrel. Exports `defineOrganizationModel`, `resolveOrganizationModel`, `OrganizationModelSchema`, `DEFAULT_ORGANIZATION_MODEL`, organization-model types, and typed System/Action plus legacy UI feature/surface constants.
-  - Legacy UI feature IDs: `CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`, `PROJECTS_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, `MONITORING_FEATURE_ID`, `SETTINGS_FEATURE_ID`, `SEO_FEATURE_ID`
-  - Headline surface IDs: `CRM_PIPELINE_SURFACE_ID`, `LEAD_GEN_LISTS_SURFACE_ID`, `PROJECTS_INDEX_SURFACE_ID`, `OPERATIONS_ORGANIZATION_GRAPH_SURFACE_ID`
-  - Reality domain types: `OrganizationModelIdentity`, `OrganizationModelCustomers`, `OrganizationModelCustomerSegment`, `OrganizationModelOfferings`, `OrganizationModelProduct`, `OrganizationModelRoles`, `OrganizationModelRole`, `OrganizationModelGoals`, `OrganizationModelObjective`, `OrganizationModelKeyResult`
-  - TechStack: `TechStackEntrySchema`, `OrganizationModelTechStackEntry`
-  - Use constants instead of magic strings when overriding the org model.
-- `@elevasis/core/entities` -- entity contracts barrel. Exports `BaseProject`, `BaseProjectSchema`, `BaseProjectInput` and the equivalents for `Milestone`, `Task`, `Deal`, `Company`, `Contact`. Each base interface is generic over a `\<TMeta>` extension slot. Extend these in `core/types/entities.ts` to add project-specific fields.
-
-## When Working with Organization OS
-
-- **Changing org model (structural reality):** Use `/knowledge` as the entry point. Direct edits to `core/config/organization-model.ts` are discouraged -- `/knowledge` runs the read -> propose -> confirm -> write -> validate ceremony. Run `/knowledge` for the full layered flow or `/knowledge \<domain>` for a targeted domain. See `.claude/rules/organization-model.md` for the concrete authoring boundary.
-- **Building or extending CRM:** Start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-crm.md`. CRM spans Organization OS sales semantics, shared UI primitives, deal hooks, workflow adapters, and generated contracts.
-- **Building or extending lead gen:** Start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md`. Lead gen spans Organization OS prospecting semantics, shared UI primitives, list/member hooks, artifact hooks, workflow adapters, and generated contracts.
-- **Customizing CRM deal actions:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/customize-crm-actions.md`. Do not add `sales.actions` to the org model; the v1 server-side override surface is intentionally deferred.
-- **Adding or toggling a System:** Follow the current scaffold recipes when they mention UI features, but translate Organization OS changes to Systems, navigation surfaces, and Actions. Use `/knowledge systems` for availability/routing changes.
-- **Adding a resource:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-resource.md`.
-- **Extending entities:** Start with `core/types/entities.ts` for the demo extension pattern. Base shapes come from `@elevasis/core/entities`.
-- **Authoring a workflow that takes a Project/Deal/etc.:** Reference entity types from `core/types/entities.ts` in the input schema -- do not redeclare them.
+
+### Domain Rename Note
+
+Some legacy UI feature constants and consumer-facing route keys are intentionally unchanged for compatibility:
+
+| Old field  | New field     | Legacy key (unchanged) | UI constant (unchanged) |
+| ---------- | ------------- | ---------------------- | ----------------------- |
+| `crm`      | `sales`       | `'crm'`                | `CRM_FEATURE_ID`        |
+| `leadGen`  | `prospecting` | `'lead-gen'`           | `LEAD_GEN_FEATURE_ID`   |
+| `delivery` | `projects`    | `'projects'`           | `PROJECTS_FEATURE_ID`   |
+
+## Reference Documentation
+
+Full Organization OS documentation ships with the SDK and is available locally after `pnpm install`:
+
+### Scaffold Reference (via SDK)
+
+All paths under `node_modules/@elevasis/sdk/reference/scaffold/`:
+
+- `node_modules/@elevasis/sdk/reference/scaffold/index.mdx` -- scaffold root and navigation
+- `node_modules/@elevasis/sdk/reference/scaffold/core/organization-model.mdx` -- semantic contract, domains, adapter authoring, validation gate, `/om` entry point
+- `node_modules/@elevasis/sdk/reference/scaffold/core/organization-graph.mdx` -- graph derivation, node/edge taxonomy, lenses
+- `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-shell.mdx` -- SystemModule manifest, provider runtime
+- `node_modules/@elevasis/sdk/reference/scaffold/ui/composition-extensibility.mdx` -- layout primitives, router abstraction
+- `node_modules/@elevasis/sdk/reference/scaffold/ui/recipes.md` -- copy-paste UI recipes for pages, nav items, components
+- `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-flags-and-gating.md` -- three-concept gating model
+- `node_modules/@elevasis/sdk/reference/scaffold/ui/customization.md` -- sidebar composition via manifest overrides
+- `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-feature.md` -- end-to-end OM-backed System recipe through manifest, routes, and gating
+- `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-resource.md` -- author and deploy a workflow or agent
+- `node_modules/@elevasis/sdk/reference/scaffold/recipes/gate-by-feature-or-admin.md` -- decision table for access control patterns
+- `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md` -- build or extend lead-gen pages, sidebars, hooks, list/member state, artifacts, workflow adapters, and prospecting semantics
+- `node_modules/@elevasis/sdk/reference/scaffold/operations/workflow-recipes.md` -- workflow anatomy, adapter patterns, trigger patterns
+- `node_modules/@elevasis/sdk/reference/scaffold/operations/propagation-pipeline.md` -- how sync and verification work across projects
+- `node_modules/@elevasis/sdk/reference/scaffold/operations/scaffold-maintenance.md` -- content placement and auto-generation pipeline
+- `node_modules/@elevasis/sdk/reference/scaffold/reference/glossary.md` -- Organization OS term definitions
+- `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` -- auto-generated TypeScript contract shapes
+- `node_modules/@elevasis/sdk/reference/scaffold/reference/feature-registry.md` -- auto-generated feature manifest catalog
+
+### Local Project Docs
+
+- `.claude/rules/agent-start-here.md` -- canonical first-read for agents (includes task-class routing)
+
+## Published Subpaths and Constants
+
+- `@elevasis/core/organization-model` -- the curated organization-model barrel. Exports `defineOrganizationModel`, `resolveOrganizationModel`, `OrganizationModelSchema`, `DEFAULT_ORGANIZATION_MODEL`, organization-model types, and typed System/Action plus legacy UI feature/surface constants.
+  - Legacy UI feature IDs: `CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`, `PROJECTS_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, `MONITORING_FEATURE_ID`, `SETTINGS_FEATURE_ID`, `SEO_FEATURE_ID`
+  - Headline surface IDs: `CRM_PIPELINE_SURFACE_ID`, `LEAD_GEN_LISTS_SURFACE_ID`, `PROJECTS_INDEX_SURFACE_ID`, `OPERATIONS_ORGANIZATION_GRAPH_SURFACE_ID`
+  - Reality domain types: `OrganizationModelIdentity`, `OrganizationModelCustomers`, `OrganizationModelCustomerSegment`, `OrganizationModelOfferings`, `OrganizationModelProduct`, `OrganizationModelRoles`, `OrganizationModelRole`, `OrganizationModelGoals`, `OrganizationModelObjective`, `OrganizationModelKeyResult`
+  - TechStack: `TechStackEntrySchema`, `OrganizationModelTechStackEntry`
+  - Use constants instead of magic strings when overriding the org model.
+- `@elevasis/core/entities` -- entity contracts barrel. Exports `BaseProject`, `BaseProjectSchema`, `BaseProjectInput` and the equivalents for `Milestone`, `Task`, `Deal`, `Company`, `Contact`. Each base interface is generic over a `\<TMeta>` extension slot. Extend these in `core/types/entities.ts` to add project-specific fields.
+
+## When Working with Organization OS
+
+- **Changing org model (structural reality):** Use `/om` as the entry point. Direct edits to `core/config/organization-model.ts` are discouraged -- `/om` runs the read -> propose -> confirm -> write -> validate ceremony. Run `/om` for the full layered flow or `/om \<domain>` for a targeted domain. See `.claude/rules/organization-model.md` for the concrete authoring boundary.
+- **Building or extending CRM:** Start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-crm.md`. CRM spans Organization OS sales semantics, shared UI primitives, deal hooks, workflow adapters, and generated contracts.
+- **Building or extending lead gen:** Start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md`. Lead gen spans Organization OS prospecting semantics, shared UI primitives, list/member hooks, artifact hooks, workflow adapters, and generated contracts.
+- **Customizing CRM deal actions:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/customize-crm-actions.md`. Do not add `sales.actions` to the org model; the v1 server-side override surface is intentionally deferred.
+- **Adding or toggling a System:** Follow the current scaffold recipes when they mention UI features, but translate Organization OS changes to Systems, navigation surfaces, and Actions. Use `/om systems` for availability/routing changes.
+- **Adding a resource:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-resource.md`.
+- **Extending entities:** Start with `core/types/entities.ts` for the demo extension pattern. Base shapes come from `@elevasis/core/entities`.
+- **Authoring a workflow that takes a Project/Deal/etc.:** Reference entity types from `core/types/entities.ts` in the input schema -- do not redeclare them.
 - **Adding system-local ontology/config:** Put durable business schema in `System.ontology`, local defaults/settings in `System.config`, executable implementations in `resources`, and explanatory or governing material in `knowledge`.
-- **Understanding contracts:** Check `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` for current type shapes.
-- **Debugging sync issues:** Check `node_modules/@elevasis/sdk/reference/scaffold/operations/propagation-pipeline.md` for the verification pipeline.
-
-## `/knowledge` -- Org Model QA Entry Point
-
-`/knowledge` is the recurring, safe-to-re-run org model editor for this project. It is a skill (not a command) at `.claude/skills/knowledge/SKILL.md`.
-
-**Usage:**
-
-- `/knowledge` -- layered flow: identity → customers → offerings → roles → goals → techStack
-- `/knowledge identity` -- legal identity, mission/vision, industry, geography, timezone
-- `/knowledge customers` -- customer segments with jobs-to-be-done, pains, gains, firmographics
-- `/knowledge offerings` -- products and services with pricing model and segment references
-- `/knowledge roles` -- role chart with responsibilities, reporting lines, and holders
-- `/knowledge goals` -- organizational goals with period and measurable outcomes
-- `/knowledge techStack` -- external-SaaS and integration context; resource identity still belongs in OM Resources descriptors
-- `/knowledge systems` -- enable, disable, or add Systems; route invokable behavior through Actions
-- `/knowledge labels` -- edit display labels on enum entries (statuses, stages)
-
-Every write is gated: `resolveOrganizationModel()` must succeed (Zod cross-refs pass) and `pnpm -C operations check-types` must pass. On failure the change is rolled back.
-
-**Distinction from `/setup`:** `/setup` is first-time bootstrap only. After bootstrap it delegates here. `/knowledge` is idempotent and safe to re-run at any time.
-
-The ambient vibe layer (`.claude/rules/vibe.md`) automatically detects Codify intent in plain language and delegates to `/knowledge`. Power users can invoke `/knowledge` directly to bypass the ambient layer entirely.
+- **Understanding contracts:** Check `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` for current type shapes.
+- **Debugging sync issues:** Check `node_modules/@elevasis/sdk/reference/scaffold/operations/propagation-pipeline.md` for the verification pipeline.
+
+## `/om` -- Org Model QA Entry Point
+
+`/om` is the recurring, safe-to-re-run org model editor for this project. It is a skill (not a command) at `.claude/skills/om/SKILL.md`.
+
+**Usage:**
+
+- `/om` -- layered flow: identity → customers → offerings → roles → goals → techStack
+- `/om identity` -- legal identity, mission/vision, industry, geography, timezone
+- `/om customers` -- customer segments with jobs-to-be-done, pains, gains, firmographics
+- `/om offerings` -- products and services with pricing model and segment references
+- `/om roles` -- role chart with responsibilities, reporting lines, and holders
+- `/om goals` -- organizational goals with period and measurable outcomes
+- `/om techStack` -- external-SaaS and integration context; resource identity still belongs in OM Resources descriptors
+- `/om systems` -- enable, disable, or add Systems; route invokable behavior through Actions
+- `/om labels` -- edit display labels on enum entries (statuses, stages)
+
+Every write is gated: `resolveOrganizationModel()` must succeed (Zod cross-refs pass) and `pnpm -C operations check-types` must pass. On failure the change is rolled back.
+
+**Distinction from `/setup`:** `/setup` is first-time bootstrap only. After bootstrap it delegates here. `/om` is idempotent and safe to re-run at any time.
+
+The ambient vibe layer (`.claude/rules/vibe.md`) automatically detects Codify intent in plain language and delegates to `/om`. Power users can invoke `/om` directly to bypass the ambient layer entirely.