@elevasis/sdk 1.36.5 → 1.38.0

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

@@ -1,78 +1,78 @@
----
-name: explore
-description: Codebase exploration anchored to project documentation
----
-
-# Explore
-
-Codebase exploration anchored to project documentation.
-
-**Usage:** `/explore [area or question]`
-
-## Process
-
-### Step 0: OS-Vocab Classification
-
-Before orienting, scan the user's query for Organization OS terminology. If any of the following appear, classify the query as **OS-relevant** and follow the OS context steps below; otherwise skip to Step 1.
-
-**OS vocabulary triggers:**
-
-- System layer: `system`, `systems`, `SystemModule`, `system key`, `system gate`, `system access`, `gate`, `gating`, `access`, `enable`, `disable`
-- Shell / nav: `manifest`, `shell`, `sub-shell`, `sidebar`, `nav`, `navigation`, `route`
-- Auth / guards: `guard`, `SystemGuard`, `AdminGuard`, `ProtectedRoute`, `admin`
-- Org model: `organization`, `org model`, `organization model`, `domain`, `surface`
-- Foundations: `foundation`, `foundations`, `@core/`, `adapter`
-- Platform ops: `workflow`, `agent`, `deployment`, `resource`
-
-**If OS-relevant:**
-
-1. Read `.claude/rules/active-change-index.md` immediately. If the target area is flagged as under active refactor, surface the watch-area warning to the user before proceeding — include the "Load:" doc paths listed in that entry so investigation does not rely on stale scaffold prose.
-2. Build the OS context bundle to pass into Step 3:
-   - Always: `node_modules/@elevasis/sdk/reference/scaffold/reference/glossary.md`, `.claude/rules/active-change-index.md`, `.claude/rules/agent-start-here.md`
-   - Systems / Shell / Gating queries: add `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-flags-and-gating.md` + `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md`
-   - Workflow / Operations queries: add `.claude/rules/operations.md` + glob `operations/src/**`
-   - Organization-model queries: add `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` + `core/config/README.md`
-
-**OS layer → query intent map** (guides which reference docs the investigator loads first):
-
-| Query intent                             | Primary OS layers                | Key reference                                                                            |
-| ---------------------------------------- | -------------------------------- | ---------------------------------------------------------------------------------------- |
-| "Why doesn't my system show up?"         | Systems + UI Shell Runtime       | `glossary.md` (SystemModule, SystemGuard), `feature-flags-and-gating.md`                 |
-| "How do I add a nav item?"               | Systems + Toolkit                | `feature-flags-and-gating.md`, `contracts.md`                                            |
-| "How does admin gating work?"            | Systems + UI Shell Runtime       | `glossary.md` (AdminGuard, requiresAdmin, ProtectedRoute), `feature-flags-and-gating.md` |
-| "What runs when this workflow triggers?" | Platform Public API + Operations | `.claude/rules/operations.md`, `resources.md`                                            |
-| "Why does the foundations adapter fail?" | Foundations                      | `glossary.md` (domain vs surface, settings asymmetry), `core/config/README.md`    |
-
-### Step 1: Orient
-
-1. Read `.claude/rules/agent-start-here.md` for project structure, task-class routing, and boundary resolution
-2. Determine which domain the user's question falls into
-
-### Step 2: Load Domain Context
-
-Read the relevant doc(s) and source directories based on the area being explored. Use the Navigation table in `CLAUDE.md` for quick reference.
-
-For OS-relevant queries, also inject the OS context bundle assembled in Step 0 into the investigator's starting context.
-
-### Step 3: Investigate
-
-For targeted questions:
-
-- Use Grep to search for specific patterns, function names, or strings
-- Use Glob to find files by pattern
-- Read specific files for detailed understanding
-
-For broad exploration:
-
-- Dispatch a `general-purpose` subagent with the domain context and exploration question
-- The subagent should read files, trace data flow, and return a structured report
-- For OS-relevant queries, pass the preloaded OS context bundle so the subagent starts with terminology already resolved
-
-### Step 4: Report
-
-Present findings with:
-
-- Direct answers to the question
-- Relevant code locations (file:function format)
-- Connections to other parts of the system
-- Suggestions for related areas to explore (if relevant)
+---
+name: explore
+description: Codebase exploration anchored to project documentation
+---
+
+# Explore
+
+Codebase exploration anchored to project documentation.
+
+**Usage:** `/explore [area or question]`
+
+## Process
+
+### Step 0: OS-Vocab Classification
+
+Before orienting, scan the user's query for Organization OS terminology. If any of the following appear, classify the query as **OS-relevant** and follow the OS context steps below; otherwise skip to Step 1.
+
+**OS vocabulary triggers:**
+
+- System layer: `system`, `systems`, `SystemModule`, `system key`, `system gate`, `system access`, `gate`, `gating`, `access`, `enable`, `disable`
+- Shell / nav: `manifest`, `shell`, `sub-shell`, `sidebar`, `nav`, `navigation`, `route`
+- Auth / guards: `guard`, `SystemGuard`, `AdminGuard`, `ProtectedRoute`, `admin`
+- Org model: `organization`, `org model`, `organization model`, `domain`, `surface`
+- Foundations: `foundation`, `foundations`, `@core/`, `adapter`
+- Platform ops: `workflow`, `agent`, `deployment`, `resource`
+
+**If OS-relevant:**
+
+1. Read `.claude/rules/active-change-index.md` immediately. If the target area is flagged as under active refactor, surface the watch-area warning to the user before proceeding — include the "Load:" doc paths listed in that entry so investigation does not rely on stale scaffold prose.
+2. Build the OS context bundle to pass into Step 3:
+   - Always: `operations/node_modules/@elevasis/sdk/reference/scaffold/reference/glossary.md`, `.claude/rules/active-change-index.md`, `.claude/rules/agent-start-here.md`
+   - Systems / Shell / Gating queries: add `operations/node_modules/@elevasis/sdk/reference/scaffold/ui/feature-flags-and-gating.md` + `operations/node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md`
+   - Workflow / Operations queries: add `.claude/rules/operations.md` + glob `operations/src/**`
+   - Organization-model queries: add `operations/node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` + `core/config/README.md`
+
+**OS layer → query intent map** (guides which reference docs the investigator loads first):
+
+| Query intent                             | Primary OS layers                | Key reference                                                                            |
+| ---------------------------------------- | -------------------------------- | ---------------------------------------------------------------------------------------- |
+| "Why doesn't my system show up?"         | Systems + UI Shell Runtime       | `glossary.md` (SystemModule, SystemGuard), `feature-flags-and-gating.md`                 |
+| "How do I add a nav item?"               | Systems + Toolkit                | `feature-flags-and-gating.md`, `contracts.md`                                            |
+| "How does admin gating work?"            | Systems + UI Shell Runtime       | `glossary.md` (AdminGuard, requiresAdmin, ProtectedRoute), `feature-flags-and-gating.md` |
+| "What runs when this workflow triggers?" | Platform Public API + Operations | `.claude/rules/operations.md`, `resources.md`                                            |
+| "Why does the foundations adapter fail?" | Foundations                      | `glossary.md` (domain vs surface, settings asymmetry), `core/config/README.md`           |
+
+### Step 1: Orient
+
+1. Read `.claude/rules/agent-start-here.md` for project structure, task-class routing, and boundary resolution
+2. Determine which domain the user's question falls into
+
+### Step 2: Load Domain Context
+
+Read the relevant doc(s) and source directories based on the area being explored. Use the Navigation table in `CLAUDE.md` for quick reference.
+
+For OS-relevant queries, also inject the OS context bundle assembled in Step 0 into the investigator's starting context.
+
+### Step 3: Investigate
+
+For targeted questions:
+
+- Use Grep to search for specific patterns, function names, or strings
+- Use Glob to find files by pattern
+- Read specific files for detailed understanding
+
+For broad exploration:
+
+- Dispatch a `general-purpose` subagent with the domain context and exploration question
+- The subagent should read files, trace data flow, and return a structured report
+- For OS-relevant queries, pass the preloaded OS context bundle so the subagent starts with terminology already resolved
+
+### Step 4: Report
+
+Present findings with:
+
+- Direct answers to the question
+- Relevant code locations (file:function format)
+- Connections to other parts of the system
+- Suggestions for related areas to explore (if relevant)

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`,