@elevasis/sdk 1.6.0 → 1.8.0

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

@@ -0,0 +1,254 @@
+---
+description: Canonical first-read for agents entering the template scaffold -- project continuity, task-class routing, and boundary resolution
+---
+
+# Agent Start Here
+
+Read this file first when entering a freshly scaffolded project.
+
+## First Action: Check Active Projects
+
+Before loading any docs for a new session, check whether the user's ask resumes or relates to an in-flight client project. Project context (milestones, tasks, resume notes) is DB-canonical -- agents and CLI read/write it through the `elevasis-sdk project:*` surface.
+
+1. **Portfolio snapshot.** Run this first to see what is active or blocked:
+
+   ```bash
+   pnpm elevasis-sdk project:list --status active --pretty
+   pnpm elevasis-sdk project:list --status blocked --pretty
+   ```
+
+2. **Resume-style asks.** If the user says "continue", "pick up", references a client name, or names a task/milestone, resolve it via:
+
+   ```bash
+   pnpm elevasis-sdk project:work <query>
+   ```
+
+   `project:work` fuzzy-matches a project or task by name/ID and returns the current resume context -- the canonical continuity payload (current state, next steps, files modified, key docs).
+
+3. **Fresh non-project asks.** Only if the portfolio snapshot and the request show no overlap with active projects, fall back to the docs-index flow below. Even then, if the work will take more than a single file edit, offer to create a project first (`/project create` or `project:create`) so continuity is captured from the start.
+
+### Resume Context Source of Truth
+
+`resume_context` lives in the `prj_tasks` table in the database, not in task-doc frontmatter. There is one source of truth:
+
+- **Humans write** via the inline resume-context editor on the Project Detail page in Command Center.
+- **Agents and the CLI write** via `pnpm elevasis-sdk project:task:save <task-id> --current-state ... --next-steps ... --files-modified ...`.
+- **Readers** consume it via `project:work <query>` or `project:task:resume <id>`.
+
+Do not write resume state into markdown frontmatter. Task-doc frontmatter is limited to `title`, `description`, and `status`.
+
+### Session-Start Dashboard
+
+The session-start dashboard directive lives in `CLAUDE.md`. If you see it there, follow it on the first response of a session. This file (`agent-start-here` rule) is the drill-down reference layer; `CLAUDE.md` owns session bootstrap.
+
+## Template Surfaces
+
+Once project continuity is resolved (or confirmed irrelevant), the template is not just an app starter. It is an agent operating environment with several distinct surfaces:
+
+- `ui/` -- React frontend app and shell composition
+- `operations/` -- Elevasis SDK resources deployed to the platform
+- `foundations/` -- runtime-agnostic shared contracts and organization model adaptation
+- `.claude/` -- local agent rules, skills, and hooks
+- `client-workspace/` -- optional separate knowledge workspace for richer team knowledge management
+- `node_modules/@elevasis/sdk/reference/scaffold/` -- SDK reference scaffold: canonical recipes, UI patterns, gating model, contracts, and glossary. Entry point: `index.mdx`.
+
+## Discovery Order
+
+Use this order unless a more specific doc tells you otherwise:
+
+1. Complete the "First Action: Check Active Projects" flow above.
+2. Read `CLAUDE.md` for project rules, command surface, and navigation pointers.
+3. Read this rule and classify the task using the Task Classes below.
+4. Read `identity.clientBrief` from the OrganizationModel (`operations/foundations/config/organization-model.ts`) for organization context and naming.
+5. Read the relevant structural map:
+   - Glob `node_modules/@elevasis/sdk/reference/` for published package surfaces
+   - Glob `operations/resources/**` for source, or run `pnpm elevasis-sdk project:list --pretty` for live DB state
+6. For feature integration, resource authoring, or UI customization tasks, read `node_modules/@elevasis/sdk/reference/scaffold/index.mdx` to find the canonical recipe or reference doc.
+7. Drill into the co-located local explainer for the abstraction boundary you are changing.
+8. Check the `.claude/rules/active-change-index.md` rule before trusting stable assumptions in areas that are under active architecture work.
+
+## SDK Reference Scaffold
+
+Universal scaffold documentation (recipes, patterns, architecture, reference) has been centralized in the SDK reference. After `pnpm install`, the entry point is:
+
+`node_modules/@elevasis/sdk/reference/scaffold/index.mdx`
+
+This index links to all scaffold docs including pathway recipes, UI patterns, core architecture, and auto-generated contracts/feature registry.
+
+For task classes that involve feature integration, resource authoring, or UI customization, start with the scaffold index rather than local docs.
+
+## Task Classes
+
+Classify the request, then follow the load/inspect/verify sequence for that class.
+
+### 1. UI / Shell Work
+
+Examples: add a page, change sidebar behavior, adjust feature visibility, update dashboard labels.
+
+Load first:
+
+- `node_modules/@elevasis/sdk/reference/scaffold/index.mdx` (scaffold index -- UI recipes, feature flags, customization)
+- `.claude/rules/ui.md`
+- `ui/src/routes/README.md`
+- `foundations/config/README.md`
+- `node_modules/@elevasis/sdk/reference/scaffold/ui/recipes.md` -- specifically recipe 6 when building a "run this resource" surface
+
+Then inspect:
+
+- `ui/src/routes/__root.tsx`
+- `ui/src/config/*`
+- relevant `ui/src/routes/*`
+- relevant `ui/src/features/*`
+- `foundations/config/organization-model.ts`
+
+Verify with:
+
+- route and manifest source
+- any relevant package README from `packages/ui`
+
+### 2. Workflow / Agent / Operations Work
+
+Examples: add a workflow, update an agent, change resource registration, understand deployable resources.
+
+Load first:
+
+- `node_modules/@elevasis/sdk/reference/scaffold/index.mdx` (scaffold index -- workflow recipes, resource authoring)
+- `.claude/rules/operations.md`
+- `operations/src/README.md`
+
+Then inspect:
+
+- `operations/src/index.ts`
+- relevant `operations/src/<feature>/*`
+- `foundations/types/index.ts` -- workflow input/output Zod schemas
+- `foundations/types/entities.ts` -- typed entity contracts (Project, Deal, etc.) extending `@elevasis/core/entities` base types. Read this when authoring a workflow that takes or returns these entities so the input/output schemas reference the canonical entity shapes rather than redeclaring them.
+- `operations/elevasis.config.ts`
+
+Verify with:
+
+- Glob `operations/resources/**` for local source files, or run `pnpm elevasis-sdk project:list --pretty` for live DB state
+- local SDK guidance in `.claude/skills/elevasis/SKILL.md`
+
+### 3. Organization Model / Feature Access Work
+
+Examples: rename a feature area, change quick access surfaces, map new business terms into the shell, adjust feature gating.
+
+Load first:
+
+- `node_modules/@elevasis/sdk/reference/scaffold/index.mdx` (scaffold index -- contracts, gating patterns, glossary)
+- `foundations/config/README.md`
+- `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md`
+- typed feature/surface constants from `@elevasis/core/organization-model` -- `CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`, `PROJECTS_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, `MONITORING_FEATURE_ID`, `SETTINGS_FEATURE_ID`, `SEO_FEATURE_ID`, `CRM_PIPELINE_SURFACE_ID`, `LEAD_GEN_LISTS_SURFACE_ID`, `PROJECTS_INDEX_SURFACE_ID`, `OPERATIONS_ORGANIZATION_GRAPH_SURFACE_ID`. Use these typed constants instead of magic strings when overriding feature/surface IDs.
+- `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-flags-and-gating.md`
+
+Then inspect:
+
+- `foundations/config/organization-model.ts`
+- `foundations/config/organization-model.examples.ts` -- 5 reference patterns: branding override, CRM pipeline stage customization, lead-gen lifecycle customization, resource mapping registration, custom feature declaration. Not imported anywhere -- pure reference. Start here for the override pattern when extending the org model.
+- `ui/src/routes/__root.tsx`
+- `ui/src/lib/hooks/useFeatureAccess.ts`
+- relevant nav config files
+
+Verify with:
+
+- published package docs for `@elevasis/core/organization-model`
+- current scaffold routes and manifests
+
+### 4. Debugging / Impact Analysis
+
+Examples: why is this automation disconnected, what does this workflow affect, what should I inspect before changing this resource.
+
+Load first:
+
+- `operations/src/README.md`
+- `.claude/rules/active-change-index.md`
+- Glob `operations/resources/**` for source, or run `pnpm elevasis-sdk project:list --pretty` for live DB state
+
+Then inspect:
+
+- `operations/src/index.ts`
+- resource definitions
+- related UI route and feature files
+- related foundations contracts
+
+Verify with:
+
+- resource registration and relationship declarations
+- generated maps
+- package and source ownership boundaries
+
+### 5. Platform Extension / Package Contract Work
+
+Examples: extend a published package contract, understand how a scaffold surface maps to `@elevasis/ui`, update a package-facing reference doc.
+
+Load first:
+
+- `.claude/rules/active-change-index.md`
+- Glob `node_modules/@elevasis/sdk/reference/` for the current SDK package surface
+- package README found via that glob
+
+Then inspect:
+
+- package source entrypoints
+- package reference manifests
+- scaffold files that consume that contract
+
+Verify with:
+
+- published package docs
+- source exports
+- scaffold consumption points
+
+## Boundary Resolution
+
+Once the request is classified, determine which boundary owns the change:
+
+- **Foundations boundary** -- semantics, aliases, labels, shared schemas
+- **UI shell boundary** -- provider composition, manifests, navigation, route ownership
+- **Operations boundary** -- deployable resource registration, workflow/agent contracts, topology
+- **Package boundary** -- public exports, shared platform behavior, reusable contracts
+
+If a task spans boundaries, start at the semantic boundary, then move to runtime composition, then to registration/deployment.
+
+## Main Boundaries
+
+### `foundations/config/organization-model.ts`
+
+The semantic adaptation point between platform contracts and scaffold-local terminology. Start here for feature labels, legacy aliases, quick-access surfaces, and shell-facing organization semantics.
+
+### `ui/src/routes/__root.tsx`
+
+The shell composition point. Start here for manifest mounting, provider wiring, app-local nav, and how the scaffold combines published feature surfaces with project-owned shell concerns.
+
+### `operations/src/index.ts`
+
+The deployment aggregation point. Start here for what resources are registered and deployed as part of the scaffold.
+
+## Source of Truth
+
+Trust these in order:
+
+1. Source code and published package docs
+2. Co-located boundary docs
+3. Generated structural maps
+4. Hand-authored template guidance
+5. In-progress architecture docs when `.claude/rules/active-change-index.md` says the area is actively evolving
+
+If a hand-authored doc conflicts with source or published package docs, trust source and flag the doc drift.
+
+## Common Traps
+
+- Do not assume `operations/resources/**` is exhaustive without also checking `operations/src/index.ts` directly.
+- Do not assume placeholder knowledge is sufficient for real client context. Read `identity.clientBrief` from the OrganizationModel (`operations/foundations/config/organization-model.ts`).
+- Do not trust stable docs blindly when `.claude/rules/active-change-index.md` flags related in-progress architecture work.
+- Do not write `resume_context` into task-doc frontmatter. DB is canonical; write via `project:task:save` or the inline editor in Command Center.
+
+## Operations-Only Projects
+
+Some projects derived from this template are operations-only. They have `operations/` (or a top-level `src/`) but NO `ui/`, NO `foundations/config/organization-model.ts`, and NO frontend. Finding none of these is not missing scaffolding -- it is by design.
+
+**What applies:** Only Task Classes 2 (Workflow / Agent / Operations Work) and 4 (Debugging / Impact Analysis) apply to operations-only projects. Task Classes 1 (UI / Shell Work), 3 (Organization Model / Feature Access Work), and 5 (Platform Extension / Package Contract Work) do not apply and can be skipped.
+
+**Primary entrypoint:** For operations-only projects, the project's own `CLAUDE.md` and its Navigation table are the canonical first-read. This rule provides task-routing context but its full surface map is irrelevant for that project type.
+
+**Signal:** The `CLAUDE.md` of an operations-only project includes `Project type: operations-only` in its `## Project` section. When you see this signal, skip all template surfaces that don't exist and go directly to the operations task class.

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

@@ -33,7 +33,6 @@ Deploy accepts `--major`, `--minor`, `--patch` flags to bump the deployment vers
 
 1. **Bundle:** esbuild compiles `src/index.ts` + all dependencies into a single self-contained CJS file. No `node_modules` needed at runtime.
 2. **Metadata:** Resource definitions, Zod schemas (converted to JSON Schema), relationships, triggers.
-3. **Docs:** All `.md` and `.mdx` files in `docs/` (max 100KB per file, 1MB total). The SDK scans the directory configured as `docsDir` in `elevasis.config.ts` (defaults to `docs/`, set to `../docs/` in this template). Two auto-generated files are regenerated by `/deploy` and `/elevasis deploy` before upload: `docs/index.md` (navigation hub) and `docs/resources.md` (platform resource inventory).
 
 ## Environment
 

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

@@ -22,8 +22,8 @@ paths:
 ## Inspecting Executions
 
 ```bash
-pnpm exec elevasis-sdk execution <resourceId> <executionId>
-pnpm exec elevasis-sdk executions <resourceId>
+pnpm elevasis-sdk execution <resourceId> <executionId>
+pnpm elevasis-sdk executions <resourceId>
 ```
 
 ## Detailed Reference

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

@@ -0,0 +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`.

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

@@ -0,0 +1,44 @@
+---
+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.

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

@@ -5,12 +5,34 @@ Organization OS is the semantic contract layer defining how organizations, featu
 ## Key Files in This Project
 
 - `foundations/config/organization-model.ts` -- project-specific org model definition (calls `defineOrganizationModel` + `resolveOrganizationModel`)
-- `foundations/config/organization-model.examples.ts` -- 5 reference patterns: branding, CRM stages, lead-gen stages, resource mappings, custom features. Pure reference -- not imported anywhere. Read this when customizing the org model.
+- `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`:
@@ -20,7 +42,7 @@ Full Organization OS documentation ships with the SDK and is available locally a
 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, schema, authoring helpers
+- `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
@@ -39,24 +61,47 @@ All paths under `node_modules/@elevasis/sdk/reference/scaffold/`:
 
 ### Local Project Docs
 
-- `docs/platform-navigation-map.md` -- auto-generated cross-package reference map
-- `docs/resources.md` -- auto-generated project resource topology
-- `docs/agent-start-here.md` -- canonical first-read for agents (includes task-class routing)
+- `.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`
-  - Use these constants instead of magic strings when overriding the org model.
+  - 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
 
-- **Adding a feature:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-feature.md`
-- **Adding a resource:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-resource.md`
-- **Changing org model:** Start with `foundations/config/organization-model.examples.ts` for reference patterns, then edit `foundations/config/organization-model.ts`. Use the typed feature/surface constants from `@elevasis/core/organization-model` rather than magic strings. Verify the org-os wiring (provider chain, CSS imports, feature shell).
+- **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
+- **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/task-tracking.md

@@ -30,7 +30,7 @@ The agent auto-saves progress (no user action needed) when:
 - 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 exec elevasis-sdk project:task:save` -- the CLI writes through to `prj_tasks.resume_context` (JSONB) so another agent can resume without re-deriving intent.
+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
 
@@ -40,8 +40,8 @@ When all plan steps are marked COMPLETE, **suggest** completing the task -- neve
 
 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 exec elevasis-sdk project:work` -- entrypoint for task work (resume / new intent detection)
-- `pnpm exec elevasis-sdk project:list` -- portfolio / task listing
-- `pnpm exec elevasis-sdk project:task:save` -- persist progress + `resume_context` to the DB
+- `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.