@elevasis/sdk 1.20.2 → 1.22.0

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

@@ -1,113 +1,115 @@
-# Organization OS
-
-Organization OS is the semantic contract layer defining how organizations, features, domains, surfaces, entities, capabilities, and resources relate. This project consumes Organization OS through the SDK and foundations config.
-
-## Key Files in This Project
-
-- `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-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`)
-
-**Organizational reality:** `identity`, `customers`, `offerings`, `roles`, `goals`
-
-**Governance:** `systems`, `resources`
-
-**Vibe layer:** `statuses`, `operations`
-
-Resource identity is authored once in `resources.entries`. Operations imports those descriptors and derives runtime `resourceId` / `type` while assembling the `DeploymentSpec`.
-
-### Domain Rename Note
-
-Three field names changed in the 2026-04-20 expansion. Feature ID constants and consumer-facing feature IDs are unchanged:
-
-| Old field  | New field     | Feature ID (unchanged) | 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, all 14 domains, adapter authoring, validation gate, `/knowledge` 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` -- FeatureModule 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 from org model key through manifest, routes, 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 feature/surface constants.
-  - 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`
-  - 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 `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 `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 `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.
-
-## `/knowledge` -- Org Model QA Entry Point
-
-`/knowledge` is the recurring, safe-to-re-run org model editor for this project. It is a skill (not a command) at `.claude/skills/knowledge/SKILL.md`.
-
-**Usage:**
-
-- `/knowledge` -- layered flow: identity → customers → offerings → roles → goals → techStack
-- `/knowledge identity` -- legal identity, mission/vision, industry, geography, timezone
-- `/knowledge customers` -- customer segments with jobs-to-be-done, pains, gains, firmographics
-- `/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 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)
-
-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. `/knowledge` 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 `/knowledge`. Power users can invoke `/knowledge` directly to bypass the ambient layer entirely.
+# Organization OS
+
+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.
+
+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`.
+
+## Key Files in This Project
+
+- `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, `/knowledge` 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 `/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. 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 `/knowledge 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.
+
+## `/knowledge` -- Org Model QA Entry Point
+
+`/knowledge` is the recurring, safe-to-re-run org model editor for this project. It is a skill (not a command) at `.claude/skills/knowledge/SKILL.md`.
+
+**Usage:**
+
+- `/knowledge` -- layered flow: identity → customers → offerings → roles → goals → techStack
+- `/knowledge identity` -- legal identity, mission/vision, industry, geography, timezone
+- `/knowledge customers` -- customer segments with jobs-to-be-done, pains, gains, firmographics
+- `/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 and integration context; resource identity still belongs in OM Resources descriptors
+- `/knowledge systems` -- enable, disable, or add Systems; route invokable behavior through Actions
+- `/knowledge 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. `/knowledge` 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 `/knowledge`. Power users can invoke `/knowledge` directly to bypass the ambient layer entirely.

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

@@ -1,33 +1,33 @@
-# 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)
+# 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)

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

