@elevasis/sdk 1.18.0 → 1.20.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elevasis/sdk",
-  "version": "1.18.0",
+  "version": "1.20.0",
   "description": "SDK for building Elevasis organization resources",
   "type": "module",
   "bin": {
@@ -57,9 +57,9 @@
     "tsup": "^8.0.0",
     "typescript": "5.9.2",
     "zod": "^4.1.0",
-    "@repo/core": "0.19.0",
-    "@repo/eslint-config": "0.0.0",
-    "@repo/typescript-config": "0.0.0"
+    "@repo/core": "0.22.0",
+    "@repo/typescript-config": "0.0.0",
+    "@repo/eslint-config": "0.0.0"
   },
   "scripts": {
     "lint": "eslint src --max-warnings 0",

package/reference/_navigation.md

@@ -2,7 +2,7 @@
 
 Auto-generated from the package reference manifests.
 
-Package entries indexed: 54.
+Package entries indexed: 55.
 
 ## @elevasis/core / Core
 
@@ -90,6 +90,7 @@ Package entries indexed: 54.
 | Features SEO | `packages/ui/src/features/README.md` | Published SEO feature surface for downstream shells. | (not specified) |
 | Features Settings | `packages/ui/src/features/README.md` | Published settings feature surface for downstream shells. | (not specified) |
 | Features Knowledge | `packages/ui/src/features/README.md` | Published knowledge feature manifest for downstream shells. | (not specified) |
+| Features Clients | `packages/ui/src/features/README.md` | Published clients feature surface for downstream shells. | (not specified) |
 
 ## @elevasis/ui / Foundation
 

package/reference/_reference-manifest.json

@@ -379,6 +379,20 @@
       "referencePath": "packages/ui/src/features/README.md",
       "publishedExportPath": "./dist/features/knowledge/index.js"
     },
