@elevasis/sdk 1.37.0 → 1.39.0

package/reference/claude-config/skills/git-sync/SKILL.md

@@ -1,126 +1,166 @@
----
-name: git-sync
-description: Pull latest changes, surface new sync notes, install when needed, and run baseline verification without auto-reconciling template drift
----
-
-# Git Sync
-
-Pull the latest upstream changes for this project, detect any newly introduced template sync notes, install dependencies when the pull changed package baselines, and run the baseline verification flow.
-
-**Usage:** `/git-sync`
-
-Use this when:
-
-- you just pulled a release-train update from the template repo
-- the branch may include dependency or scaffold baseline changes
-- you want the current sync-note guidance before making any manual reconciliation edits
-
-This command is intentionally narrower than template reconciliation. It stops after pull, install, verification, and note surfacing. It never auto-overwrites project-owned files.
-
-## Sync Notes Contract
-
-Downstream release guidance lives in `.claude/sync-notes/`.
-
-- Operative note files are named `YYYY-MM-DD-<slug>.md`
-- `README.md` documents the contract and is ignored by note detection
-- Notes are append-only release guidance; do not rewrite old note filenames after they ship
-- Every operative note uses these exact headings:
-  - `## Why this note exists`
-  - `## Applies to`
-  - `## Required actions`
-  - `## Verification`
-  - `## Not handled by /git-sync`
-
-## Process
-
-### Step 1: Check for Uncommitted Changes
-
-```bash
-git status --short
-```
-
-If the worktree is dirty, stop and tell the user to commit, stash, or discard changes first. Do not pull on top of local edits.
-
-### Step 2: Snapshot Current Sync Notes
-
-Capture the current operative note filenames before pulling:
-
-```bash
-git ls-files ".claude/sync-notes/*.md"
-```
-
-Ignore `README.md` when building the pre-pull note set.
-
-### Step 3: Pull Latest Changes
-
-```bash
-git pull --rebase
-```
-
-If the pull conflicts, stop and report the conflict. Do not attempt auto-resolution.
-
-### Step 4: Detect Whether Install Is Required
-
-If the pull changed any dependency baseline files, run a fresh install:
-
-```bash
-git diff --name-only HEAD@{1} HEAD -- package.json pnpm-lock.yaml pnpm-workspace.yaml ui/package.json operations/package.json shared/package.json
-```
-
-If the diff is non-empty:
-
-```bash
-pnpm install
-```
-
-If none of those files changed, skip install and report that the dependency baseline was unchanged.
-
-### Step 5: Run Baseline Verification
-
-Run the standard project verification flow:
-
-```bash
-pnpm -C ui check-types
-pnpm -C ui build
-pnpm -C operations check
-pnpm -C operations check-types
-```
-
-Stop on the first failure and report it clearly.
-
-### Step 6: Surface Newly Introduced Sync Notes
-
-Build the post-pull operative note set and compare it to the pre-pull set. Any newly added note filename is considered unread guidance for this pull.
-
-When new notes exist:
-
-- print each new note filename
-- summarize the `## Required actions`, `## Verification`, and `## Not handled by /git-sync` sections
-- tell the user exactly which manual follow-up remains
-
-When no new notes exist, say so explicitly.
-
-### Step 7: Stop Before Reconciliation
-
-`/git-sync` ends after pull, optional install, verification, and note surfacing.
-
-It does **not**:
-
-- run registry/template reconciliation
-- overwrite project-owned files
-- resolve downstream migration conflicts
-- treat a passing baseline verify as proof that manual follow-up is complete
-
-If a sync note or the pulled diff requires project-specific changes, leave those as an explicit next step.
-
-## Report
-
-```text
-Git Sync Complete
-=================
-Git:        pulled (<branch>)
-Install:    ran | skipped (no dependency baseline changes)
-Verify:     PASS | FAIL at <step>
-Sync notes: none | 2026-04-22-example-change.md
-Next step:  manual reconciliation required | none
-```
+---
+name: git-sync
+description: Pull latest changes, surface new sync notes, install when needed, and run baseline verification without auto-reconciling template drift
+---
+
+# Git Sync
+
+Pull the latest upstream changes for this project, detect any newly introduced template sync notes, install dependencies when the pull changed package baselines, and run the baseline verification flow.
+
+**Usage:** `/git-sync`
+
+Use this when:
+
+- you just pulled a release-train update from the template repo
+- the branch may include dependency or scaffold baseline changes
+- you want the current sync-note guidance before making any manual reconciliation edits
+
+This command is intentionally narrower than template reconciliation. It stops after pull, install, verification, and note surfacing. It never auto-overwrites project-owned files.
+
+## Sync Notes Contract
+
+Downstream release guidance lives in `.claude/sync-notes/`.
+
+- Operative note files are named `YYYY-MM-DD-<slug>.md`
+- `README.md` documents the contract and is ignored by note detection
+- Notes are append-only release guidance; do not rewrite old note filenames after they ship
+- Every operative note uses these exact headings:
+  - `## Why this note exists`
+  - `## Applies to`
+  - `## Required actions`
+  - `## Verification`
+  - `## Not handled by /git-sync`
+
+## Process
+
+### Step 1: Check for Uncommitted Changes
+
+```bash
+git status --short
+```
+
+If the worktree is dirty, stop and tell the user to commit, stash, or discard changes first. Do not pull on top of local edits.
+
+### Step 2: Snapshot Current Sync Notes
+
+Capture the current operative note filenames before pulling:
+
+```bash
+git ls-files ".claude/sync-notes/*.md"
+```
+
+Ignore `README.md` when building the pre-pull note set.
+
+### Step 3: Pull Latest Changes
+
+```bash
+git pull --rebase
+```
+
+If the pull conflicts, stop and report the conflict. Do not attempt auto-resolution.
+
+### Step 4: Detect Whether Install Is Required
+
+If the pull changed any dependency baseline files, run a fresh install:
+
+```bash
+git diff --name-only HEAD@{1} HEAD -- package.json pnpm-lock.yaml pnpm-workspace.yaml ui/package.json operations/package.json core/package.json
+```
+
+If the diff is non-empty:
+
+```bash
+pnpm install
+```
+
+If none of those files changed, skip install and report that the dependency baseline was unchanged.
+
+### Step 5: Verify the Installed SDK Bundle
+
+Tenant `.claude/` files (skills, rules pointers, sync notes) arrive via this git pull. The canonical rule bodies those pointers resolve to (`operations/node_modules/@elevasis/sdk/reference/rules/*.md`) arrive on a separate channel: the published npm tarball, pulled in by `pnpm install`. These two channels can silently disagree -- a pull can land new `.claude/` pointers aimed at rule files the installed SDK does not have yet. Check for that gap explicitly:
+
+1. **Confirm the bundle exists:**
+
+   ```bash
+   ls operations/node_modules/@elevasis/sdk/package.json
+   ```
+
+   If missing, the SDK is not installed at all -- run `pnpm install` and re-check before continuing.
+
+2. **Read the installed version:**
+
+   ```bash
+   node -p "require('./operations/node_modules/@elevasis/sdk/package.json').version"
+   ```
+
+3. **Read the declared range:**
+
+   ```bash
+   node -p "require('./operations/package.json').dependencies['@elevasis/sdk']"
+   ```
+
+   Compare the installed version against the declared semver range (e.g. `^1.37.0`). If the installed version does not satisfy the declared range -- most commonly because it is behind (older than the range allows) -- the lockfile and `node_modules` are out of sync with the manifest.
+
+4. **Confirm the rules bundle is present and non-empty:**
+
+   ```bash
+   ls operations/node_modules/@elevasis/sdk/reference/rules/
+   ```
+
+   An empty or missing directory means the tenant's `.claude/rules/*.md` compatibility pointers have nothing to resolve to, even if the package itself is present.
+
+**If the installed version is behind the declared range, or the rules directory is missing/empty:** run `pnpm install`, then repeat steps 1-4 to confirm the gap is closed. Report the before/after versions.
+
+**This step reports and stops -- it does not auto-reconcile template drift.** If after a fresh install the installed version still does not satisfy the declared range (e.g. the range itself needs bumping), or the rules directory is still empty, surface that as an explicit manual-reconciliation item in the final report. Do not attempt to hand-edit `operations/package.json` version ranges here.
+
+### Step 6: Run Baseline Verification
+
+Run the standard project verification flow:
+
+```bash
+pnpm -C ui check-types
+pnpm -C ui build
+pnpm -C operations check
+pnpm -C operations check-types
+```
+
+Stop on the first failure and report it clearly.
+
+### Step 7: Surface Newly Introduced Sync Notes
+
+Build the post-pull operative note set and compare it to the pre-pull set. Any newly added note filename is considered unread guidance for this pull.
+
+When new notes exist:
+
+- print each new note filename
+- summarize the `## Required actions`, `## Verification`, and `## Not handled by /git-sync` sections
+- tell the user exactly which manual follow-up remains
+
+When no new notes exist, say so explicitly.
+
+### Step 8: Stop Before Reconciliation
+
+`/git-sync` ends after pull, optional install, verification, and note surfacing.
+
+It does **not**:
+
+- run registry/template reconciliation
+- overwrite project-owned files
+- resolve downstream migration conflicts
+- treat a passing baseline verify as proof that manual follow-up is complete
+
+If a sync note or the pulled diff requires project-specific changes, leave those as an explicit next step.
+
+## Report
+
+```text
+Git Sync Complete
+=================
+Git:         pulled (<branch>)
+Install:     ran | skipped (no dependency baseline changes)
+SDK bundle:  <installed-version> satisfies <declared-range> | BEHIND (installed <x> < declared <y>) | reinstalled -> now satisfies
+Rules bundle: present (<n> files) | MISSING/EMPTY
+Verify:      PASS | FAIL at <step>
+Sync notes:  none | 2026-04-22-example-change.md
+Next step:   manual reconciliation required | none
+```

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

