@elevasis/sdk 1.23.0 → 1.24.0

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

@@ -1,43 +1,11 @@
----
-description: Frontend conventions -- React, routing, state, styling, testing, pages
-paths:
-  - ui/src/**
----
-
-# Frontend
-
-## Safety Invariants
-
-- `ElevasisUIProvider` in `ui/src/main.tsx` auto-composes shared UI, auth, and API surface -- route files do not wire providers manually
-- `useApiClient()` from `@/lib/hooks/useApiClient` for authenticated API calls -- never raw `fetch` with auth headers
-- `routeTree.gen.ts` is auto-generated on `pnpm dev` -- never edit manually
-- Auth protection: wrap page content with `ProtectedRoute` from `@elevasis/ui/auth`. Admin pages nest `AdminGuard` inside `ProtectedRoute`
-- Never fork `@elevasis/ui` components -- if a published component needs a tweak, that missing capability is a bug in `@elevasis/ui`
-
-## 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
-- `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
-
-- Mantine 8.2.7 for all UI components -- no Radix UI, no Tailwind CSS, no shadcn
-- `@tabler/icons-react` for icons -- never Lucide
-- Server state: TanStack Query. Client state: Zustand + Immer. Never mix the two
-- Glass background is the primary surface treatment: `var(--glass-background)` with `backdrop-filter: var(--glass-blur)`
-- Import shared components from `@elevasis/ui/components`, `@elevasis/ui/layout`, `@elevasis/ui/charts`
-- Import charts from `@elevasis/ui/charts`, not directly from `@mantine/charts`
-
-## Integration UI Surfaces
-
-When building pages that display external data, use published `@elevasis/ui` components before building custom UI. Use Mantine components and CSS variables exclusively -- no inline hex colors, no custom design tokens. Match existing page density and spacing.
-
-## Detailed Reference
-
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/recipes.md` -- add a page, add a nav item, theme tokens, feature-scoped components, route patterns (static, nested, dynamic)
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-flags-and-gating.md` -- `systemKey` / `SystemGuard` / `AdminGuard` model
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/customization.md` -- sidebar composition via manifest overrides
-- `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` -- TypeScript shapes (`SystemModule`, `NavItem`, `OrganizationModel`)
-- `ui/src/config/theme.ts` -- theme configuration and CSS variable definitions
-- `ui/src/config/nav-items.ts` -- sidebar navigation entries
+---
+description: Compatibility pointer for the canonical Frontend rule bundled with @elevasis/sdk
+---
+
+# Frontend
+
+Canonical rule source:
+
+`node_modules/@elevasis/sdk/reference/rules/frontend.md`
+
+Read that bundled rule before applying this rule. This local file is intentionally kept as a thin compatibility pointer for existing local rule references in skills, sync notes, and older prompts.

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

@@ -1,31 +1,11 @@
----
-description: Observability -- context.logger API, execution inspection, step-level context
-paths:
-  - operations/**
----
-
-# Observability
-
-## Safety Invariants
-
-- Use `context.logger` for all logging in step handlers -- `console.*` is NOT captured by the platform
-- Log levels: `debug` (verbose), `info` (normal progress), `warn` (non-fatal, processing continues), `error` (fatal, processing stops)
-- Step lifecycle events (started, completed, failed, route taken) are auto-logged by the SDK worker -- no handler code needed
-
-## Key Rules
-
-- Every handler should log at: entry (step name + key params), decisions (skips, branches), progress (per-item in loops), summary (counts at end)
-- Error messages in handlers surface as the execution's error message -- write for humans, not machines
-- String values truncated at 200 characters in logs
-- 30-day log retention (includes logs from deleted resources)
-
-## Inspecting Executions
-
-```bash
-pnpm elevasis-sdk execution <resourceId> <executionId>
-pnpm elevasis-sdk executions <resourceId>
-```
-
-## Detailed Reference
-
-- `node_modules/@elevasis/sdk/reference/scaffold/operations/workflow-recipes.md` -- full logging patterns and handler examples
+---
+description: Compatibility pointer for the canonical Observability rule bundled with @elevasis/sdk
+---
+
+# Observability
+
+Canonical rule source:
+
+`node_modules/@elevasis/sdk/reference/rules/observability.md`
+
+Read that bundled rule before applying this rule. This local file is intentionally kept as a thin compatibility pointer for existing local rule references in skills, sync notes, and older prompts.

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

@@ -1,80 +1,11 @@
----
-description: Platform workflows, agents, resource definitions, and deployment for the operations/ surface
-paths:
-  - operations/**
----
-
-# Operations
-
-**Status:** Stable
-
-## Overview
-
-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:** 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 `core/types/index.ts` and imported by both the workflow and the frontend.
-
-```
-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
-```
-
-The workflow is registered in `operations/src/index.ts` as part of the `example` group and deployed with `pnpm -C operations deploy`.
-
-## Adding a New Workflow
-
-1. **Define the descriptor in `core/config/organization-model.ts`** -- Add the OM Resource descriptor under the id-keyed `resources` map so identity, System membership, owner role, and governance status are authored once.
-
-2. **Model the semantic surface** -- Add durable business nouns, verbs, catalogs, links, events, and surfaces to the owning System's `ontology`; bind executable Resources through `resource.ontology.actions` and optional `resource.ontology.primaryAction`; add system-local defaults/settings to `System.config`; add explanatory or governing material to `knowledge`; and keep transient DTOs and handler internals out of the OM. Top-level `entities`, top-level `actions`, and `System.content` are compatibility mirrors only when current published consumers still need them.
-
-3. **Define the contract in `core/types/`** -- Add Zod schemas and inferred types to `core/types/index.ts` (or a new file under `core/types/`). Use `core/types/entities.ts` when workflows operate on project-specific entity contracts.
-
-4. **Implement the workflow in `operations/src/`** -- Create a new directory under `operations/src/` for the feature. Import the descriptor, derive runtime `resourceId`, `type`, `name`, and `description` from it, export the workflow from its `index.ts`, and register it in `operations/src/index.ts`.
-
-5. **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. Read OM resources, ontology, knowledge, and graph data where possible instead of creating page-local semantic registries.
-
-6. **Update rules when the pattern persists** -- If the workflow introduces a reusable adapter pattern, checkpoint/schedule convention, domain vocabulary, or workflow family behavior that future agents must follow, update this rule or add a scoped rule under `.claude/rules/` in the same change.
-
-7. **Deploy and verify:**
-
-```bash
-pnpm -C operations check        # validate resource definitions
-pnpm -C operations deploy       # deploy to dev
-```
-
-## Resource Registry
-
-`operations/src/index.ts` default-exports a `DeploymentSpec` with `version`, `organizationModel`, `workflows`, `agents`, and optional deployment mechanics such as `triggers`, `integrations`, `relationships`, `humanCheckpoints`, and `externalResources`. Durable operational wiring belongs in `organizationModel.topology.relationships`; deployment mechanics, credentials, provider webhook details, and per-run state stay outside the OM. 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
-- `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
-
-| Command                          | Purpose                       |
-| -------------------------------- | ----------------------------- |
-| `pnpm -C operations check`       | Validate resource definitions |
-| `pnpm -C operations check-types` | TypeScript type-check         |
-| `pnpm -C operations deploy`      | Deploy to dev                 |
-| `pnpm -C operations deploy:prod` | Deploy to production          |
-
-Always run `check` before `deploy`.
-
-## Rule Updates
-
-When developing resources, workflows, agents, integrations, checkpoints, schedules, or recurring operational conventions, keep `.claude/rules/` current.
-
-- Update `operations.md` for package-wide operations invariants.
-- Add a scoped rule for domain-specific workflow families whose conventions should autoload for future edits.
-- Do not bury durable operational rules only in task notes or chat context.
+---
+description: Compatibility pointer for the canonical Operations rule bundled with @elevasis/sdk
+---
+
+# Operations
+
+Canonical rule source:
+
+`node_modules/@elevasis/sdk/reference/rules/operations.md`
+
+Read that bundled rule before applying this rule. This local file is intentionally kept as a thin compatibility pointer for existing local rule references in skills, sync notes, and older prompts.

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

@@ -1,116 +1,11 @@
 ---
-description: Edits to the canonical organization model go through /om
-paths:
-  - core/config/organization-model.ts
-  - core/config/extensions/**/*.ts
+description: Compatibility pointer for the canonical Organization Model rule bundled with @elevasis/sdk
 ---
 
