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