@@ -265,18 +265,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 /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`                                                                                      |
+| 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 `operations/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`                                                                                      |
 
 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
@@ -340,7 +340,7 @@ Current template placement convention:
 
 `system.apiInterface` is adopt-only in tenant projects. It declares intent to adopt a platform-provided API capability from the installed `@elevasis/core` / `@elevasis/sdk` version; it is not a tenant extension point.
 
-Use only readiness profiles listed in `node_modules/@elevasis/sdk/reference/scaffold/reference/system-interface-capabilities.md`. The profile also fixes the required System path, such as `sales.lead-gen` or `sales.crm`. Do not invent a profile, and do not repoint a cataloged profile to a custom System path.
+Use only readiness profiles listed in `operations/node_modules/@elevasis/sdk/reference/scaffold/reference/system-interface-capabilities.md`. The profile also fixes the required System path, such as `sales.lead-gen` or `sales.crm`. Do not invent a profile, and do not repoint a cataloged profile to a custom System path.
 
 Readiness is derived, not hand-authored. After the marker is present, the validator checks ontology object/catalog types, scoped resources and their `resource.ontology` bindings, and any required scoped topology `uses` grants. Lead-gen to CRM handoff is represented as a scoped topology relationship under the cross-System boundary invariant, not as an authored bridge object.
 
@@ -356,7 +356,7 @@ When opening a domain that uses a closed stage, status, or catalog vocabulary --
 prospecting, CRM, outreach, or another pipeline-like domain -- read the scaffold-shipped primer:
 
 ```bash