-# Organization Model Edit Guide
+# Organization Model
 
-`core/config/organization-model.ts` is the single source of truth for this
-project's organizational identity -- it encodes customers, offerings, roles, goals,
-Systems, ontology, Policies, Knowledge, config, and Resources
-descriptors that agents, workflows, and the UI shell all consume at runtime.
-New semantic authoring should start in system-colocated `ontology` scopes. Top-level
-`entities`, top-level `actions`, and `System.content` remain compatibility mirrors while
-published consumers finish moving to compiled ontology indexes.
+Canonical rule source:
 
-## Preferred Entry Point: `/om`
+`node_modules/@elevasis/sdk/reference/rules/organization-model.md`
 
-Direct edits to `organization-model.ts` are discouraged. Instead, use `/om` (or
-`/om <domain>`) to run the read → propose → confirm → write → validate ceremony:
-
-1. The skill reads the current model so proposals start from ground truth.
-2. It drafts only the specific block being changed, leaving everything else intact.
-3. The user confirms before any file is written.
-4. After writing, `pnpm -C operations check-types` runs and `OrganizationModelSchema.parse()`
-   is verified. On failure the file is rolled back automatically.
-
-Use `/om <domain>` for targeted edits: `identity`, `customers`, `offerings`,
-`roles`, `goals`, `techStack`, `systems`, `actions`, or `labels`. Resource identity and
-governance metadata belong in the id-keyed `resources` map; operations code derives runtime
-`resourceId` / `type` from those descriptors.
-
-Author system-local semantics by boundary:
-
-- `System.ontology` owns durable object types, action types, catalog types, link types, event types, and surfaces.
-- `System.config` owns system-local JSON settings and defaults.
-- `resources` own executable workflow/agent descriptors, `systemPath`, owners, governance status, code references, and runtime implementation links.
-- `resource.ontology.actions` describes the ontology actions a Resource performs; `resource.ontology.primaryAction` names the default/selectable action when a Resource has one.
-- `resource.ontology` also describes reads, writes, catalog use, and emitted events.
-- `topology.relationships` owns durable operational wiring between Systems, Resources, ontology nodes, policies, roles, triggers, checkpoints, and external resources.
-- `knowledge` owns long-form playbooks, strategies, references, and governance context.
-- `System.content`, top-level `entities`, and top-level `actions` are compatibility mirrors only. Keep them aligned when current published consumers still need them, but do not treat them as the primary authoring surface.
-
-Do not author Resource `actionKey` in the target contract. Runtime/UI routing that needs a single selectable action should read `resource.ontology.primaryAction`.
-
-## Runtime Validation
-
-The model is validated at startup via `resolveOrganizationModel()` followed by
-`OrganizationModelSchema.parse()`. Cross-reference checks (segment ID refs in offerings,
-role reporting lines, period ordering in goals) are runtime-only and not caught by tsc
-alone -- always let the ceremony run both checks before treating a change as complete.
-
-## Extension Files
-
-New Zod extension files under `core/config/extensions/` are Level B codify
-operations. Route these through `/om <domain>` as well -- the skill gates Level B
-to explicit user confirmation before scaffolding a new `.ts` file.
-
-This is a soft guide, not a hard block. The ceremony exists to prevent silent schema
-drift and to keep the model's editorial history visible.
-
-## Resource System Attachment
-
-Every resource in the id-keyed `organizationModel.resources` map declares which System it belongs to
-via `systemPath` -- a dot-separated path that resolves against the OM system tree
-(e.g. `"sys.operations"`, `"sales.crm"`):
-
-```ts
-{
-  id: 'apify-website-crawl',
-  systemPath: 'sys.operations',   // canonical system attachment
-  kind: 'workflow',
-  ...
-}
-```
-
-`systemPath` is validated at parse time by `SystemPathSchema` and cross-checked by
-`OrganizationModelSchema.superRefine` -- an unresolvable path causes a Zod error at
-schema validation. Use `getResourcesForSystem(model, path)` (from `@elevasis/core`) to
-query resources for a system at runtime. Pass `{ includeDescendants: true }` to include
-all descendant systems (segment-aware -- `'sales'` does NOT match `'salesforce.foo'`).
-
-Some external templates may carry a `systemId` compatibility mirror while published
-`@elevasis/core` releases catch up to the current source contract. Treat that field as
-legacy adapter data only; author new resource relationships against `systemPath`.
-
-Do not fetch resources for every system-oriented read by default. For agent workflows, start
-with the user's requested OM/om context and query resources only when the task involves
-runtime ownership, executable implementation, observability, deployment, or resource governance.
-Use the descendant rollup only when parent-system scope is intended.
-
-`resource.category` and `resource.links[].nodeId` are **runtime filter overlays** -- they
-drive UI faceted filtering in the Command Center but do NOT define system membership.
-System membership is `systemPath` only.
-
-```ts
-// category and links power UI filter chips; systemPath is the
-// canonical OM attachment used for graph edges and getResourcesForSystem queries.
-```
-
-`resource.codeRefs[]` are repo-relative implementation breadcrumbs for agents and
-operators. Use them to point from a governed OM Resource descriptor to the operations
-entrypoint, handler, schema, test, docs, or config files that implement it. They do
-not define resource identity, System membership, runtime execution topology, or graph
-relationships.
-
-`topology.relationships` defines durable operational wiring in the OM. Keep credential
-values, provider webhook mechanics, deployment environment settings, execution logs,
-and per-run scheduler state outside the OM.
-
-`System.ontology` owns durable semantic contracts: object types, action types, catalog
-types, link types, event types, and surfaces. `System.config` owns local settings and
-defaults. If current UI or runtime code still needs legacy mirrors, keep `entities`,
-`actions`, or `System.content` aligned with the ontology/config record instead of
-inventing a separate source of truth.
+Read that bundled rule before applying this rule. This local file is intentionally kept as a thin compatibility pointer for existing local rule references in skills, sync notes, and older prompts.

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