@@ -1,42 +1,42 @@
----
-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 `@shared/types` -- never define inline Zod schemas in 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`)
-- `@shared/*` resolves to `../shared/*` for shared type 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: 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)

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

@@ -1,46 +1,49 @@
----
-description: Shared type boundary -- what belongs in core/types, import rules, schema conventions
-paths:
-  - core/types/**
----
-
-# Shared Types
-
-`shared/` is the type boundary between the frontend (`src/`) and platform (`operations/`). Both runtimes import from here but never from each other.
-
-## 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 `shared/types/`. The directory structure:
-
-- `shared/types/index.ts` -- Main entry point, re-exports from domain files
-- As the project grows: split into domain files within the directory (e.g., `shared/types/billing.ts`, `shared/types/auth.ts`)
-- Re-export new domain files from `shared/types/index.ts`
-
-## Path Alias
-
-Both tsconfigs resolve `@shared/*` to `shared/*`. Always use `@shared/types` (not relative paths) when importing from `src/` or `operations/src/`.
+---
+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.
+
+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/`.

package/reference/claude-config/rules/task-tracking.md

@@ -1,47 +1,47 @@
----
-description: In-progress task conventions -- doc format, status values, auto-save behavior
----
-
-# Task Tracking
-
-## Status Values
-
-Exactly three values for frontmatter `status`: `planned`, `in-progress`, `complete`.
-
-## Doc Format
-
-- Frontmatter: `title`, `description`, `status` only -- nothing else belongs in task-doc frontmatter; `resume_context` is DB-canonical on `prj_tasks`
-- Sections: Objective, Plan, Progress, Resume Context
-- Progress subsections use markers: `### Step N: Title -- PENDING`, `-- IN PROGRESS`, `-- COMPLETE`
-
-## Auto-Update Behavior
-
-- When working on a tracked task, update the Progress section when a plan step transitions:
-  - PENDING -> IN PROGRESS (starting work on a step)
-  - IN PROGRESS -> COMPLETE (finishing a step)
-- Do NOT update on every action -- only on step transitions
-
-## Auto-Save Behavior
-
-The agent auto-saves progress (no user action needed) when:
-
-- The conversation context is getting heavy (many tool calls, large file reads)
-- The user appears to be wrapping up (thanks, goodbye, switching topics)
-- Significant progress has been made (2+ steps completed without saving)
-- Before a context reset
-
-Auto-save updates the task doc's Progress and Resume Context sections silently, then briefly confirms. The canonical persistence path is `pnpm elevasis-sdk project:task:save` -- the CLI writes through to `prj_tasks.resume_context` (JSONB) so another agent can resume without re-deriving intent.
-
-## Completion Suggestions
-
-When all plan steps are marked COMPLETE, **suggest** completing the task -- never auto-invoke. Ask: "All steps for '{task}' look done. Want me to finalize it?"
-
-## Where Tasks Live
-
-Project tasks for this template live in the `prj_tasks` Supabase table, not in repo-local files. Operate on them via the SDK CLI:
-
-- `pnpm elevasis-sdk project:work` -- entrypoint for task work (resume / new intent detection)
-- `pnpm elevasis-sdk project:list` -- portfolio / task listing
-- `pnpm elevasis-sdk project:task:save` -- persist progress + `resume_context` to the DB
-
-The monorepo-side `/work` slash command still exists for monorepo task docs under `apps/docs/content/docs/in-progress/**`; that flow is unchanged. What went away is the external template's own `/work` skill and its `docs/in-progress/` directory -- external projects now route through the DB-backed `project:*` surface above.
+---
+description: In-progress task conventions -- doc format, status values, auto-save behavior
+---
+
+# Task Tracking
+
+## Status Values
+
+Exactly three values for frontmatter `status`: `planned`, `in-progress`, `complete`.
+
+## Doc Format
+
+- Frontmatter: `title`, `description`, `status` only -- nothing else belongs in task-doc frontmatter; `resume_context` is DB-canonical on `prj_tasks`
+- Sections: Objective, Plan, Progress, Resume Context
+- Progress subsections use markers: `### Step N: Title -- PENDING`, `-- IN PROGRESS`, `-- COMPLETE`
+
+## Auto-Update Behavior
+
+- When working on a tracked task, update the Progress section when a plan step transitions:
+  - PENDING -> IN PROGRESS (starting work on a step)
+  - IN PROGRESS -> COMPLETE (finishing a step)
+- Do NOT update on every action -- only on step transitions
+
+## Auto-Save Behavior
+
+The agent auto-saves progress (no user action needed) when:
+
+- The conversation context is getting heavy (many tool calls, large file reads)
+- The user appears to be wrapping up (thanks, goodbye, switching topics)
+- Significant progress has been made (2+ steps completed without saving)
+- Before a context reset
+
+Auto-save updates the task doc's Progress and Resume Context sections silently, then briefly confirms. The canonical persistence path is `pnpm elevasis-sdk project:task:save` -- the CLI writes through to `prj_tasks.resume_context` (JSONB) so another agent can resume without re-deriving intent.
+
+## Completion Suggestions
+
+When all plan steps are marked COMPLETE, **suggest** completing the task -- never auto-invoke. Ask: "All steps for '{task}' look done. Want me to finalize it?"
+
+## Where Tasks Live
+
+Project tasks for this template live in the `prj_tasks` Supabase table, not in repo-local files. Operate on them via the SDK CLI:
+
+- `pnpm elevasis-sdk project:work` -- entrypoint for task work (resume / new intent detection)
+- `pnpm elevasis-sdk project:list` -- portfolio / task listing
+- `pnpm elevasis-sdk project:task:save` -- persist progress + `resume_context` to the DB
+
+The monorepo-side `/work` slash command still exists for monorepo task docs under `apps/docs/content/docs/in-progress/**`; that flow is unchanged. What went away is the external template's own `/work` skill and its `docs/in-progress/` directory -- external projects now route through the DB-backed `project:*` surface above.