-node_modules/@elevasis/sdk/reference/spine/spine-primer.md
+operations/node_modules/@elevasis/sdk/reference/spine/spine-primer.md
 ```
 
 Use it to emit a short domain layering preview before the normal read, describe, or codify flow:
@@ -466,7 +466,7 @@ classification names a specific domain.
 - `/configure` -- legacy org-model editor (pre-absorption). Absorbed into this skill; all Codify
   and Toggle intents now route here. `/configure` vocabulary still works as a domain hint
   (e.g. "configure identity" is parsed as domain=identity, intent=Describe-or-Codify).
-- `node_modules/@elevasis/sdk/reference/spine/spine-primer.md` -- scaffold-shipped layering primer
+- `operations/node_modules/@elevasis/sdk/reference/spine/spine-primer.md` -- scaffold-shipped layering primer
   for stage/status/catalog vocabularies that coordinate business-profile entries, runtime progress,
   producers, and consumers in tenant projects.
 

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

@@ -183,7 +183,7 @@ path to the relevant sidebar section. Validate after the navigation write.
 `system.apiInterface` is adopt-only in tenant projects. Only add it when the system adopts a
 platform-provided API capability from the installed `@elevasis/core` / `@elevasis/sdk` version.
 Use only readiness profiles listed in
-`node_modules/@elevasis/sdk/reference/scaffold/reference/system-interface-capabilities.md`.
+`operations/node_modules/@elevasis/sdk/reference/scaffold/reference/system-interface-capabilities.md`.
 
 The profile also fixes the required System path — do not invent a profile or repoint a cataloged
 profile to a custom path.
@@ -234,4 +234,4 @@ pnpm elevasis-sdk om:scaffold:fill --gaps .elevasis/conformance-gaps.json --dry-
 - Codify Level-A ceremony: `.claude/skills/om/operations/codify-level-a.md`
 - Scaffold (guided new entries): `.claude/skills/om/operations/scaffold.md`
 - API interface readiness: "API Interface Readiness" section in `.claude/skills/om/SKILL.md`
-- Platform narrative guide + worked examples: `node_modules/@elevasis/sdk/reference/guides/building-systems.md` (if present)
+- Platform narrative guide + worked examples: `operations/node_modules/@elevasis/sdk/reference/guides/building-systems.md` (if present)

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

@@ -442,7 +442,7 @@ Footer shape:
 Related skill bindings
 - Domain: <domain>
 - Read or change business profile: /om <domain>
-- Layering primer: node_modules/@elevasis/sdk/reference/spine/spine-primer.md
+- Layering primer: operations/node_modules/@elevasis/sdk/reference/spine/spine-primer.md
 ```
 
 External projects do not expose monorepo-only architecture commands. Never suggest `/org-os`,