+    {
+      "packageName": "@elevasis/ui",
+      "packageDir": "packages/ui",
+      "subpath": "./features/clients",
+      "kind": "subpath",
+      "title": "Features Clients",
+      "description": "Published clients feature surface for downstream shells.",
+      "group": "Features",
+      "order": 12,
+      "sourcePath": "packages/ui/src/features/clients/index.ts",
+      "docPath": "packages/ui/src/features/README.md",
+      "referencePath": "packages/ui/src/features/README.md",
+      "publishedExportPath": "./dist/features/clients/index.js"
+    },
     {
       "packageName": "@elevasis/ui",
       "packageDir": "packages/ui",

package/reference/claude-config/registries/graph-skills.json

@@ -0,0 +1,4 @@
+{
+  "generatedBy": "generate-knowledge-nodes",
+  "domains": {}
+}

package/reference/claude-config/rules/agent-start-here.md

@@ -75,7 +75,7 @@ Use this order unless a more specific doc tells you otherwise:
 4. Read `identity.clientBrief` from the OrganizationModel (`core/config/organization-model.ts`) for organization context and naming.
 5. Read the relevant structural map:
    - Glob `node_modules/@elevasis/sdk/reference/` for published package surfaces
-   - Glob `operations/resources/**` for source, or run `pnpm elevasis-sdk project:list --pretty` for live DB state
+   - Read `operations/src/index.ts` for deployment assembly, `core/config/organization-model.ts` for resource descriptors, or run `pnpm elevasis-sdk project:list --pretty` for live DB state
 6. For feature integration, resource authoring, or UI customization tasks, read `node_modules/@elevasis/sdk/reference/scaffold/index.mdx` to find the canonical recipe or reference doc.
 7. Drill into the co-located local explainer for the abstraction boundary you are changing.
 8. Check the `.claude/rules/active-change-index.md` rule before trusting stable assumptions in areas that are under active architecture work.
@@ -142,7 +142,7 @@ Then inspect:
 
 Verify with:
 
-- Glob `operations/resources/**` for local source files, or run `pnpm elevasis-sdk project:list --pretty` for live DB state
+- Read `operations/src/index.ts` for deployment assembly, `core/config/organization-model.ts` for resource descriptors, or run `pnpm elevasis-sdk project:list --pretty` for live DB state
 - local SDK guidance in `.claude/skills/elevasis/SKILL.md`
 
 ### 3. Organization Model / Feature Access Work
@@ -163,7 +163,7 @@ Load first:
 Then inspect:
 
 - `core/config/organization-model.ts`
-- `core/config/organization-model.examples.ts` -- 5 reference patterns: branding override, CRM pipeline stage customization, lead-gen lifecycle customization, resource mapping registration, custom feature declaration. Not imported anywhere -- pure reference. Start here for the override pattern when extending the org model.
+- `core/config/organization-model.ts` -- Organization Model overrides plus Systems and Resources descriptors. Start here for feature labels, surface mapping, and resource identity/governance changes.
 - `ui/src/routes/__root.tsx`
 - `ui/src/lib/hooks/useFeatureAccess.ts`
 - relevant nav config files
@@ -181,7 +181,7 @@ Load first:
 
 - `operations/src/README.md`
 - `.claude/rules/active-change-index.md`
-- Glob `operations/resources/**` for source, or run `pnpm elevasis-sdk project:list --pretty` for live DB state
+- Read `operations/src/index.ts` for deployment assembly, `core/config/organization-model.ts` for resource descriptors, or run `pnpm elevasis-sdk project:list --pretty` for live DB state
 
 Then inspect:
 
@@ -257,7 +257,7 @@ If a hand-authored doc conflicts with source or published package docs, trust so
 
 ## Common Traps
 
-- Do not assume `operations/resources/**` is exhaustive without also checking `operations/src/index.ts` directly.
+- Do not assume feature directories are exhaustive without also checking `operations/src/index.ts` and `core/config/organization-model.ts` directly.
 - Do not assume placeholder knowledge is sufficient for real client context. Read `identity.clientBrief` from the OrganizationModel (`core/config/organization-model.ts`).
 - Do not trust stable docs blindly when `.claude/rules/active-change-index.md` flags related in-progress architecture work.
 - Do not write `resume_context` into task-doc frontmatter. DB is canonical; write via `project:task:save` or the inline editor in Command Center.

package/reference/claude-config/rules/deployment.md

@@ -14,7 +14,7 @@ pnpm -C operations run check-types  # TypeScript type-check
 pnpm -C operations run deploy       # Deploy to dev (only after both pass)
 ```
 
-`check` catches duplicate resourceIds, invalid step chains, broken relationships, and schema serialization issues. Same validation runs during deploy -- if `check` passes, deploy validation will pass.
+`check` catches duplicate resource IDs, OM descriptor/code mismatches, invalid step chains, broken relationships, and schema serialization issues. Same validation runs during deploy -- if `check` passes, deploy validation will pass.
 
 ## Dev vs Prod
 
@@ -32,7 +32,7 @@ Deploy accepts `--major`, `--minor`, `--patch` flags to bump the deployment vers
 ## What Gets Deployed
 
 1. **Bundle:** esbuild compiles `src/index.ts` + all dependencies into a single self-contained CJS file. No `node_modules` needed at runtime.
-2. **Metadata:** Resource definitions, Zod schemas (converted to JSON Schema), relationships, triggers.
+2. **Metadata:** Resource definitions, OM Resources descriptor bindings, Zod schemas (converted to JSON Schema), relationships, triggers.
 
 ## Environment
 
@@ -45,7 +45,8 @@ Deploy accepts `--major`, `--minor`, `--patch` flags to bump the deployment vers
 | Error                                    | Fix                                                     |
 | ---------------------------------------- | ------------------------------------------------------- |
 | `401: Invalid API key`                   | Check `ELEVASIS_PLATFORM_KEY` in `.env`                 |
-| `Duplicate resource ID`                  | Rename `resourceId` in the conflicting resource         |
+| `Duplicate resource ID`                  | Fix the duplicated OM Resource descriptor ID, then derive runtime `resourceId` from that descriptor |
+| `Missing OM Resource descriptor`         | Add the descriptor to `core/config/organization-model.ts` under `resources.entries` |
 | `Step references non-existent next step` | Fix the `next:` field in the step chain                 |
 | `Schema serialization failed`            | Simplify the Zod schema (warning, still deploys)        |
 | `No default export found`                | `src/index.ts` must `export default` a `DeploymentSpec` |

package/reference/claude-config/rules/frontend.md

@@ -17,8 +17,8 @@ paths:
 ## Silent-Break Gotchas
 
 - Route files vs layout files: `operations.tsx` is a layout (renders `<Outlet />`), `operations/my-page.index.tsx` is a page. Confusing the two breaks routing silently
-- `foundations/` cannot import React or `@elevasis/sdk/worker` -- it is runtime-agnostic shared types only
-- `@/*` resolves to `ui/src/*`, `@foundation/*` resolves to `foundations/*` -- never import from `operations/` (separate runtime)
+- `core/` cannot import React or `@elevasis/sdk/worker` -- it is runtime-agnostic shared types and organization configuration only
+- `@/*` resolves to `ui/src/*`, `@core/*` resolves to `core/*` -- never import from `operations/` (separate runtime)
 
 ## Stack Constraints
 

package/reference/claude-config/rules/operations.md

@@ -12,16 +12,16 @@ paths:
 
 The `operations/` directory contains platform resources and deployment metadata that deploy to the Elevasis platform. It is a standalone TypeScript project with its own `package.json`, `tsconfig.json`, and dependencies.
 
-**Discovering deployed resources:** Glob `operations/resources/**` for local source files, or run `pnpm elevasis-sdk project:list --pretty` against the live DB for the deployed surface. No static resource map exists -- the file system and CLI are authoritative.
+**Discovering deployed resources:** Read `operations/src/index.ts` for deployment assembly and `core/config/organization-model.ts` for the OM Resources descriptor catalog. Run `pnpm elevasis-sdk project:list --pretty` against the live DB for the deployed surface.
 
 ## Echo Workflow (Starter Example)
 
 **Location:** `operations/src/example/echo.ts`
 
-The echo workflow accepts a message string and returns it unchanged. Its purpose is the wiring, not the logic: input and output schemas are defined in `foundations/types/index.ts` and imported by both the workflow and the frontend.
+The echo workflow accepts a message string and returns it unchanged. Its purpose is the wiring, not the logic: input and output schemas are defined in `core/types/index.ts` and imported by both the workflow and the frontend.
 
 ```
-foundations/types/index.ts      -- defines echoInputSchema, echoOutputSchema
+core/types/index.ts             -- defines echoInputSchema, echoOutputSchema
 operations/src/example/echo.ts  -- imports schemas for workflow contract
 ui/src/routes/                  -- imports schemas for form validation and display
 ```
@@ -30,13 +30,15 @@ The workflow is registered in `operations/src/index.ts` as part of the `example`
 
 ## Adding a New Workflow
 
-1. **Define the contract in `foundations/`** -- Add Zod schemas and inferred types to `foundations/types/index.ts` (or a new file under `foundations/types/`).
-
-2. **Implement the workflow in `operations/src/`** -- Create a new directory under `operations/src/` for the feature. Export the workflow from its `index.ts` and register it in `operations/src/index.ts`.
-
-3. **Add the UI in `ui/src/routes/`** -- Create a new route file. Use TanStack Query to call the workflow execution endpoint. Import schemas from `@foundation/types` for validation and type inference.
-
-4. **Deploy and verify:**
+1. **Define the descriptor in `core/config/organization-model.ts`** -- Add the OM Resource descriptor under `resources.entries` so identity, System membership, owner role, and governance status are authored once.
+
+2. **Define the contract in `core/types/`** -- Add Zod schemas and inferred types to `core/types/index.ts` (or a new file under `core/types/`).
+
+3. **Implement the workflow in `operations/src/`** -- Create a new directory under `operations/src/` for the feature. Import the descriptor, derive runtime `resourceId` / `type` from it, export the workflow from its `index.ts`, and register it in `operations/src/index.ts`.
+
+4. **Add the UI in `ui/src/routes/`** -- Create a new route file. Use TanStack Query to call the workflow execution endpoint. Import schemas from `@core/types` for validation and type inference.
+
+5. **Deploy and verify:**
 
 ```bash
 pnpm -C operations check        # validate resource definitions
@@ -45,12 +47,14 @@ pnpm -C operations deploy       # deploy to dev
 
 ## Resource Registry
 
-`operations/src/index.ts` default-exports a `DeploymentSpec` with `version`, `workflows`, `agents`, and optional topology-oriented metadata such as `triggers`, `integrations`, `relationships`, `humanCheckpoints`, and `externalResources`. Each feature group exports `workflows` and `agents` arrays from its own `index.ts`, spread into the top-level spec.
+`operations/src/index.ts` default-exports a `DeploymentSpec` with `version`, `organizationModel`, `workflows`, `agents`, and optional topology-oriented metadata such as `triggers`, `integrations`, `relationships`, `humanCheckpoints`, and `externalResources`. Each feature group exports `workflows` and `agents` arrays from its own `index.ts`, spread into the top-level spec. `DeploymentSpec` assembles deployable behavior; it should not be treated as a second resource identity catalog.
 
 When you need breadth first, read:
 
-- `operations/src/README.md` for the source boundary and drill-down guidance
-- Glob `operations/resources/**` or run `pnpm elevasis-sdk project:list --pretty` for the live deployed surface
+- `operations/src/README.md` for the source boundary and drill-down guidance
+- `core/config/organization-model.ts` for descriptor identity and governance metadata
+- `operations/src/index.ts` for deployment assembly
+- `pnpm elevasis-sdk project:list --pretty` for the live deployed surface
 
 ## Commands
 

package/reference/claude-config/rules/organization-model.md

@@ -7,10 +7,10 @@ paths:
 
 # Organization Model Edit Guide
 
-`foundations/config/organization-model.ts` is the single source of truth for this
+`core/config/organization-model.ts` is the single source of truth for this
 project's organizational identity -- it encodes customers, offerings, roles, goals,
-features, statuses, and resource mappings that agents, workflows, and the UI shell all
-consume at runtime.
+features, statuses, Systems, and Resources descriptors that agents, workflows, and the
+UI shell all consume at runtime.
 
 ## Preferred Entry Point: `/knowledge`
 
@@ -24,7 +24,9 @@ Direct edits to `organization-model.ts` are discouraged. Instead, use `/knowledg
    is verified. On failure the file is rolled back automatically.
 
 Use `/knowledge <domain>` for targeted edits: `identity`, `customers`, `offerings`,
-`roles`, `goals`, `techStack`, `features`, or `labels`.
+`roles`, `goals`, `techStack`, `features`, or `labels`. Resource identity and
+governance metadata belong in `resources.entries`; operations code derives runtime
+`resourceId` / `type` from those descriptors.
 
 ## Runtime Validation
 
@@ -35,7 +37,7 @@ alone -- always let the ceremony run both checks before treating a change as com
 
 ## Extension Files
 
-New Zod extension files under `foundations/config/extensions/` are Level B codify
+New Zod extension files under `core/config/extensions/` are Level B codify
 operations. Route these through `/knowledge <domain>` as well -- the skill gates Level B
 to explicit user confirmation before scaffolding a new `.ts` file.
 

package/reference/claude-config/rules/organization-os.md

@@ -4,24 +4,26 @@ Organization OS is the semantic contract layer defining how organizations, featu
 
 ## Key Files in This Project
 
-- `foundations/config/organization-model.ts` -- project-specific org model definition (calls `defineOrganizationModel` + `resolveOrganizationModel`)
-- `foundations/config/organization-model.examples.ts` -- reference patterns for all 14 domains: branding, identity, customers, offerings, roles, goals, sales stages, prospecting stages, resource mappings with techStack, custom features, statuses, and open-placement navigation groups. Pure reference -- not imported anywhere. Read this when customizing the org model.
-- `foundations/types/entities.ts` -- typed entity contracts (Project, Deal, etc.). Extends `BaseProject`, `BaseDeal` from `@elevasis/core/entities` with project-specific metadata. Read this when authoring workflows that operate on these entities.
+- `core/config/organization-model.ts` -- project-specific org model definition, Systems, and Resources descriptor catalog (`organizationModel.resources.entries`)
+- `core/config/extensions/` -- project-owned entity extension schemas
+- `core/types/entities.ts` -- typed entity contracts (Project, Deal, etc.). Extends `BaseProject`, `BaseDeal` from `@elevasis/core/entities` with project-specific metadata. Read this when authoring workflows that operate on these entities.
 - `ui/src/routes/__root.tsx` -- wires `ElevasisFeaturesProvider` with `canonicalOrganizationModel`
 - `ui/src/app-config.ts` -- references the org model
 - `operations/src/index.ts` -- `DeploymentSpec` registry for workflows and agents
 
 ## Domain Overview
 
-As of the 2026-04-20 expansion, `OrganizationModel` contains 14 top-level domains:
+As of the 2026-05 resource-governance expansion, `OrganizationModel` includes platform configuration, organizational reality, and governance domains:
 
-**Platform configuration:** `features`, `branding`, `navigation`, `sales` (formerly `crm`), `prospecting` (formerly `leadGen`), `projects` (formerly `delivery`), `resourceMappings`
+**Platform configuration:** `features`, `branding`, `navigation`, `sales` (formerly `crm`), `prospecting` (formerly `leadGen`), `projects` (formerly `delivery`)
 
 **Organizational reality:** `identity`, `customers`, `offerings`, `roles`, `goals`
 
+**Governance:** `systems`, `resources`
+
 **Vibe layer:** `statuses`, `operations`
 
-The `resourceMappings` entries may carry an optional `techStack` extension (`platform`, `purpose`, `credentialStatus`, `isSystemOfRecord`) without introducing a new top-level domain.
+Resource identity is authored once in `resources.entries`. Operations imports those descriptors and derives runtime `resourceId` / `type` while assembling the `DeploymentSpec`.
 
 ### Domain Rename Note
 
@@ -73,18 +75,18 @@ All paths under `node_modules/@elevasis/sdk/reference/scaffold/`:
   - Vibe domain types: `OrganizationModelStatuses`, `OrganizationModelOperations`
   - TechStack: `TechStackEntrySchema`, `OrganizationModelTechStackEntry`
   - Use constants instead of magic strings when overriding the org model.
-- `@elevasis/core/entities` -- entity contracts barrel. Exports `BaseProject`, `BaseProjectSchema`, `BaseProjectInput` and the equivalents for `Milestone`, `Task`, `Deal`, `Company`, `Contact`. Each base interface is generic over a `\<TMeta>` extension slot. Extend these in `foundations/types/entities.ts` to add project-specific fields.
+- `@elevasis/core/entities` -- entity contracts barrel. Exports `BaseProject`, `BaseProjectSchema`, `BaseProjectInput` and the equivalents for `Milestone`, `Task`, `Deal`, `Company`, `Contact`. Each base interface is generic over a `\<TMeta>` extension slot. Extend these in `core/types/entities.ts` to add project-specific fields.
 
 ## When Working with Organization OS
 
-- **Changing org model (structural reality):** Use `/knowledge` as the entry point. Direct edits to `foundations/config/organization-model.ts` are discouraged -- `/knowledge` runs the read → propose → confirm → write → validate ceremony. Run `/knowledge` for the full layered flow or `/knowledge \<domain>` for a targeted domain.
+- **Changing org model (structural reality):** Use `/knowledge` as the entry point. Direct edits to `core/config/organization-model.ts` are discouraged -- `/knowledge` runs the read -> propose -> confirm -> write -> validate ceremony. Run `/knowledge` for the full layered flow or `/knowledge \<domain>` for a targeted domain.
 - **Building or extending CRM:** Start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-crm.md`. CRM spans Organization OS sales semantics, shared UI primitives, deal hooks, workflow adapters, and generated contracts.
 - **Building or extending lead gen:** Start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md`. Lead gen spans Organization OS prospecting semantics, shared UI primitives, list/member hooks, artifact hooks, workflow adapters, and generated contracts.
 - **Customizing CRM deal actions:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/customize-crm-actions.md`. Do not add `sales.actions` to the org model; the v1 server-side override surface is intentionally deferred.
 - **Adding a feature:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-feature.md`. For toggling an existing feature, use `/knowledge features`.
 - **Adding a resource:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-resource.md`.
-- **Extending entities:** Start with `foundations/types/entities.ts` for the demo extension pattern. Base shapes come from `@elevasis/core/entities`.
-- **Authoring a workflow that takes a Project/Deal/etc.:** Reference entity types from `foundations/types/entities.ts` in the input schema -- do not redeclare them.
+- **Extending entities:** Start with `core/types/entities.ts` for the demo extension pattern. Base shapes come from `@elevasis/core/entities`.
+- **Authoring a workflow that takes a Project/Deal/etc.:** Reference entity types from `core/types/entities.ts` in the input schema -- do not redeclare them.
 - **Understanding contracts:** Check `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` for current type shapes.
 - **Debugging sync issues:** Check `node_modules/@elevasis/sdk/reference/scaffold/operations/propagation-pipeline.md` for the verification pipeline.
 
@@ -100,7 +102,7 @@ All paths under `node_modules/@elevasis/sdk/reference/scaffold/`:
 - `/knowledge offerings` -- products and services with pricing model and segment references
 - `/knowledge roles` -- role chart with responsibilities, reporting lines, and holders
 - `/knowledge goals` -- organizational goals with period and measurable outcomes
-- `/knowledge techStack` -- external-SaaS integration metadata on resource mappings
+- `/knowledge techStack` -- external-SaaS and integration context; resource identity still belongs in OM Resources descriptors
 - `/knowledge features` -- enable, disable, or add features
 - `/knowledge labels` -- edit display labels on enum entries (statuses, stages)
 

package/reference/claude-config/rules/ui.md

@@ -17,7 +17,7 @@ The main join points are:
 - `ui/src/main.tsx` -- boots the app with `ElevasisUIProvider`, query client, theme config, WorkOS AuthKit, notifications, and the generated route tree
 - `ui/src/routes/__root.tsx` -- composes the authenticated shell with `ElevasisFeaturesProvider`, published feature manifests, app-local dashboard nav, shell runtime dependencies, and `FeatureShell`
 - `ui/src/config/nav-items.ts` -- keeps the host-local dashboard entry separate from the published feature manifests
-- `foundations/config/organization-model.ts` -- is the template's semantic source of truth, adapting `@elevasis/core/organization-model` into the preserved branding, dashboard label, quick-access, feature-label, and legacy surface helpers the shell still uses
+- `core/config/organization-model.ts` -- is the template's semantic source of truth, adapting `@elevasis/core/organization-model` into the preserved branding, dashboard label, quick-access, feature-label, resource descriptors, and shell helpers
 
 Published feature manifests mounted by the template shell:
 
@@ -32,7 +32,7 @@ Important distinction:
 
 - shared manifests gate on grouped org-model keys such as `acquisition` and `delivery`
 - template routes and local nav may still use legacy aliases such as `crm`, `lead-gen`, and `projects`
-- `foundations/config/organization-model.ts` and `ui/src/lib/hooks/useFeatureAccess.ts` are the bridge between those two vocabularies
+- `core/config/organization-model.ts` and `ui/src/lib/hooks/useFeatureAccess.ts` are the bridge between those two vocabularies
 
 Dashboard remains a host-local route at `/`, not a shared feature manifest.
 
@@ -165,7 +165,7 @@ The main template-owned customization surfaces are:
 - `ui/src/config/background.tsx` -- shared background treatment
 - `ui/src/config/loader.tsx` -- global loader element
 - `ui/src/config/nav-items.ts` -- app-local nav entries, including the preserved dashboard/home entry
-- `foundations/config/organization-model.ts` -- product labels, feature enablement, semantic surfaces, canonical-to-legacy surface aliases, and quick-access behavior
+- `core/config/organization-model.ts` -- product labels, feature enablement, resource descriptors, semantic surfaces, canonical-to-legacy surface aliases, and quick-access behavior
 - `ui/src/config/README.md` -- the deeper guide for those config files
 
 ## Customizing Feature Sidebars

package/reference/claude-config/rules/vibe.md

@@ -71,7 +71,7 @@ bucket, catalog entry, progress step, pipeline column, or similarly closed busin
 also show the cross-system impact before the normal description:
 
 1. Read `node_modules/@elevasis/sdk/reference/spine/spine-primer.md` for the layering pattern.
-2. Read the relevant domain in `foundations/config/organization-model.ts`.
+2. Read the relevant domain in `core/config/organization-model.ts`.
 3. Explain the impact in vibe-coder language only: the business profile entry, the saved progress
    on each record, the automations that produce updates, and the dashboard or reports that read it.
 4. Route follow-up changes through `/knowledge <domain>`. Do not mention the technical pattern name
@@ -140,7 +140,7 @@ change and does not expose monorepo-only commands.
 This routing applies to both codify levels (decision #21 -- Codify ceremony delegated to `/knowledge`):
 
 - **Level A** (config-only edits to `organization-model.ts`, feature toggles, label renames): delegate to `/knowledge <domain>` immediately.
-- **Level B** (new Zod extension files in `foundations/config/extensions/`): also delegate to `/knowledge <domain>`; `/knowledge` gates Level B to explicit user asks before scaffolding a new TS file.
+- **Level B** (new Zod extension files in `core/config/extensions/`): also delegate to `/knowledge <domain>`; `/knowledge` gates Level B to explicit user asks before scaffolding a new TS file.
 
 Vibe detects the intent and delegates in both cases. It does not run either pipeline itself.
 
@@ -171,7 +171,7 @@ The user wants to enable or disable a feature.
 | "Disable monitoring for now"    | "Disable" + feature reference                 |
 | "We don't use SEO, turn it off" | Declarative + "turn it off" = feature disable |
 
-**Agent action:** delegate to `/knowledge features`. The ceremony (confirm + edit `foundations/config/organization-model.ts` + typecheck) belongs to `/knowledge`, not to the ambient rule.
+**Agent action:** delegate to `/knowledge features`. The ceremony (confirm + edit `core/config/organization-model.ts` + typecheck) belongs to `/knowledge`, not to the ambient rule.
 
 ## Quick Reference Table
 
@@ -211,7 +211,7 @@ The threshold controls how aggressively the classifier proposes codification fro
 - `balanced` -- second mention OR explicit declaration triggers; default
 - `loose` -- first strong signal triggers a proposal
 
-Override per project in `foundations/config/organization-model.ts` under `vibe.classifierThreshold`. The override is merge-aware (Tier 2 sync) and will not be overwritten by template sync operations.
+Override per project in `core/config/organization-model.ts` under `vibe.classifierThreshold`. The override is merge-aware (Tier 2 sync) and will not be overwritten by template sync operations.
 
 ## Phase-1 Scope
 

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

@@ -21,7 +21,7 @@ Before orienting, scan the user's query for Organization OS terminology. If any
 - Shell / nav: `manifest`, `shell`, `sub-shell`, `sidebar`, `nav`, `navigation`, `route`
 - Auth / guards: `guard`, `FeatureGuard`, `AdminGuard`, `ProtectedRoute`, `admin`
 - Org model: `organization`, `org model`, `organization model`, `domain`, `surface`
-- Foundations: `foundation`, `foundations`, `@foundation/`, `adapter`
+- Foundations: `foundation`, `foundations`, `@core/`, `adapter`
 - Platform ops: `workflow`, `agent`, `deployment`, `resource`
 
 **If OS-relevant:**
@@ -30,8 +30,8 @@ Before orienting, scan the user's query for Organization OS terminology. If any
 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`
    - Features / 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/resources/**`
-   - Organization-model queries: add `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` + `foundations/config/README.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):
 
@@ -41,7 +41,7 @@ Before orienting, scan the user's query for Organization OS terminology. If any
 | "How do I add a nav item?"               | Features + Toolkit               | `feature-flags-and-gating.md`, `contracts.md`                                            |
 | "How does admin gating work?"            | Features + 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), `foundations/config/README.md`    |
+| "Why does the foundations adapter fail?" | Foundations                      | `glossary.md` (domain vs surface, settings asymmetry), `core/config/README.md`    |
 
 ### Step 1: Orient
 

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

@@ -11,14 +11,14 @@ description: |
     identity set to?", "what's our timezone?", "show me all reference docs", "list my roles",
     "where does outreach-cadence apply?", or similar.
   - An agent is editing files matching: core/config/organization-model.ts,
-    foundations/config/organization-model.ts, packages/elevasis-core/src/organization-model.ts,
+    core/config/organization-model.ts, packages/elevasis-core/src/organization-model.ts,
     or packages/core/src/knowledge/**.
   SKIP this skill when the task is purely UI layout, workflow authoring, or infrastructure
   work with no reference to org-model or knowledge-graph entities.
 metadata:
   pathPatterns:
     - "core/config/organization-model.ts"
-    - "foundations/config/organization-model.ts"
+    - "core/config/organization-model.ts"
     - "packages/elevasis-core/src/organization-model.ts"
     - "packages/core/src/knowledge/**"
   promptSignals:
@@ -72,7 +72,7 @@ This skill auto-invokes whenever:
 - The user asks to read, list, find, show, query, navigate, describe, codify, add, edit,
   update, toggle, enable, or disable any of those
 - An agent is editing files matching `core/config/organization-model.ts`,
-  `foundations/config/organization-model.ts`, `packages/elevasis-core/src/organization-model.ts`,
+  `core/config/organization-model.ts`, `packages/elevasis-core/src/organization-model.ts`,
   or `packages/core/src/knowledge/**`
 
 Auto-invocation is driven by frontmatter `description`, `metadata.pathPatterns`, and
@@ -131,9 +131,9 @@ through `/knowledge`; do not point them at monorepo-only commands.
 ```bash
 pnpm exec elevasis knowledge:ls
 pnpm exec elevasis knowledge:cat <node-id>
-pnpm exec elevasis knowledge:graph --axis by-feature
-pnpm exec elevasis knowledge:graph --axis by-domain
-pnpm exec elevasis knowledge:graph --mount <mount-id>
+pnpm exec elevasis knowledge:ls /by-feature/<feature-id>
+pnpm exec elevasis knowledge:ls /by-owner/<owner-id>
+pnpm exec elevasis knowledge:graph <node-id>
 ```
 
 ### External projects (org instance)
@@ -141,14 +141,15 @@ pnpm exec elevasis knowledge:graph --mount <mount-id>
 ```bash
 pnpm exec elevasis-sdk knowledge:ls
 pnpm exec elevasis-sdk knowledge:cat <node-id>
-pnpm exec elevasis-sdk knowledge:graph --axis by-feature
-pnpm exec elevasis-sdk knowledge:graph --axis by-domain
-pnpm exec elevasis-sdk knowledge:graph --mount <mount-id>
+pnpm exec elevasis-sdk knowledge:ls /by-feature/<feature-id>
+pnpm exec elevasis-sdk knowledge:ls /by-owner/<owner-id>
+pnpm exec elevasis-sdk knowledge:graph <node-id>
 ```
 
 Use `knowledge:ls` to enumerate all knowledge nodes. Use `knowledge:cat` to read a specific
-node's content. Use `knowledge:graph` to navigate the governance graph -- `by-feature` is the
-default axis for "what governs X?" queries; `by-domain` for domain-wide surveys.
+node's content. Use `knowledge:ls /by-feature/<feature-id>` or
+`knowledge:ls /by-owner/<owner-id>` to navigate feature and owner groupings. Use
+`knowledge:graph <node-id>` to inspect incoming and outgoing graph edges for a specific node.
 
 ### `/knowledge read-folder` (chat shorthand from the Knowledge Browser)
 
@@ -175,7 +176,7 @@ preserved verbatim from `/configure`.
 
 ### Step 1: Snapshot
 
-Read `foundations/config/organization-model.ts` (external) or the appropriate platform OM file
+Read `core/config/organization-model.ts` (external) or the appropriate platform OM file
 (monorepo) into memory before any edit. This is the rollback target.
 
 ### Step 2: Propose
@@ -214,9 +215,9 @@ The rollback is mandatory -- never leave the project in a broken state.
 
 **Two-level ceremony:**
 
-- **Level A** -- config-only edits to existing schema fields in `foundations/config/organization-model.ts`.
+- **Level A** -- config-only edits to existing schema fields in `core/config/organization-model.ts`.
   Execute: `.claude/skills/knowledge/operations/codify-level-a.md`
-- **Level B** -- new Zod extension files in `foundations/config/extensions/`. Gated to explicit
+- **Level B** -- new Zod extension files in `core/config/extensions/`. Gated to explicit
   user ask. On casual second mentions of a new type, suggest Level B and wait for confirmation
   rather than scaffolding automatically.
   Execute: `.claude/skills/knowledge/operations/codify-level-b.md`
@@ -250,8 +251,8 @@ and routing.
 
 In external projects (`external/nirvana-marketing`, `external/ZentaraHQ`, etc.) this skill has
 full power: read + write + codify + toggle. The org-model file is
-`foundations/config/organization-model.ts` (or `core/config/organization-model.ts` for
-`external/_template`-derived projects). Extension files live in `foundations/config/extensions/`.
+`core/config/organization-model.ts` (or `core/config/organization-model.ts` for
+`external/_template`-derived projects). Extension files live in `core/config/extensions/`.
 
 This is the environment where Codify and Toggle intents write. All six ceremony steps apply.
 

package/reference/claude-config/skills/knowledge/operations/codify-level-a.md

@@ -1,7 +1,7 @@
 # Codify Pipeline: Level A (Config-Only Edits)
 
 Level A is the codify pipeline for changes that land exclusively in
-`foundations/config/organization-model.ts`. No new TypeScript files are created. The entire
+`core/config/organization-model.ts`. No new TypeScript files are created. The entire
 ceremony is: snapshot current file, propose the edit, write the edit, validate, and roll back on
 failure.
 
@@ -15,18 +15,18 @@ the specific field/block being changed and the proposed new value.
 
 ### Step 1: Snapshot
 
-Before any write, read `foundations/config/organization-model.ts` and keep the full file content
+Before any write, read `core/config/organization-model.ts` and keep the full file content
 in memory as the rollback snapshot. Do not write any file during this step.
 
 ```
-Read("foundations/config/organization-model.ts")
+Read("core/config/organization-model.ts")
 -- store as ROLLBACK_SNAPSHOT
 ```
 
 ### Step 2: Apply the edit
 
 Use the Edit tool to apply the caller's proposed change to
-`foundations/config/organization-model.ts`.
+`core/config/organization-model.ts`.
 
 Rules for the edit:
 
@@ -67,7 +67,7 @@ If either validation step fails, proceed to Step 5 (rollback).
 
 If Step 3 or Step 4 failed:
 
-1. Write the ROLLBACK_SNAPSHOT content back to `foundations/config/organization-model.ts`
+1. Write the ROLLBACK_SNAPSHOT content back to `core/config/organization-model.ts`
    verbatim (use the Write tool with the exact snapshot content).
 2. Confirm the file has been restored by checking that the content matches the snapshot.
 3. Return the error message to the caller.
@@ -90,9 +90,9 @@ The caller formats and presents the final report.
 
 Callers must provide before invoking this pipeline:
 
-- **Target file:** always `foundations/config/organization-model.ts`
+- **Target file:** always `core/config/organization-model.ts`
 - **Target block:** the specific domain key or sub-key being changed (e.g. `identity`,
-  `customers.segments`, `roles.roles`, `resourceMappings[id="rm-hubspot"].techStack`)
+  `customers.segments`, `roles.roles`, `resources.entries[id="hubspot"]`)
 - **Proposed value:** the new TypeScript literal to write for that block
 - **Confirmed:** the user has already said yes to the proposed change