@elevasis/sdk 1.30.2 → 1.32.0

package/dist/test-utils/index.js

@@ -9200,7 +9200,13 @@ function computeInterfaceReadiness(model, request) {
       `System "${request.systemPath}" is missing.`,
       { ref: request.systemPath }
     );
-    return { ready: false, systemPath: request.systemPath, interfaceKey: request.interfaceKey, scopedResourceIds, issues };
+    return {
+      ready: false,
+      systemPath: request.systemPath,
+      interfaceKey: request.interfaceKey,
+      scopedResourceIds,
+      issues
+    };
   }
   if (systemInterface === void 0) {
     addReadinessIssue(
@@ -9210,7 +9216,13 @@ function computeInterfaceReadiness(model, request) {
       `System "${request.systemPath}" does not declare interface "${request.interfaceKey}".`,
       { path: readinessMarkerPath(request) }
     );
-    return { ready: false, systemPath: request.systemPath, interfaceKey: request.interfaceKey, scopedResourceIds, issues };
+    return {
+      ready: false,
+      systemPath: request.systemPath,
+      interfaceKey: request.interfaceKey,
+      scopedResourceIds,
+      issues
+    };
   }
   if (systemInterface.lifecycle !== "active") {
     addReadinessIssue(

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elevasis/sdk",
-  "version": "1.30.2",
+  "version": "1.32.0",
   "description": "SDK for building Elevasis organization resources",
   "type": "module",
   "bin": {
@@ -58,7 +58,7 @@
     "tsup": "^8.0.0",
     "typescript": "5.9.2",
     "zod": "^4.1.0",
-    "@repo/core": "0.39.0",
+    "@repo/core": "0.41.0",
     "@repo/eslint-config": "0.0.0",
     "@repo/typescript-config": "0.0.0"
   },

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

@@ -93,13 +93,13 @@ Auto-invocation is driven by frontmatter `description`, `metadata.pathPatterns`,
 Once invoked, classify the user's input into ONE of these buckets and dispatch the matching
 primitive. When two buckets fit, prefer the higher one (more specific → more general).
 
-| #   | Bucket                         | Trigger                                                                           | Dispatch                                                                        |
-| --- | ------------------------------ | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
-| 1   | Named knowledge/role/policy id | User names `knowledge.<id>`, `role.<id>`, `policy.<id>` directly                  | `om:cat <id>` for body, `om:describe <id>` for neighborhood                     |
-| 2   | Named system                   | User names a system path (`sales.crm`, `sales.lead-gen`)                          | `om:describe <id>`                                                              |
+| #   | Bucket                         | Trigger                                                                                          | Dispatch                                                                        |
+| --- | ------------------------------ | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- |
+| 1   | Named knowledge/role/policy id | User names `knowledge.<id>`, `role.<id>`, `policy.<id>` directly                                 | `om:cat <id>` for body, `om:describe <id>` for neighborhood                     |
+| 2   | Named system                   | User names a system path (`sales.crm`, `sales.lead-gen`)                                         | `om:describe <id>`                                                              |
 | 3   | Named ontology id              | Id contains `:object/`, `:action/`, `:event/`, `:catalog/`, `:interface/`, `:link/`, `:surface/` | `om:describe <id>` (or `om:ls /by-ontology/<id> --ids-only` then `om:cat` each) |
-| 4   | Kind keyword                   | "playbooks", "strategies", "all references", "list policies"                      | `om:ls /by-kind/<kind> --ids-only` then `om:cat` each                           |
-| 5   | Free-text discovery            | Anything else ("lead gen", "outreach", "what governs X?")                         | `om:search "<query>"` then drill into top hit with `om:describe`                |
+| 4   | Kind keyword                   | "playbooks", "strategies", "all references", "list policies"                                     | `om:ls /by-kind/<kind> --ids-only` then `om:cat` each                           |
+| 5   | Free-text discovery            | Anything else ("lead gen", "outreach", "what governs X?")                                        | `om:search "<query>"` then drill into top hit with `om:describe`                |
 
 On ambiguous input, default to **bucket 5 (search)** and surface the top hits. Codify and Toggle
 intents are write paths -- see "Write Power" below.
@@ -110,15 +110,15 @@ intents are write paths -- see "Write Power" below.
 
 All commands run with `pnpm exec elevasis-sdk <cmd>` (or the `om:` alias of the legacy `knowledge:` name).
 
-| Command            | Alias                | Purpose                                                                                                                   |
-| ------------------ | -------------------- | ------------------------------------------------------------------------------------------------------------------------- |
-| `om:search <q>`    | `knowledge:search`   | Universal keyword search across all 6 OM surfaces                                                                         |
-| `om:describe <id>` | `knowledge:describe` | Structured neighborhood view; kind auto-detected from id shape                                                            |
-| `om:cat <id>`      | `knowledge:cat`      | Raw MDX body of a knowledge node                                                                                          |
-| `om:ls <path>`     | `knowledge:ls`       | List nodes by mount path (`/by-system/`, `/by-kind/`, `/by-ontology/`, `/by-owner/`, `/graph/<id>/{governs,governed-by}`) |
-| `om:graph <id>`    | `knowledge:graph`    | Show outgoing + incoming graph edges                                                                                      |
-| `om:skills <id>`   | `knowledge:skills`   | Show callable invocations on graph neighbors                                                                              |
-| `om:generate`      | `knowledge:generate` | Regenerate `_generated/nodes.ts` from MDX sources                                                                         |
+| Command            | Alias                | Purpose                                                                                                                                                                                 |
+| ------------------ | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `om:search <q>`    | `knowledge:search`   | Universal keyword search across all 6 OM surfaces                                                                                                                                       |
+| `om:describe <id>` | `knowledge:describe` | Structured neighborhood view; kind auto-detected from id shape                                                                                                                          |
+| `om:cat <id>`      | `knowledge:cat`      | Raw MDX body of a knowledge node                                                                                                                                                        |
+| `om:ls <path>`     | `knowledge:ls`       | List by mount path. Enumeration: `/all-systems`, `/all-resources`, `/all-roles`. Scoped: `/by-system/`, `/by-kind/`, `/by-ontology/`, `/by-owner/`, `/graph/<id>/{governs,governed-by}` |
+| `om:graph <id>`    | `knowledge:graph`    | Show outgoing + incoming graph edges                                                                                                                                                    |
+| `om:skills <id>`   | `knowledge:skills`   | Show callable invocations on graph neighbors                                                                                                                                            |
+| `om:generate`      | `knowledge:generate` | Regenerate `_generated/nodes.ts` from MDX sources                                                                                                                                       |
 
 Common flags: `--json`, `--ids-only`, `--limit <n>`, `--kinds <list>`.
 
@@ -148,7 +148,22 @@ pnpm exec elevasis-sdk om:describe sales.crm:object/deal
 pnpm exec elevasis-sdk om:cat knowledge.outreach-playbook
 ```
 
-### Mount-path listings
+### Top-level enumeration (drill-down entry point)
+
+Start here when an agent needs to discover what this tenant's custom OM contains before
+building on it -- list everything in a domain, then narrow with `om:describe` / `om:cat`:
+
+```bash
+pnpm exec elevasis-sdk om:ls /all-systems              # every System (path + label)
+pnpm exec elevasis-sdk om:ls /all-resources            # every resource (id, kind, title)
+pnpm exec elevasis-sdk om:ls /all-roles                # every role (id, title)
+pnpm exec elevasis-sdk om:ls /all-systems --ids-only   # pipe paths into om:describe
+```
+
+These resolve against this tenant's resolved model -- they enumerate the project's own custom
+OM, not the platform's. Use `--json` for the wrapped envelope or `--ids-only` for piping.
+
+### Scoped mount-path listings
 
 ```bash
 pnpm exec elevasis-sdk om:ls /by-system/sales.crm
@@ -193,16 +208,18 @@ current task makes it relevant.
 Use this map whenever the task asks what something is, where it lives, what governs it, or
 what adjacent context may matter:
 
-| Question                           | Start here                                                                                    | Then inspect                                                               |
-| ---------------------------------- | --------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
-| What Systems exist?                | `om:ls /by-kind/system` or `core/config/organization-model.ts`                                | System IDs, parentage, lifecycle, UI metadata, and content                 |
-| What governs a System?             | `om:describe <system-id>` or `om:ls /by-system/<id>`                                          | system entry, governed knowledge, roles, policies, graph `governs` edges   |
-| What resources belong to a System? | the id-keyed `organizationModel.resources` map and `getResourcesForSystem(model, systemPath)` | use `{ includeDescendants: true }` only for parent-scope rollups           |
-| What can a System do?              | system action refs and the actions domain                                                     | `action.resourceId`, invocation metadata, affected entities, policies      |
-| What data does it own?             | entities domain                                                                               | owning System refs, state catalogs, entity links, emitted/projected events |
+| Question                           | Start here                                                                                                                        | Then inspect                                                                                                                         |
+| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| What Systems exist?                | `om:ls /all-systems`                                                                                                              | System IDs, parentage, lifecycle, UI metadata, and content                                                                           |
+| What resources exist?              | `om:ls /all-resources`                                                                                                            | resource ids, kinds, owning System refs                                                                                              |
+| What roles exist?                  | `om:ls /all-roles`                                                                                                                | role ids, titles, responsibilities                                                                                                   |
+| What governs a System?             | `om:describe <system-id>` or `om:ls /by-system/<id>`                                                                              | system entry, governed knowledge, roles, policies, graph `governs` edges                                                             |
+| What resources belong to a System? | the id-keyed `organizationModel.resources` map and `getResourcesForSystem(model, systemPath)`                                     | use `{ includeDescendants: true }` only for parent-scope rollups                                                                     |
+| What can a System do?              | system action refs and the actions domain                                                                                         | `action.resourceId`, invocation metadata, affected entities, policies                                                                |
+| What data does it own?             | entities domain                                                                                                                   | owning System refs, state catalogs, entity links, emitted/projected events                                                           |
 | Is a platform API interface ready? | the System's `apiInterface` marker and `node_modules/@elevasis/sdk/reference/scaffold/reference/system-interface-capabilities.md` | matching convention-locked System path, cataloged `readinessProfile`, derived resource ontology bindings, and scoped topology grants |
-| What UI surface exposes it?        | `navigation.sidebar` plus `SystemModule` manifests                                            | route files, surface targets, route-prefix modules, guards                 |
-| What knowledge applies?            | `om:ls /by-system/<id>` plus graph edges                                                      | `om:cat`, `om:graph`, `/graph/<id>/governed-by`                            |
+| What UI surface exposes it?        | `navigation.sidebar` plus `SystemModule` manifests                                                                                | route files, surface targets, route-prefix modules, guards                                                                           |
+| What knowledge applies?            | `om:ls /by-system/<id>` plus graph edges                                                                                          | `om:cat`, `om:graph`, `/graph/<id>/governed-by`                                                                                      |
 
 Do not treat any one read as a complete system snapshot. The OM is a set of related domain maps;
 follow the relationship that matches the work. Prefer structured helpers from

package/reference/claude-config/skills/om/operations/scaffold.md

@@ -91,7 +91,7 @@ Re-run the command without `--dry-run`. The CLI:
 Always run both gates after a scaffold write:
 
 ```bash
-pnpm -C operations check-types   # tsc --noEmit
+pnpm -C operations check-types   # type-check only, no emit
 pnpm -C operations check         # elevasis-sdk resource validator (incl. conformance gate)
 ```
 

package/reference/claude-config/sync-notes/2026-05-28-om-snapshot-sdk-workflow-config.md

@@ -0,0 +1,33 @@
+# OM snapshot stamp + `@elevasis/sdk` workflow-config promotion + `om:ls` enumeration
+
+## Why this note exists
+
+The 2026-05-28 SDK ship train publishes two coordinated package bumps and propagates two template-authored changes:
+
+- **`@elevasis/core` 0.40.0** — adds an optional `snapshotHash` field to the Organization Model schema (deploy-time + runtime OM snapshot-drift detection), a `STALE_OM_SNAPSHOT` validation member, and three new `@elevasis/core/knowledge` enumeration helpers (`listAllSystemsFlat`, `listAllResources`, `listAllRoles`).
+- **`@elevasis/sdk` 1.31.0** — promotes the generic `defineWorkflowConfig(resourceId, descriptors, actionRegistry)` helper out of the private platform package into the published SDK barrel, and adds `om:ls /all-systems | /all-resources | /all-roles` enumeration mounts to the tenant `elevasis-sdk om:ls` CLI.
+
+These change tenant-visible behavior (a new readiness diagnostic, new CLI mounts, and a new recommended deployment-binding pattern), so they cannot be left to silent dependency-baseline drift.
+
+## Applies to
+
+- All tenant SDK consumers depending on `@elevasis/core` and/or `@elevasis/sdk` (`external/nirvana-marketing`, and any project scaffolded from `external/_template`).
+- New scaffolds: pick up the `operations/src/metadata.ts` convention seed and (after the post-publish template authoring lands) the `projectDeploymentSpec`-based `operations/src/index.ts`.
+
+## Required actions
+
+1. **Adopt the bumped baselines.** `core/package.json` → `@elevasis/core` `^0.40.0`; `operations/package.json` → `@elevasis/core` `^0.40.0` and `@elevasis/sdk` `^1.31.0`. (Handled by the package-cascade entries in `_external-sync-prep.json`; verify, do not hand-edit.)
+2. **Redeploy operations after the bump** so the deployment writes a hash-stamped OM snapshot. Until you redeploy, the deployed snapshot carries no `snapshotHash` and the new drift diagnostic stays dormant. Stale-snapshot 503s now name the cause and the fix ("redeploy via `pnpm operations:deploy`") instead of the old opaque "not ready for this API surface".
+3. **New enumeration CLI is available after the `@elevasis/sdk` bump:** `pnpm -C external/<project>/operations exec elevasis-sdk om:ls /all-systems` (also `/all-resources`, `/all-roles`; supports `--json` / `--ids-only`). The tenant `/om` skill documents the drill-down surface.
+4. **Deployment-binding convention (informational for existing tenants; default for new scaffolds):** the template now deploys through `projectDeploymentSpec` with injected descriptor getters and derives per-workflow `config` via the promoted `defineWorkflowConfig`. `operations/src/**` is project-owned, so existing tenants are NOT auto-rewritten; adopt the pattern at your discretion. A typed `operations/src/metadata.ts` stub (triggers / integrations / human checkpoints) is seeded as the home for deployment mechanics.
+
+## Verification
+
+- `pnpm -C external/<project>/operations exec elevasis-sdk om:ls /all-systems` returns systems (not an empty list).
+- After redeploy, the system-interface readiness probe no longer returns a stale-snapshot 503; a deliberate source/deploy mismatch now surfaces `STALE_OM_SNAPSHOT` with an actionable message.
+- `pnpm sync:verify` and `pnpm external:verify-template-family` pass after the sync.
+
+## Not handled by /git-sync
+
+- The **operations redeploy** (action 2) is a deliberate deploy, not a file sync — `/git-sync` will not run it.
+- **Adopting `projectDeploymentSpec` / wiring `metadata.ts`** in an existing tenant's `operations/src/**` (project-owned) is a manual, tenant-authored migration; the sync only seeds it into fresh scaffolds.

package/reference/claude-config/sync-notes/2026-05-30-client-source-and-om-profiles.md

@@ -0,0 +1,39 @@
+# Client Source and OM Client Profiles
+
+## Why this note exists
+
+The client-system release train adds first-class client source support across the platform and introduces top-level Organization Model client profiles in `@elevasis/core/organization-model`.
+
+Template-derived projects need the updated package baselines and guidance before relying on the shared clients UI, SDK client commands, or OM client-profile helpers. Tenant-authored client profile content remains project-owned and is not auto-generated by sync.
+
+## Applies to
+
+- Projects that use the shared `@elevasis/ui` clients feature.
+- Projects that create or update clients through `elevasis-sdk client:create` or `elevasis-sdk client:update`.
+- Projects that intentionally author real client profiles in `core/config/organization-model.ts`.
+- Projects that deploy operations bundles against the updated `@elevasis/sdk` baseline.
+
+## Required actions
+
+1. Pull the package baseline updates from the prepared `/sdk ship` train.
+2. Use the first-class client `source` field for direct clients, for example `word_of_mouth`, instead of storing the primary source only in ad hoc metadata.
+3. If the project intentionally authors OM client profiles, key `organizationModel.clients` by the canonical production `public.clients.id`; the profile `id` must match the same UUID.
+4. Keep tenant-specific client profile records, prompts, branding, workspace links, and custom values project-owned. Do not copy Elevasis or another tenant's client profiles into this project.
+5. Treat `Organization > Clients` as the semantic home for real client profiles and `Systems > Client Management` as the operational platform system.
+
+## Verification
+
+Run the checks that match the project surface:
+
+```bash
+pnpm -C core check-types
+pnpm -C operations check-types
+pnpm -C operations check
+pnpm -C ui check-types
+```
+
+For projects that author OM client profiles, also run the project-local OM validation or deploy preflight before publishing operations resources.
+
+## Not handled by /git-sync
+
+`/git-sync` can propagate the updated package baselines and this guidance, but it does not create tenant-specific `clients` rows, choose client source values, author OM client profile content, or decide whether a project should model a client profile at all. Maintainers must make those project-specific data and authoring decisions intentionally.

package/reference/index.mdx

@@ -31,7 +31,7 @@ You do not need all three packages. A pure automation project needs only `@eleva
 
 ## Packages
 
-### @elevasis/sdk (v1.28.1)
+### @elevasis/sdk (v1.30.2)
 
 The primary developer package. Provides the TypeScript API for defining workflows and agents, the `elevasis-sdk` CLI for validation and deployment, and typed worker adapters for 25 platform and integration tools.
 
@@ -41,7 +41,7 @@ The primary developer package. Provides the TypeScript API for defining workflow
 
 See [@elevasis/sdk](sdk/index.mdx) for the full group overview, getting started guide, CLI reference, adapter catalog, and more.
 
-### @elevasis/core (v0.35.1)
+### @elevasis/core (v0.39.0)
 
 The shared contract layer. Exports Zod schemas and TypeScript types that are shared between the SDK, the UI, and the platform API. Useful when you need the typed contracts (organization model, entities, knowledge, auth) in a package that does not pull in the full SDK runtime.
 
@@ -51,7 +51,7 @@ The shared contract layer. Exports Zod schemas and TypeScript types that are sha
 
 See [@elevasis/core](core/index.mdx) for subpath details, browser/server split, and when to use it.
 
-### @elevasis/ui (v2.39.1)
+### @elevasis/ui (v2.42.0)
 
 The shared React feature-shell. Provides an `ElevasisProvider` and manifest-backed feature modules that a host UI embeds. Many peer dependencies are optional -- pull only what the features you use require.
 
@@ -60,3 +60,7 @@ The shared React feature-shell. Provides an `ElevasisProvider` and manifest-back
 **Peer deps:** React 19, Mantine 8.2.7, TanStack Query, TanStack Router, Zod 4.1, Zustand 5, cytoscape (many optional)
 
 See [@elevasis/ui](ui/index.mdx) for the provider model, feature modules, peer dependency details, and when to use it.
+
+## Authoring Note
+
+These pages have a dual surface. At SDK build time, `packages/sdk/scripts/copy-reference-docs.mjs` copies every `apps/docs/content/docs/sdk/**.mdx` into `packages/sdk/reference/`, which ships inside the npm package (`files: ["reference/"]`). The `external/_template/CLAUDE.md` points tenant-project agents at `node_modules/@elevasis/sdk/reference/` as their primary reference bundle. Drift in these docs does not just affect the public site -- it actively misleads every agent building a tenant project.

package/reference/scaffold/reference/contracts.md

@@ -42,6 +42,60 @@ export type OrganizationModelDomainMetadataByDomain = z.infer<typeof Organizatio
 export type OrganizationModelBranding = z.infer<typeof OrganizationModelBrandingSchema>
 ```
 
+### `ClientProfile`
+
+```typescript
+export type ClientProfile = z.infer<typeof ClientProfileSchema>
+```
+
+### `ClientProfileBranding`
+
+```typescript
+export type ClientProfileBranding = z.infer<typeof ClientProfileBrandingSchema>
+```
+
+### `ClientProfileIdentity`
+
+```typescript
+export type ClientProfileIdentity = z.infer<typeof ClientProfileIdentitySchema>
+```
+
+### `ClientProfileLinks`
+
+```typescript
+export type ClientProfileLinks = z.infer<typeof ClientProfileLinksSchema>
+```
+
+### `ClientProfilePrompts`
+
+```typescript
+export type ClientProfilePrompts = z.infer<typeof ClientProfilePromptsSchema>
+```
+
+### `ClientProfileSource`
+
+```typescript
+export type ClientProfileSource = z.infer<typeof ClientProfileSourceSchema>
+```
+
+### `ClientProfileStatus`
+
+```typescript
+export type ClientProfileStatus = z.infer<typeof ClientProfileStatusSchema>
+```
+
+### `ClientProfileWorkspace`
+
+```typescript
+export type ClientProfileWorkspace = z.infer<typeof ClientProfileWorkspaceSchema>
+```
+
+### `OrganizationModelClients`
+
+```typescript
+export type OrganizationModelClients = z.infer<typeof ClientProfilesDomainSchema>
+```
+
 ### `SalesPipeline`
 
 ```typescript

package/reference/sdk/concepts.mdx

@@ -22,7 +22,7 @@ This page covers core Elevasis concepts in plain English. It is the teaching voc
 | Handler       | The function inside a step that does the actual work. It receives input data and returns output data.                                                                                              |
 | Entry Point   | The first step that runs when a workflow is executed. Every workflow must have one.                                                                                                                |
 | Resource ID   | A unique lowercase name for your resource (e.g., `lead-scorer`, `send-welcome-email`). Must be unique within your organization.                                                                    |
-| Workspace     | Your Elevasis project directory. Contains resources (workflows and agents), documentation, and optionally a database connection and custom apps. Created by `elevasis-sdk init`.                   |
+| Workspace     | Your Elevasis project directory. Contains resources (workflows and agents), documentation, and optionally a database connection and custom apps.                                                   |
 | Data Table    | A table in your database (e.g., Supabase) that stores structured data your workflows can read and write. Defined in `data/schema.ts` as documentation for the agent.                               |
 
 ---