@@ -1,115 +1,11 @@
-# Organization OS
+---
+description: Compatibility pointer for the canonical Organization Os rule bundled with @elevasis/sdk
+---
 
-Organization OS is the semantic contract layer defining how organizations, Systems, Actions, ontology, resources, policies, roles, goals, knowledge, and runtime surfaces relate. This project consumes Organization OS through published `@elevasis/core` / `@elevasis/sdk` configuration and does not maintain the monorepo schema.
+# Organization Os
 
-This rule is an orientation and reference map. Concrete edit rules for `core/config/organization-model.ts`, `systemPath`, resources, ontology, knowledge, and validation live in `.claude/rules/organization-model.md`.
+Canonical rule source:
 
-## Key Files in This Project
+`node_modules/@elevasis/sdk/reference/rules/organization-os.md`
 
-- `core/config/organization-model.ts` -- project-specific org model definition, Systems, system-local ontology/config, Knowledge, and Resources descriptor catalog (`organizationModel.resources`)
-- `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 `ElevasisSystemsProvider` 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-05 resource-governance expansion, `OrganizationModel` includes platform configuration, organizational reality, governance, and knowledge domains:
-
-**Platform configuration:** `systems`, `branding`, `navigation`
-
-**Organizational reality:** `identity`, `customers`, `offerings`, `roles`, `goals`
-
-**Governance:** `resources`, `policies`, and resource-to-System relationships
-
-**Ontology, config, and knowledge:** `System.ontology` owns durable semantic contracts such as object types, action types, catalog types, link types, event types, and surfaces. `System.config` owns system-local JSON settings and defaults. `knowledge` is a flat id-keyed map of playbooks, strategies, and references that explain or govern systems and ontology records.
-
-Resource identity is authored once in the id-keyed `resources` map. Each resource attaches to a System via `systemPath` and can declare ontology relationships through `resource.ontology`. Operations imports those descriptors and derives runtime `resourceId` / `type` while assembling the `DeploymentSpec`.
-
-### Domain Rename Note
-
-Some legacy UI feature constants and consumer-facing route keys are intentionally unchanged for compatibility:
-
-| Old field  | New field     | Legacy key (unchanged) | UI constant (unchanged) |
-| ---------- | ------------- | ---------------------- | ----------------------- |
-| `crm`      | `sales`       | `'crm'`                | `CRM_FEATURE_ID`        |
-| `leadGen`  | `prospecting` | `'lead-gen'`           | `LEAD_GEN_FEATURE_ID`   |
-| `delivery` | `projects`    | `'projects'`           | `PROJECTS_FEATURE_ID`   |
-
-## Reference Documentation
-
-Full Organization OS documentation ships with the SDK and is available locally after `pnpm install`:
-
-### Scaffold Reference (via SDK)
-
-All paths under `node_modules/@elevasis/sdk/reference/scaffold/`:
-
-- `node_modules/@elevasis/sdk/reference/scaffold/index.mdx` -- scaffold root and navigation
-- `node_modules/@elevasis/sdk/reference/scaffold/core/organization-model.mdx` -- semantic contract, domains, adapter authoring, validation gate, `/om` entry point
-- `node_modules/@elevasis/sdk/reference/scaffold/core/organization-graph.mdx` -- graph derivation, node/edge taxonomy, lenses
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-shell.mdx` -- SystemModule manifest, provider runtime
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/composition-extensibility.mdx` -- layout primitives, router abstraction
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/recipes.md` -- copy-paste UI recipes for pages, nav items, components
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-flags-and-gating.md` -- three-concept gating model
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/customization.md` -- sidebar composition via manifest overrides
-- `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-feature.md` -- end-to-end OM-backed System recipe through manifest, routes, and gating
-- `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-resource.md` -- author and deploy a workflow or agent
-- `node_modules/@elevasis/sdk/reference/scaffold/recipes/gate-by-feature-or-admin.md` -- decision table for access control patterns
-- `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md` -- build or extend lead-gen pages, sidebars, hooks, list/member state, artifacts, workflow adapters, and prospecting semantics
-- `node_modules/@elevasis/sdk/reference/scaffold/operations/workflow-recipes.md` -- workflow anatomy, adapter patterns, trigger patterns
-- `node_modules/@elevasis/sdk/reference/scaffold/operations/propagation-pipeline.md` -- how sync and verification work across projects
-- `node_modules/@elevasis/sdk/reference/scaffold/operations/scaffold-maintenance.md` -- content placement and auto-generation pipeline
-- `node_modules/@elevasis/sdk/reference/scaffold/reference/glossary.md` -- Organization OS term definitions
-- `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` -- auto-generated TypeScript contract shapes
-- `node_modules/@elevasis/sdk/reference/scaffold/reference/feature-registry.md` -- auto-generated feature manifest catalog
-
-### Local Project Docs
-
-- `.claude/rules/agent-start-here.md` -- canonical first-read for agents (includes task-class routing)
-
-## Published Subpaths and Constants
-
-- `@elevasis/core/organization-model` -- the curated organization-model barrel. Exports `defineOrganizationModel`, `resolveOrganizationModel`, `OrganizationModelSchema`, `DEFAULT_ORGANIZATION_MODEL`, organization-model types, and typed System/Action plus legacy UI feature/surface constants.
-  - Legacy UI feature IDs: `CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`, `PROJECTS_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, `MONITORING_FEATURE_ID`, `SETTINGS_FEATURE_ID`, `SEO_FEATURE_ID`
-  - Headline surface IDs: `CRM_PIPELINE_SURFACE_ID`, `LEAD_GEN_LISTS_SURFACE_ID`, `PROJECTS_INDEX_SURFACE_ID`, `OPERATIONS_ORGANIZATION_GRAPH_SURFACE_ID`
-  - Reality domain types: `OrganizationModelIdentity`, `OrganizationModelCustomers`, `OrganizationModelCustomerSegment`, `OrganizationModelOfferings`, `OrganizationModelProduct`, `OrganizationModelRoles`, `OrganizationModelRole`, `OrganizationModelGoals`, `OrganizationModelObjective`, `OrganizationModelKeyResult`
-  - 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 `core/types/entities.ts` to add project-specific fields.
-
-## When Working with Organization OS
-
-- **Changing org model (structural reality):** Use `/om` as the entry point. Direct edits to `core/config/organization-model.ts` are discouraged -- `/om` runs the read -> propose -> confirm -> write -> validate ceremony. Run `/om` for the full layered flow or `/om \<domain>` for a targeted domain. See `.claude/rules/organization-model.md` for the concrete authoring boundary.
-- **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 or toggling a System:** Follow the current scaffold recipes when they mention UI features, but translate Organization OS changes to Systems, navigation surfaces, and Actions. Use `/om systems` for availability/routing changes.
-- **Adding a resource:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-resource.md`.
-- **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.
-- **Adding system-local ontology/config:** Put durable business schema in `System.ontology`, local defaults/settings in `System.config`, executable implementations in `resources`, and explanatory or governing material in `knowledge`.
-- **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.
-
-## `/om` -- Org Model QA Entry Point
-
-`/om` is the recurring, safe-to-re-run org model editor for this project. It is a skill (not a command) at `.claude/skills/om/SKILL.md`.
-
-**Usage:**
-
-- `/om` -- layered flow: identity → customers → offerings → roles → goals → techStack
-- `/om identity` -- legal identity, mission/vision, industry, geography, timezone
-- `/om customers` -- customer segments with jobs-to-be-done, pains, gains, firmographics
-- `/om offerings` -- products and services with pricing model and segment references
-- `/om roles` -- role chart with responsibilities, reporting lines, and holders
-- `/om goals` -- organizational goals with period and measurable outcomes
-- `/om techStack` -- external-SaaS and integration context; resource identity still belongs in OM Resources descriptors
-- `/om systems` -- enable, disable, or add Systems; route invokable behavior through Actions
-- `/om labels` -- edit display labels on enum entries (statuses, stages)
-
-Every write is gated: `resolveOrganizationModel()` must succeed (Zod cross-refs pass) and `pnpm -C operations check-types` must pass. On failure the change is rolled back.
-
-**Distinction from `/setup`:** `/setup` is first-time bootstrap only. After bootstrap it delegates here. `/om` is idempotent and safe to re-run at any time.
-
-The ambient vibe layer (`.claude/rules/vibe.md`) automatically detects Codify intent in plain language and delegates to `/om`. Power users can invoke `/om` directly to bypass the ambient layer entirely.
+Read that bundled rule before applying this rule. This local file is intentionally kept as a thin compatibility pointer for existing local rule references in skills, sync notes, and older prompts.

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

