@elevasis/sdk 1.44.3 → 1.46.0

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

@@ -1,146 +1,159 @@
----
-title: Organization Model
-description: Organization OS Model layer documentation for the System hierarchy, semantic domains, resource descriptors, and curated @elevasis/core public API.
----
+---
+title: Organization Model
+description: Organization OS Model layer documentation for the System hierarchy, semantic domains, resource descriptors, and curated @elevasis/core public API.
+---
 <!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
 <!-- Regenerate: pnpm scaffold:sync -->
 
-
-## Overview
-
-The organization model is the semantic contract that maps an organization's System hierarchy, business semantics, shell navigation, resource governance, action/entity vocabulary, and graph binding. It is schema-first, versioned, and validated.
-
-The model is authored in `@repo/core` and published through the curated `@elevasis/core/organization-model` surface.
-
-## Source of Truth
-
-- `packages/core/src/organization-model/schema.ts`
-- `packages/core/src/organization-model/types.ts`
-- `packages/core/src/organization-model/defaults.ts`
-- `packages/core/src/organization-model/helpers.ts`
-- `packages/core/src/organization-model/graph/link.ts`
-- `packages/core/src/organization-model/published.ts`
-- `packages/core/src/__tests__/template-core-compatibility.test.ts`
-
-## Contract Shape
-
-Top-level fields on `OrganizationModel`:
-
-- `version`
-- `domainMetadata`
-- `branding`
-- `navigation`
-- `identity`
-- `customers`
-- `offerings`
-- `roles`
-- `goals`
-- `systems`
-- `resources`
-- `actions`
-- `entities`
-- `policies`
-- `knowledge`
-
-The pure collection domains are id-keyed maps: `systems`, `roles`, `goals`, `customers`, `offerings`, `resources`, `actions`, `entities`, `policies`, and `knowledge`. The map key must match the entry `id`. Entries carry `order` for deterministic ordered views; use `listDomain(record)` when order matters.
-
-Resource identity is authored inside `OrganizationModel.resources`. Runtime workflows, agents, integrations, and scripts import those descriptors, derive `resourceId` and kind from them, and attach executable behavior in operations code.
-
-## System Shape
-
-`OrganizationModel.systems` is the canonical semantic domain map. Hierarchy is authored with recursive `subsystems`; dotted paths such as `sales.crm` are derived from position in that tree. `parentSystemId` and `id` remain accepted compatibility fields during the migration.
-
-```ts
-systems: {
-  dashboard: { id: 'dashboard', order: 10, label: 'Dashboard', lifecycle: 'active' },
-  sales: { id: 'sales', order: 20, label: 'Sales', lifecycle: 'active' },
-  clients: { id: 'clients', order: 30, label: 'Clients', lifecycle: 'active' },
-  projects: { id: 'projects', order: 40, label: 'Projects', lifecycle: 'active' }
-}
-```
-
-Authored fields:
-
-- `id`
-- `label`
-- `description`
-- `kind`
-- `parentSystemId`
-- `ui`
-- `lifecycle`
-- `requiresAdmin`
-- `actions`
-- `policies`
-- `content`
-- `subsystems`
-- `order`
-
-Systems describe ownership, hierarchy, lifecycle, access, and governance. Sidebar presentation lives in `navigation.sidebar`, not on System entries. UI-backed Systems may still provide `ui.path` for route matching during the migration, but `ui.surfaces` is not an authored contract. `lifecycle` replaces the old feature enabled/dev-only split.
-
-## Navigation Shape
-
-`OrganizationModel.navigation.sidebar` is the authored shell tree. It has `primary` and `bottom` sections whose records contain recursive group nodes and routeable surface nodes:
-
-```ts
-navigation: {
-  sidebar: {
-    primary: {
-      dashboard: {
-        type: 'surface',
-        order: 10,
-        label: 'Dashboard',
-        path: '/',
-        surfaceType: 'dashboard',
-        targets: { systems: ['dashboard'] }
-      },
-      business: {
-        type: 'group',
-        order: 20,
-        label: 'Business',
-        children: {
-          sales: {
-            type: 'surface',
-            order: 10,
-            label: 'Sales',
-            path: '/sales',
-            surfaceType: 'page',
-            targets: { systems: ['sales'] }
-          },
-          clients: {
-            type: 'surface',
-            order: 20,
-            label: 'Clients',
-            path: '/clients',
-            surfaceType: 'list',
-            targets: { systems: ['clients'] }
-          }
-        }
-      }
-    },
-    bottom: {}
-  }
-}
-```
-
-Dashboard is ordered before Business in the primary sidebar. Business is a navigation group only; it is not a System and it is not a URL namespace. Routeable leaves are projected into flat surface DTOs by `projectOrganizationSurfaces(model)`.
-
-## Graph IDs and Resource Descriptors
-
-Cross-collection links use kind-prefixed graph IDs:
-
-- `system:sales.crm`
-- `integration:instantly`
-- `resource:lead-import`
-- `action:operations.queue.review`
-
-Resource identity is authored in the OM Resources domain. Operations imports descriptors from `organizationModel.resources` and derives runtime `resourceId` / `type` while attaching executable behavior.
-
-```ts
-import { defineResources } from '@elevasis/core/organization-model'
-
+
+## Overview
+
+The organization model is the semantic contract that maps an organization's System hierarchy, business semantics, shell navigation, resource governance, action/entity vocabulary, and graph binding. It is schema-first, versioned, and validated.
+
+The model is authored in `@repo/core` and published through the curated `@elevasis/core/organization-model` surface.
+
+## Source of Truth
+
+- `packages/core/src/organization-model/schema.ts`
+- `packages/core/src/organization-model/types.ts`
+- `packages/core/src/organization-model/defaults.ts`
+- `packages/core/src/organization-model/helpers.ts`
+- `packages/core/src/organization-model/graph/link.ts`
+- `packages/core/src/organization-model/published.ts`
+- `packages/core/src/__tests__/template-core-compatibility.test.ts`
+
+## Contract Shape
+
+Top-level fields on `OrganizationModel`:
+
+- `version`
+- `snapshotHash`
+- `domainMetadata`
+- `branding`
+- `navigation`
+- `identity`
+- `clients`
+- `customers`
+- `offerings`
+- `roles`
+- `goals`
+- `systems`
+- `ontology`
+- `resources`
+- `topology`
+- `actions`
+- `entities`
+- `knowledge`
+
+The pure collection domains are id-keyed maps: `systems`, `roles`, `goals`, `clients`, `customers`, `offerings`, `resources`, `actions`, `entities`, and `knowledge`. `ontology` is an `OntologyScope` object (not an id-keyed map at the top level) and `topology` is a relationships record. The map key must match the entry `id` for id-keyed domains. Entries carry `order` for deterministic ordered views; use `listDomain(record)` when order matters. `sales`, `prospecting`, `projects`, `statuses`, and `policies` were removed from the top-level contract; do not author against them.
+
+Resource identity is authored inside `OrganizationModel.resources`. Runtime workflows, agents, integrations, and scripts import those descriptors, derive `resourceId` and kind from them, and attach executable behavior in operations code.
+
+## System Shape
+
+`OrganizationModel.systems` is the canonical semantic domain map. Hierarchy is authored with recursive `systems`; dotted paths such as `sales.crm` are derived from position in that tree. `subsystems` is a deprecated compatibility alias — it is still accepted and kept in sync with `systems` during parse, but new authoring should use `systems`. `parentSystemId` and `id` remain accepted compatibility fields during the migration.
+
+{/* doc-snippet:skip: illustrative excerpt, not a standalone compilable file */}
+
+```ts
+systems: {
+  dashboard: { id: 'dashboard', order: 10, label: 'Dashboard', lifecycle: 'active' },
+  sales: { id: 'sales', order: 20, label: 'Sales', lifecycle: 'active' },
+  clients: { id: 'clients', order: 30, label: 'Clients', lifecycle: 'active' },
+  projects: { id: 'projects', order: 40, label: 'Projects', lifecycle: 'active' }
+}
+```
+
+Authored fields:
+
+- `id`
+- `label`
+- `description`
+- `kind`
+- `parentSystemId`
+- `ui`
+- `lifecycle`
+- `responsibleRoleId`
+- `governedByKnowledge`
+- `actions`
+- `drivesGoals`
+- `apiInterface`
+- `config`
+- `ontology`
+- `systems`
+- `order`
+
+Systems describe ownership, hierarchy, lifecycle, access, and governance. Sidebar presentation lives in `navigation.sidebar`, not on System entries. UI-backed Systems may still provide `ui.path` for route matching during the migration, but `ui.surfaces` is not an authored contract. `lifecycle` replaces the old feature enabled/dev-only split. `config` holds System-local JSON settings; `ontology` holds System-owned object, action, catalog, link, event, and other ontology records; `apiInterface` is the thin platform API-readiness marker (see `System Interface` in the glossary).
+
+## Navigation Shape
+
+`OrganizationModel.navigation.sidebar` is the authored shell tree. It has `primary` and `bottom` sections whose records contain recursive group nodes and routeable surface nodes:
+
+{/* doc-snippet:skip: illustrative excerpt, not a standalone compilable file */}
+
+```ts
+navigation: {
+  sidebar: {
+    primary: {
+      dashboard: {
+        type: 'surface',
+        order: 10,
+        label: 'Dashboard',
+        path: '/',
+        surfaceType: 'dashboard',
+        targets: { systems: ['dashboard'] }
+      },
+      business: {
+        type: 'group',
+        order: 20,
+        label: 'Business',
+        children: {
+          sales: {
+            type: 'surface',
+            order: 10,
+            label: 'Sales',
+            path: '/sales',
+            surfaceType: 'page',
+            targets: { systems: ['sales'] }
+          },
+          clients: {
+            type: 'surface',
+            order: 20,
+            label: 'Clients',
+            path: '/clients',
+            surfaceType: 'list',
+            targets: { systems: ['clients'] }
+          }
+        }
+      }
+    },
+    bottom: {}
+  }
+}
+```
+
+Dashboard is ordered before Business in the primary sidebar. Business is a navigation group only; it is not a System and it is not a URL namespace. Routeable leaves are projected into flat surface DTOs by `projectOrganizationSurfaces(model)`.
+
+## Graph IDs and Resource Descriptors
+
+Cross-collection links use kind-prefixed graph IDs:
+
+- `system:sales.crm`
+- `integration:instantly`
+- `resource:lead-import`
+- `action:operations.queue.review`
+
+Resource identity is authored in the OM Resources domain. Operations imports descriptors from `organizationModel.resources` and derives runtime `resourceId` / `type` while attaching executable behavior.
+
+{/* doc-snippet:skip: `systems` in resourceGovernanceModel refers to the System map authored earlier in a tenant's own organization-model.ts, not a local declaration */}
+
+```ts
+import { defineResources } from '@elevasis/core/organization-model'
+
 export const resourceDescriptors = defineResources({
   leadImport: {
     id: 'lgn-01c-apollo-import-workflow',
+    order: 10,
     title: 'Apollo Import',
     description: 'Imports Apollo company records into the lead generation pipeline.',
     kind: 'workflow',
@@ -153,82 +166,85 @@ export const resourceDescriptors = defineResources({
     },
     codeRefs: [
       {
-        path: 'packages/elevasis-operations/src/sales/prospecting/scrape/apollo-import.ts',
-        role: 'entrypoint',
-        symbol: 'lgnApolloImportWorkflow'
-      }
-    ]
-  }
-})
-
-export const resourceGovernanceModel = {
-  systems,
-  resources: resourceDescriptors
-} as const
-```
-
-Legacy `sys.*` paths may still appear in older examples and external compatibility mirrors.
-For new Organization OS examples, prefer the current semantic System path.
-
-## Domain Semantics
-
-The model keeps business semantics in named domains:
-
-- `identity`, `customers`, `offerings`, `roles`, `goals` -- organizational reality
-- `systems` -- bounded contexts that group governed operational resources and system-local content
-- `actions` -- stable business verbs exposed or consumed by systems
-- `entities` -- durable business nouns and their semantic links
-- `resources` -- governance-only workflow, agent, integration, and script descriptors
-- `policies` -- operational governance rules over systems, actions, resources, and roles
-- `knowledge` -- playbooks, strategies, references, and graph-governing links
-
+        path: 'packages/elevasis/operations/src/sales/prospecting/scrape/apollo-import.ts',
+        role: 'entrypoint',
+        symbol: 'lgnApolloImportWorkflow'
+      }
+    ]
+  }
+})
+
+export const resourceGovernanceModel = {
+  systems,
+  resources: resourceDescriptors
+} as const
+```
+
+Legacy `sys.*` paths may still appear in older examples and external compatibility mirrors.
+For new Organization OS examples, prefer the current semantic System path.
+
+## Domain Semantics
+
+The model keeps business semantics in named domains:
+
+- `identity`, `customers`, `offerings`, `roles`, `goals` -- organizational reality
+- `systems` -- bounded contexts that group governed operational resources and system-local content
+- `actions` -- stable business verbs exposed or consumed by systems
+- `entities` -- durable business nouns and their semantic links
+- `resources` -- governance-only workflow, agent, integration, and script descriptors
+- `knowledge` -- playbooks, strategies, references, and graph-governing links
+
 System-local operational catalogs live under `System.ontology.catalogTypes`, including pipeline, stage, template, template-step, status-flow, and status records. System-local settings live in `System.config`. The legacy compound and status domains should not be used for new authoring.
-
-## Authoring and Resolution
-
-- `defineOrganizationModel()` is a typed authoring helper.
-- `resolveOrganizationModel(partial)` deep-merges a partial override into `DEFAULT_ORGANIZATION_MODEL` and validates the result.
-- `createFoundationOrganizationModel(partial)` resolves the canonical model and returns template-facing helpers.
-- Plain objects merge recursively.
-- Id-keyed domain maps merge additively by key.
-- Arrays replace defaults.
-
-## Referential Integrity
-
-`OrganizationModelSchema` validates:
-
-- unique System IDs
-- ancestor existence for dotted System IDs and `parentSystemId`
-- UI path rules for Systems with UI presence
-- valid sidebar positions
-- reality-domain cross references such as offering target segments and role reporting lines
-- system, resource, role, knowledge, and goal cross references used by resource governance
-
-`DeploymentSpec` remains the runtime/deploy assembly around these descriptors. It is not the source of resource identity.
-
-## Provider Integration
-
-`ElevasisSystemsProvider` uses the organization model to:
-
-1. validate each manifest's `systemId`
-2. resolve effective system access
-3. derive sidebar entries from `navigation.sidebar`
-4. expose shell helpers such as `childrenOf`, `ancestorsOf`, and `findByPath`
-5. bridge the operations graph into shared UI
-
-## Published Package
-
-`@elevasis/core` exposes a curated browser-safe surface:
-
-- root barrel
-- `./organization-model`
-
-The organization graph builder remains monorepo-internal until there is a concrete external contract need.
-
-## Verification
-
-```bash
-pnpm --filter @repo/core test -- organization-model
-pnpm --filter @repo/core build:publish
-pnpm -C external/_template/core test
-```
+
+## Authoring and Resolution
+
+- `defineOrganizationModel()` is a typed authoring helper.
+- `resolveOrganizationModel(partial)` deep-merges a partial override into `DEFAULT_ORGANIZATION_MODEL` and validates the result.
+- `createFoundationOrganizationModel(partial)` resolves the canonical model and returns template-facing helpers.
+- Plain objects merge recursively.
+- Id-keyed domain maps merge additively by key.
+- Arrays replace defaults.
+
+## Referential Integrity
+
+`OrganizationModelSchema` validates:
+
+- unique System IDs
+- ancestor existence for dotted System IDs and `parentSystemId`
+- UI path rules for Systems with UI presence
+- valid sidebar positions
+- reality-domain cross references such as offering target segments and role reporting lines
+- system, resource, role, knowledge, and goal cross references used by resource governance
+
+`DeploymentSpec` remains the runtime/deploy assembly around these descriptors. It is not the source of resource identity.
+
+## Provider Integration
+
+`ElevasisSystemsProvider` uses the organization model to:
+
+1. validate each manifest's `systemId`
+2. resolve effective system access
+3. derive sidebar entries from `navigation.sidebar`
+4. expose shell helpers such as `childrenOf`, `ancestorsOf`, and `findByPath`
+5. bridge the operations graph into shared UI
+
+## Published Package
+
+`@elevasis/core` exposes a curated browser-safe surface with six subpaths:
+
+- `.` (root barrel)
+- `./auth`
+- `./test-utils`
+- `./organization-model`
+- `./entities`
+- `./knowledge`
+
+Only these subpaths are the legitimate published contract; any other `@repo/core/<subpath>` (`/server`, `/platform`, `/execution`, `/commands`, `/operations`, `/resilience`, `/supabase`, ...) is workspace-internal and not part of the SDK surface. The organization graph builder remains monorepo-internal until there is a concrete external contract need.
+
+## Verification
+
+```bash
+pnpm --filter @repo/core test -- organization-model
+pnpm --filter @repo/core build:publish
+pnpm -C external/_template/core test
+```

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

@@ -31,19 +31,18 @@ Layer 3: Sync Verification (pnpm sync:verify)
 
 ## Layer 1: Source Generation
 
-`pnpm scaffold:sync` is the meta-script that regenerates all derived documentation and validates the output. It chains seven sub-scripts:
+`pnpm scaffold:sync` is the meta-script that regenerates all derived documentation and validates the output. It chains six sub-scripts:
 
-| Script                 | Input                                                                                                                 | Output                                                                                                     |
-| ---------------------- | --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
-| `scaffold:generate`    | Scaffold contract and feature-registry sources                                                                        | `packages/core/src/reference/_generated/**`, `packages/ui/src/scaffold/_generated/feature-registry.md`     |
-| `knowledge:generate`   | Elevasis core knowledge nodes and UI knowledge body sources                                                           | Generated knowledge nodes and UI knowledge bodies                                                          |
-| `gen:sdk-catalog`      | SDK catalog source definitions                                                                                         | SDK catalog artifacts                                                                                      |
-| `gen:sdk-adapters`     | SDK adapter definitions                                                                                                | SDK adapter artifacts                                                                                      |
-| `copy-docs`            | SDK docs, package-owned reference docs, scaffold docs, and `_template/.claude` config                                  | `packages/sdk/reference/**` copied docs and scaffold reference bundle                                       |
-| `sdk-ref:generate`     | SDK manifest and navigation sources                                                                                    | `packages/sdk/reference/_reference-manifest.json`, `packages/sdk/reference/_navigation.md`                  |
-| `sdk-ref:check`        | Generated SDK reference artifacts                                                                                      | Freshness validation for `packages/sdk/reference/_reference-manifest.json` and `_navigation.md`             |
+| Script               | Input                                                                                 | Output                                                                                                 |
+| -------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
+| `scaffold:generate`  | Scaffold contract and feature-registry sources                                        | `packages/core/src/reference/_generated/**`, `packages/ui/src/scaffold/_generated/feature-registry.md` |
+| `knowledge:generate` | Elevasis core knowledge nodes and UI knowledge body sources                           | Generated knowledge nodes and UI knowledge bodies                                                      |
+| `gen:sdk-catalog`    | SDK catalog source definitions                                                        | SDK catalog artifacts                                                                                  |
+| `gen:sdk-adapters`   | SDK adapter definitions                                                               | SDK adapter artifacts                                                                                  |
+| `copy-docs`          | SDK docs, package-owned reference docs, scaffold docs, and `_template/.claude` config | `packages/sdk/reference/**` copied docs, `_reference-manifest.json`, and `_navigation.md`              |
+| `sdk-ref:check`      | Generated SDK reference artifacts                                                     | Freshness validation for `packages/sdk/reference/_reference-manifest.json` and `_navigation.md`        |
 
-The final `sdk-ref:check` step validates that the reference artifacts are consistent. Exit 1 if drifted.
+`copy-docs` (`packages/sdk/scripts/copy-reference-docs.mjs`) atomically regenerates `_reference-manifest.json` and `_navigation.md` itself as its own Phase 5, via the same `buildAllArtifacts()`/`writeArtifacts()` functions the standalone `sdk-ref:generate` script runs -- so there is no separate `sdk-ref:generate` step in this chain; running it again after `copy-docs` would just recompute an identical result. The final `sdk-ref:check` step validates that the reference artifacts are consistent. Exit 1 if drifted.
 
 ### Trigger Points
 
@@ -63,12 +62,12 @@ Drift is healed at the moment it would otherwise leak downstream. This is cheape
 `/external sync` now treats the scaffold registry as the execution contract rather than relying on tier prose alone.
 The canonical ownership vocabulary is:
 
-| Category      | Strategy examples                 | Meaning                                                             |
-| ------------- | --------------------------------- | ------------------------------------------------------------------- |
-| `replace`     | `replace-all`                     | Template-managed surface; copy from template baseline               |
+| Category      | Strategy examples                          | Meaning                                                             |
+| ------------- | ------------------------------------------ | ------------------------------------------------------------------- |
+| `replace`     | `replace-all`                              | Template-managed surface; copy from template baseline               |
 | `merge`       | `merge-baseline`, `preserve-on-divergence` | Merge-aware surface; preserve project customizations where required |
-| `never-touch` | `verify-only`                     | Project-owned surface; planner may report drift but never writes    |
-| `generated`   | `generated-freshness`             | Generated surface; verify/regen instead of copying                  |
+| `never-touch` | `verify-only`                              | Project-owned surface; planner may report drift but never writes    |
+| `generated`   | `generated-freshness`                      | Generated surface; verify/regen instead of copying                  |
 
 Current command helpers:
 
@@ -127,7 +126,7 @@ The external skill doc (`.claude/skills/external/SKILL.md`) remains the workflow
 ```bash
 pnpm sync:verify              # Post-sync assertion (exit 1 on failures)
 pnpm sync:verify --pre         # Pre-sync drift report (always exit 0)
-pnpm sync:verify -- ZentaraHQ  # Single project
+pnpm sync:verify -- nirvana-marketing  # Single project
 ```
 
 ### Integration Points

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

@@ -25,24 +25,24 @@ Scaffold docs are co-located with their owning package and copied into the SDK r
 
 ### Source-to-Destination Map
 
-| Content                     | Source                                                          | SDK Reference Destination                     |
-| --------------------------- | --------------------------------------------------------------- | --------------------------------------------- |
-| Organization Model          | `packages/core/src/organization-model/organization-model.mdx`   | `scaffold/core/organization-model.mdx`        |
-| Organization Graph          | `packages/core/src/organization-model/organization-graph.mdx`   | `scaffold/core/organization-graph.mdx`        |
-| Glossary                    | `packages/core/src/reference/glossary.md`                       | `scaffold/reference/glossary.md`              |
-| Contracts (auto-gen)        | `packages/core/src/reference/_generated/contracts.md`           | `scaffold/reference/contracts.md`             |
+| Content                                  | Source                                                                    | SDK Reference Destination                             |
+| ---------------------------------------- | ------------------------------------------------------------------------- | ----------------------------------------------------- |
+| Organization Model                       | `packages/core/src/organization-model/organization-model.mdx`             | `scaffold/core/organization-model.mdx`                |
+| Organization Graph                       | `packages/core/src/organization-model/organization-graph.mdx`             | `scaffold/core/organization-graph.mdx`                |
+| Glossary                                 | `packages/core/src/reference/glossary.md`                                 | `scaffold/reference/glossary.md`                      |
+| Contracts (auto-gen)                     | `packages/core/src/reference/_generated/contracts.md`                     | `scaffold/reference/contracts.md`                     |
 | System Interface Capabilities (auto-gen) | `packages/core/src/reference/_generated/system-interface-capabilities.md` | `scaffold/reference/system-interface-capabilities.md` |
-| UI Recipes                  | `packages/ui/src/scaffold/recipes.md`                           | `scaffold/ui/recipes.md`                      |
-| System Flags & Gating       | `packages/ui/src/scaffold/feature-flags-and-gating.md`          | `scaffold/ui/feature-flags-and-gating.md`     |
-| Customization               | `packages/ui/src/scaffold/customization.md`                     | `scaffold/ui/customization.md`                |
-| System Shell                | `packages/ui/src/scaffold/feature-shell.mdx`                    | `scaffold/ui/feature-shell.mdx`               |
-| Composition & Extensibility | `packages/ui/src/scaffold/composition-extensibility.mdx`        | `scaffold/ui/composition-extensibility.mdx`   |
-| System Registry (auto-gen)  | `packages/ui/src/scaffold/_generated/feature-registry.md`       | `scaffold/reference/feature-registry.md`      |
-| Scaffold Index              | `packages/sdk/docs/scaffold/index.mdx`                          | `scaffold/index.mdx`                          |
-| Pathway Recipes             | `packages/sdk/docs/scaffold/recipes/`                           | `scaffold/recipes/`                           |
-| Workflow Recipes            | `packages/sdk/docs/scaffold/operations/workflow-recipes.md`     | `scaffold/operations/workflow-recipes.md`     |
-| Propagation Pipeline        | `packages/sdk/docs/scaffold/operations/propagation-pipeline.md` | `scaffold/operations/propagation-pipeline.md` |
-| This doc                    | `packages/sdk/docs/scaffold/operations/scaffold-maintenance.md` | `scaffold/operations/scaffold-maintenance.md` |
+| UI Recipes                               | `packages/ui/src/scaffold/recipes.md`                                     | `scaffold/ui/recipes.md`                              |
+| System Flags & Gating                    | `packages/ui/src/scaffold/feature-flags-and-gating.md`                    | `scaffold/ui/feature-flags-and-gating.md`             |
+| Customization                            | `packages/ui/src/scaffold/customization.md`                               | `scaffold/ui/customization.md`                        |
+| System Shell                             | `packages/ui/src/scaffold/feature-shell.mdx`                              | `scaffold/ui/feature-shell.mdx`                       |
+| Composition & Extensibility              | `packages/ui/src/scaffold/composition-extensibility.mdx`                  | `scaffold/ui/composition-extensibility.mdx`           |
+| System Registry (auto-gen)               | `packages/ui/src/scaffold/_generated/feature-registry.md`                 | `scaffold/reference/feature-registry.md`              |
+| Scaffold Index                           | `packages/sdk/docs/scaffold/index.mdx`                                    | `scaffold/index.mdx`                                  |
+| Pathway Recipes                          | `packages/sdk/docs/scaffold/recipes/`                                     | `scaffold/recipes/`                                   |
+| Workflow Recipes                         | `packages/sdk/docs/scaffold/operations/workflow-recipes.md`               | `scaffold/operations/workflow-recipes.md`             |
+| Propagation Pipeline                     | `packages/sdk/docs/scaffold/operations/propagation-pipeline.md`           | `scaffold/operations/propagation-pipeline.md`         |
+| This doc                                 | `packages/sdk/docs/scaffold/operations/scaffold-maintenance.md`           | `scaffold/operations/scaffold-maintenance.md`         |
 
 ---
 
@@ -65,7 +65,8 @@ Output: `packages/core/src/reference/_generated/contracts.md`
 Generated by `scripts/monorepo/generate-scaffold-contracts.js` from:
 
 - `packages/core/src/organization-model/domains/systems.ts` -- `SYSTEM_INTERFACE_PROFILES`
-- `packages/core/src/business/acquisition/ontology-validation.ts` -- derived-readiness validation constants and checks
+- `packages/core/src/organization-model/readiness/` -- generic derived-readiness engine (`computeInterfaceReadiness`)
+- `packages/core/src/business/acquisition/ontology-validation.ts` -- built-in lead-gen/CRM readiness contracts and profile registration
 
 Output: `packages/core/src/reference/_generated/system-interface-capabilities.md`
 
@@ -99,12 +100,13 @@ Generated files should never be edited manually. If the output is wrong, fix the
 
 ## SDK Build Pipeline (Reference Copy)
 
-`packages/sdk/scripts/copy-reference-docs.mjs` runs during `pnpm --filter @elevasis/sdk build` and has four phases:
+`packages/sdk/scripts/copy-reference-docs.mjs` runs during `pnpm --filter @elevasis/sdk build` (and as the `copy-docs` root script) and has five phases:
 
 1. **Phase 1:** Copies SDK public docs from `apps/docs/content/docs/sdk/` with link rewriting and MDX escape stripping
 2. **Phase 2:** Copies package-owned reference docs declared in reference manifests
 3. **Phase 3:** Copies scaffold docs from co-located package sources using the `SCAFFOLD_COPIES` map
-4. **Phase 4:** Copies `external/_template/.claude` into `packages/sdk/reference/claude-config` for tenant-facing agent configuration
+4. **Phase 4:** Generates a pointer doc (`claude-config.md`) to the tenant's own `.claude/` config instead of bundling it wholesale
+5. **Phase 5 (F14):** Atomically regenerates `_reference-manifest.json` and `_navigation.md` via the same `buildAllArtifacts()`/`writeArtifacts()` functions the standalone `sdk-ref:generate` script runs -- this happens after the wipe-and-recopy above because the orphan-reachability check inside `buildAllArtifacts()` walks the output directory. This closes the window where `packages/sdk/reference/` could sit without those two files between a `copy-docs` run and a separate `sdk-ref:generate` run, so a chain that already runs `copy-docs` never needs a following `sdk-ref:generate` step -- it would just recompute an identical result.
 
 The output lands in `packages/sdk/reference/` which is included in the npm package's `files` array. External projects access it via `operations/node_modules/@elevasis/sdk/reference/`.