@elevasis/sdk 1.8.2 → 1.9.0

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

@@ -1,64 +1,64 @@
----
-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:** 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.
-
-## 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.
-
-```
-foundations/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 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:**
-
-```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`, `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.
-
-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
-
-## 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`.
+---
+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:** 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.
+
+## 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.
+
+```
+foundations/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 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:**
+
+```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`, `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.
+
+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
+
+## 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`.

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

@@ -1,44 +1,43 @@
----
-description: Edits to the canonical organization model go through /configure
+---
+description: Edits to the canonical organization model go through /configure
 paths:
-  - operations/foundations/config/organization-model.ts
-  - operations/foundations/config/organization-model.override.ts
-  - operations/foundations/config/extensions/**/*.ts
----
-
-# Organization Model Edit Guide
-
-`foundations/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.
-
-## Preferred Entry Point: `/configure`
-
-Direct edits to `organization-model.ts` are discouraged. Instead, use `/configure` (or
-`/configure <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 `/configure <domain>` for targeted edits: `identity`, `customers`, `offerings`,
-`roles`, `goals`, `techStack`, `features`, or `labels`.
-
-## 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 `foundations/config/extensions/` are Level B codify
-operations. Route these through `/configure <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.
+  - core/config/organization-model.ts
+  - core/config/extensions/**/*.ts
+---
+
+# Organization Model Edit Guide
+
+`foundations/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.
+
+## Preferred Entry Point: `/configure`
+
+Direct edits to `organization-model.ts` are discouraged. Instead, use `/configure` (or
+`/configure <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 `/configure <domain>` for targeted edits: `identity`, `customers`, `offerings`,
+`roles`, `goals`, `techStack`, `features`, or `labels`.
+
+## 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 `foundations/config/extensions/` are Level B codify
+operations. Route these through `/configure <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.

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

@@ -1,107 +1,107 @@
-# 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
-
-- `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.
-- `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:
-
-**Platform configuration:** `features`, `branding`, `navigation`, `sales` (formerly `crm`), `prospecting` (formerly `leadGen`), `projects` (formerly `delivery`), `resourceMappings`
-
-**Organizational reality:** `identity`, `customers`, `offerings`, `roles`, `goals`
-
-**Vibe layer:** `statuses`, `operations`
-
-The `resourceMappings` entries may carry an optional `techStack` extension (`platform`, `purpose`, `credentialStatus`, `isSystemOfRecord`) without introducing a new top-level domain.
-
-### 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, `/configure` 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/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 `foundations/types/entities.ts` to add project-specific fields.
-
-## When Working with Organization OS
-
-- **Changing org model (structural reality):** Use `/configure` as the entry point. Direct edits to `foundations/config/organization-model.ts` are discouraged -- `/configure` runs the read → propose → confirm → write → validate ceremony. Run `/configure` for the full layered flow or `/configure \<domain>` for a targeted domain.
-- **Adding a feature:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-feature.md`. For toggling an existing feature, use `/configure 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.
-- **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.
-
-## `/configure` -- Org Model QA Entry Point
-
-`/configure` is the recurring, safe-to-re-run org model editor for this project. It is a skill (not a command) at `.claude/skills/configure/SKILL.md`.
-
-**Usage:**
-
-- `/configure` -- layered flow: identity → customers → offerings → roles → goals → techStack
-- `/configure identity` -- legal identity, mission/vision, industry, geography, timezone
-- `/configure customers` -- customer segments with jobs-to-be-done, pains, gains, firmographics
-- `/configure offerings` -- products and services with pricing model and segment references
-- `/configure roles` -- role chart with responsibilities, reporting lines, and holders
-- `/configure goals` -- organizational goals with period and measurable outcomes
-- `/configure techStack` -- external-SaaS integration metadata on resource mappings
-- `/configure features` -- enable, disable, or add features
-- `/configure 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. `/configure` 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 `/configure`. Power users can invoke `/configure` directly to bypass the ambient layer entirely.
+# 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
+
+- `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.
+- `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:
+
+**Platform configuration:** `features`, `branding`, `navigation`, `sales` (formerly `crm`), `prospecting` (formerly `leadGen`), `projects` (formerly `delivery`), `resourceMappings`
+
+**Organizational reality:** `identity`, `customers`, `offerings`, `roles`, `goals`
+
+**Vibe layer:** `statuses`, `operations`
+
+The `resourceMappings` entries may carry an optional `techStack` extension (`platform`, `purpose`, `credentialStatus`, `isSystemOfRecord`) without introducing a new top-level domain.
+
+### 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, `/configure` 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/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 `foundations/types/entities.ts` to add project-specific fields.
+
+## When Working with Organization OS
+
+- **Changing org model (structural reality):** Use `/configure` as the entry point. Direct edits to `foundations/config/organization-model.ts` are discouraged -- `/configure` runs the read → propose → confirm → write → validate ceremony. Run `/configure` for the full layered flow or `/configure \<domain>` for a targeted domain.
+- **Adding a feature:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-feature.md`. For toggling an existing feature, use `/configure 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.
+- **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.
+
+## `/configure` -- Org Model QA Entry Point
+
+`/configure` is the recurring, safe-to-re-run org model editor for this project. It is a skill (not a command) at `.claude/skills/configure/SKILL.md`.
+
+**Usage:**
+
+- `/configure` -- layered flow: identity → customers → offerings → roles → goals → techStack
+- `/configure identity` -- legal identity, mission/vision, industry, geography, timezone
+- `/configure customers` -- customer segments with jobs-to-be-done, pains, gains, firmographics
+- `/configure offerings` -- products and services with pricing model and segment references
+- `/configure roles` -- role chart with responsibilities, reporting lines, and holders
+- `/configure goals` -- organizational goals with period and measurable outcomes
+- `/configure techStack` -- external-SaaS integration metadata on resource mappings
+- `/configure features` -- enable, disable, or add features
+- `/configure 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. `/configure` 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 `/configure`. Power users can invoke `/configure` directly to bypass the ambient layer entirely.

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

@@ -1,7 +1,7 @@
 ---
-description: Shared type boundary -- what belongs in shared/, import rules, schema conventions
+description: Shared type boundary -- what belongs in core/types, import rules, schema conventions
 paths:
-  - shared/**
+  - core/types/**
 ---
 
 # Shared Types

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

@@ -10,7 +10,7 @@ Exactly three values for frontmatter `status`: `planned`, `in-progress`, `comple
 
 ## Doc Format
 
-- Frontmatter: `title`, `description`, `status` (per the monorepo rule in `.claude/rules/in-progress-tasks.md` -- nothing else belongs in task-doc frontmatter; `resume_context` is DB-canonical on `prj_tasks`)
+- 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`