@@ -1,33 +1,11 @@
-# Package Taxonomy (Consumer View)
-
-External projects consume the **published `@elevasis/*` surface only**. The Elevasis monorepo also has workspace-internal `@repo/elevasis-*` packages — those are NOT installable here and should never appear in your imports or `package.json`.
-
-## What You Can Import
-
-| Package          | Subpaths                                     | Where it lives in `node_modules` |
-| ---------------- | -------------------------------------------- | -------------------------------- |
-| `@elevasis/sdk`  | default, `/worker`, `/node`, `/test-utils`   | `node_modules/@elevasis/sdk/`    |
-| `@elevasis/ui`   | default, `/auth`, `/initialization`, etc.    | `node_modules/@elevasis/ui/`     |
-| `@elevasis/core` | `/organization-model`, `/entities`, `/utils` | `node_modules/@elevasis/core/`   |
-
-## What You Will See in Monorepo Docs (and should NOT import)
-
-Monorepo source and docs reference `@repo/elevasis-core` and `@repo/elevasis-operations`. These are workspace-internal packages used by Elevasis as a tenant of its own platform. They are `private: true` and never published. If you see them mentioned:
-
-- Do NOT add them to this project's `package.json`
-- Do NOT try to import from them — they are not in your `node_modules`
-- They are not a substitute for `@elevasis/core` even though the name overlaps
-
-## Confused About Where Something Lives?
-
-Check the import path:
-
-- `@elevasis/...` → published, consumable here
-- `@repo/...` → monorepo-internal, not consumable
-
-This project's own org-model and workflows live in `core/config/organization-model.ts` and `operations/src/**` — those are project-owned, not part of either family above.
-
-## References
-
-- `node_modules/@elevasis/sdk/reference/scaffold/index.mdx` — full SDK scaffold reference
-- Monorepo source rule: `.claude/rules/package-taxonomy.md` in the elevasis-monorepo (when working across both)
+---
+description: Compatibility pointer for the canonical Package Taxonomy rule bundled with @elevasis/sdk
+---
+
+# Package Taxonomy
+
+Canonical rule source:
+
+`node_modules/@elevasis/sdk/reference/rules/package-taxonomy.md`
+
+Read that bundled rule before applying this rule. This local file is intentionally kept as a thin compatibility pointer for existing local rule references in skills, sync notes, and older prompts.

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

@@ -1,42 +1,11 @@
----
-description: Platform conventions -- SDK workflows, agents, deployment, resource registry
-paths:
-  - operations/**
----
-
-# Platform (Elevasis SDK)
-
-## Safety Invariants
-
-- Every workflow implements `WorkflowDefinition` from `@elevasis/sdk` with: `config`, `contract` (Zod schemas), `steps` map, and `entryPoint`
-- Input/output schemas MUST come from `@core/types` or browser-safe sibling schema files -- never define reusable workflow contracts inline in Node-only workflow files
-- `operations/src/index.ts` default-exports a `DeploymentSpec` with `workflows` and `agents` arrays -- every resource must be registered here
-- Always run `check` before `deploy`
-
-## Imports
-
-- `@elevasis/sdk` for types (`WorkflowDefinition`, `DeploymentSpec`)
-- `@elevasis/sdk/worker` for runtime utilities (`platform`, adapters: `llm`, `storage`, `scheduler`, `notifications`, `acqDb`, `list`)
-- `@core/*` resolves to `../core/*` for shared type and org-model imports
-- Never import from `ui/src/` -- separate runtimes
-
-## Key Rules
-
-- Use typed adapters over raw `platform.call()` whenever a typed adapter exists
-- `version` in resource config is semver -- bump on contract changes
-- `status` is `'dev'` or `'prod'` -- new resources start as `'dev'`
-
-## CLI Commands
-
-| Command                              | Purpose                       |
-| ------------------------------------ | ----------------------------- |
-| `pnpm -C operations run check`       | Validate resource definitions |
-| `pnpm -C operations run deploy`      | Deploy to dev                 |
-| `pnpm -C operations run deploy:prod` | Deploy to production          |
-
-## Detailed Reference
-
-- `node_modules/@elevasis/sdk/reference/scaffold/operations/workflow-recipes.md` -- workflow anatomy, adapter patterns, trigger patterns
-- `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-resource.md` -- end-to-end resource authoring guide
-- `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md` -- lead-gen UI, hooks, list/member state, artifacts, and workflow adapter extension guide
-- SDK reference docs: `operations/node_modules/@elevasis/sdk/reference/` (concepts, framework, platform-tools, runtime, CLI)
+---
+description: Compatibility pointer for the canonical Platform rule bundled with @elevasis/sdk
+---
+
+# Platform
+
+Canonical rule source:
+
+`node_modules/@elevasis/sdk/reference/rules/platform.md`
+
+Read that bundled rule before applying this rule. This local file is intentionally kept as a thin compatibility pointer for existing local rule references in skills, sync notes, and older prompts.

package/reference/claude-config/rules/shared-types.md

@@ -1,49 +1,11 @@
----
-description: Core type boundary -- what belongs in core/types, import rules, schema conventions
-paths:
-  - core/types/**
----
-
-# Core Types
-
-`core/types/` is the browser-safe type boundary between the frontend (`ui/`) and platform runtime (`operations/`). Both runtimes import from here but never from each other.
+---
+description: Compatibility pointer for the canonical Shared Types rule bundled with @elevasis/sdk
+---
 
-Keep this as a standalone rule because it autoloads only for `core/types/**` edits. Operations workflow rules can reference this boundary, but shared browser-safe contract guidance belongs here.
-
-## What Belongs Here
-
-- Zod schemas for workflow input/output contracts
-- TypeScript types inferred from those schemas (`z.infer<typeof schema>`)
-- Domain types referenced by both runtimes (status enums, entity shapes)
-- Shared constants
-
-## What Does NOT Belong Here
-
-- React components, hooks, or anything importing `react`
-- SDK runtime code or anything importing `@elevasis/sdk/worker`
-- Browser APIs or Node-specific APIs
-- Implementation logic -- types and constants only
-
-## Schema Convention
-
-Define Zod schemas first, then infer the type:
-
-```typescript
-export const fooInputSchema = z.object({ ... })
-export type FooInput = z.infer<typeof fooInputSchema>
-```
-
-Name schemas `<name>InputSchema` / `<name>OutputSchema`. Name types `<Name>Input` / `<Name>Output`.
-
-## File Organization
-
-Types live in `core/types/`. The directory structure:
-
-- `core/types/index.ts` -- Main entry point, re-exports from domain files
-- `core/types/entities.ts` -- Entity contracts extending published base entities
-- As the project grows: split into domain files within the directory (e.g., `core/types/billing.ts`, `core/types/auth.ts`)
-- Re-export new domain files from `core/types/index.ts`
-
-## Path Alias
-
-Project tsconfigs resolve `@core/*` to `core/*`. Always use `@core/types` or `@core/types/entities` (not relative paths) when importing shared contracts from `ui/` or `operations/src/`.
+# Shared Types
+
+Canonical rule source:
+
+`node_modules/@elevasis/sdk/reference/rules/shared-types.md`
+
+Read that bundled rule before applying this rule. This local file is intentionally kept as a thin compatibility pointer for existing local rule references in skills, sync notes, and older prompts.