@elevasis/sdk 1.44.2 → 1.45.0

package/reference/claude-config/skills/om/operations/features.md

@@ -1,88 +0,0 @@
-# Features Compatibility Notes
-
-`features` is legacy organization-model wording. Current Organization OS vocabulary is
-System/Resource/Action oriented:
-
-- **Systems** describe durable capability ownership, ontology/config, accountability, governance,
-  and knowledge mounts. They are not sidebar groups.
-- **Resources** describe executable artifacts such as workflows, agents, scripts, and triggers;
-  each Resource attaches to a real System through `systemPath`.
-- **Actions** describe invokable operations such as workflows, agents, commands, and UI-triggered
-  tasks.
-
-Use this file only when older prompts, browser copy text, SDK references, or scaffold recipes still
-say "feature". For current tenant organization-model work, route the user to Systems and Actions
-wording and use `/by-system/<id>` knowledge paths.
-
-Do not translate "feature" into a catch-all System. Route to Systems only when the user means a
-durable capability boundary; route workflow, agent, script, trigger, or implementation asks to
-Resources under the System that owns the actual business or platform capability.
-
-## Compatibility Mapping
-
-| Legacy wording                                                                        | Current wording                                 |
-| ------------------------------------------------------------------------------------- | ----------------------------------------------- |
-| Feature toggle                                                                        | System availability or routing toggle           |
-| Feature ID                                                                            | System ID when discussing Organization OS       |
-| Add a custom feature                                                                  | Add or extend a capability System, then define Resources and Actions it owns |
-| Feature governs X                                                                     | System governs X                                |
-| `/om read-folder feature:x` (legacy `/knowledge read-folder feature:x` also accepted) | `/om read-folder system:x`                      |
-| `/by-feature/x`                                                                       | `/by-system/x`                                  |
-
-`by-feature` may still exist as a legacy compatibility axis in older tools. Do not introduce new
-guidance that depends on it; prefer `by-system` everywhere.
-
-## What To Do With Toggle Requests
-
-For natural-language requests like "turn on lead gen", "disable SEO", or "enable CRM":
-
-1. Treat the request as a System availability/routing change.
-2. Read the Systems config file to find the matching System entry or platform default constant
-   exposed by `@elevasis/core/organization-model`. For split projects this is
-   `core/config/organization-model/systems.ts`; for unsplit projects use
-   `core/config/organization-model.ts`.
-3. Propose the exact availability/routing change in plain language.
-4. After confirmation, run the Level A codify ceremony in `operations/codify-level-a.md`, passing
-   `targetFile` as `core/config/organization-model/systems.ts` (split) or
-   `core/config/organization-model.ts` (unsplit).
-
-Do not create new extension files for a simple on/off change.
-
-## When Level B Applies
-
-Level B applies only when the user explicitly asks for a new structural concept that cannot be
-represented as an existing System or Action configuration. In current vocabulary this usually
-means adding a project-owned extension under `core/config/extensions/` and wiring it into the
-organization model.
-
-Older references may call this "adding a custom feature"; translate it to "add or extend a
-capability System and define the Resources and Actions it owns" before invoking
-`operations/codify-level-b.md`.
-
-## UI Package Exception
-
-Keep the word `features` only for legacy frontend source paths that still use that directory
-name, such as `ui/src/features/`. Current published shell APIs are System-oriented:
-`SystemShell`, `SystemModule`, and `ElevasisSystemsProvider`.
-
-## Read Examples
-
-Use current system paths:
-
-```bash
-pnpm exec elevasis-sdk om:ls /by-system/<id> --ids-only
-pnpm exec elevasis-sdk om:cat <node-id>
-```
-
-Legacy browser output (the `/knowledge` slash form is preserved as a permanent alias for `/om`):
-
-```text
-/knowledge read-folder feature:<id>
-/om read-folder feature:<id>
-```
-
-Resolve as:
-
-```bash
-pnpm exec elevasis-sdk om:ls /by-system/<id> --ids-only
-```

package/reference/claude-config/skills/om/operations/goals.md

@@ -1,123 +0,0 @@
-# Goals domain
-
-The `goals` domain captures what the organization is working toward — time-bounded goals with
-measurable outcomes. The schema shape is OKR-inspired (objectives + key results) but all
-user-facing language must say "goals" and "measurable outcomes". Never say "OKR", "objective",
-or "key result" to the user.
-
-Agents use this domain for quarterly planning, priority routing, and understanding which outcomes
-matter most right now.
-
-## Schema
-
-Source: `packages/core/src/organization-model/domains/goals.ts`
-
-```typescript
-GoalsDomainSchema = z.object({
-  objectives: z.array(ObjectiveSchema).default([])
-})
-
-ObjectiveSchema = z.object({
-  id:          z.string().trim().min(1).max(100),   // stable ID, e.g. "goal-grow-arr-q1-2026"
-  description: z.string().trim().min(1).max(1000),  // plain-language goal statement
-  periodStart: z.string().regex(ISO_DATE),          // YYYY-MM-DD — must be before periodEnd
-  periodEnd:   z.string().regex(ISO_DATE),          // YYYY-MM-DD — enforced in superRefine
-  keyResults:  z.array(KeyResultSchema).default([]) // measurable outcomes under this goal
-})
-
-KeyResultSchema = z.object({
-  id:           z.string().trim().min(1).max(100),  // e.g. "kr-revenue-q1"
-  description:  z.string().trim().min(1).max(500),  // e.g. "Increase trial-to-paid conversion"
-  targetMetric: z.string().trim().min(1).max(200),  // what is being measured, e.g. "monthly revenue"
-  currentValue: z.number().default(0),              // current tracked value
-  targetValue:  z.number().optional()               // target to hit (omit if directional)
-})
-```
-
-## Field reference
-
-| Field         | Type          | Notes                                                      |
-| ------------- | ------------- | ---------------------------------------------------------- |
-| `id`          | string (100)  | Stable key; e.g. `"goal-grow-arr-q1-2026"`                 |
-| `description` | string (1000) | Plain-language goal statement; min 1 char required         |
-| `periodStart` | string        | ISO date `YYYY-MM-DD`; must be strictly before `periodEnd` |
-| `periodEnd`   | string        | ISO date `YYYY-MM-DD`; enforced by `superRefine`           |
-| `keyResults`  | array         | Measurable outcomes under this goal; defaults to `[]`      |
-
-Key result fields:
-
-| Field          | Type         | Notes                                               |
-| -------------- | ------------ | --------------------------------------------------- |
-| `id`           | string (100) | Stable key; e.g. `"kr-revenue-q1"`                  |
-| `description`  | string (500) | What is being tracked; min 1 char required          |
-| `targetMetric` | string (200) | The metric name; e.g. `"monthly recurring revenue"` |
-| `currentValue` | number       | Current value; defaults to `0`                      |
-| `targetValue`  | number       | Optional target; omit if the outcome is directional |
-
-## Validation rules
-
-- `periodEnd` must be strictly after `periodStart`; enforced at parse time by
-  `OrganizationModelSchema.superRefine()`; setting equal dates is also invalid
-- Both `periodStart` and `periodEnd` must match `YYYY-MM-DD` ISO date format exactly
-- The internal field name for the goals array is `objectives` (not `goals`) — this is a
-  schema-level name, not user-facing vocabulary; always say "goals" to users
-- The internal field name for measurable outcomes is `keyResults` (not `outcomes`) — same
-  convention applies; say "measurable outcomes" to users
-- `targetValue` is optional for directional goals where there is no specific number target
-
-## Examples
-
-```typescript
-goals: {
-  objectives: [
-    {
-      id:          "goal-arr-q1-2026",
-      description: "Reach $50K MRR by end of Q1 2026",
-      periodStart: "2026-01-01",
-      periodEnd:   "2026-03-31",
-      keyResults: [
-        {
-          id:           "kr-mrr-q1",
-          description:  "Grow monthly recurring revenue",
-          targetMetric: "monthly recurring revenue (MRR)",
-          currentValue: 32000,
-          targetValue:  50000
-        },
-        {
-          id:           "kr-churn-q1",
-          description:  "Reduce monthly churn rate",
-          targetMetric: "monthly churn rate (%)",
-          currentValue: 4.2,
-          targetValue:  2.5
-        }
-      ]
-    }
-  ]
-}
-```
-
-## Where it lives in the adapter
-
-**Split projects:** `core/config/organization-model/profile.ts` under the `goals` key of
-`defineOrganizationModel({...})`.
-
-**Unsplit projects:** `core/config/organization-model.ts` under the same key.
-
-To read current goals: open the appropriate file and inspect the `goals.objectives` array, or
-use `pnpm exec elevasis-sdk om:cat goals` (external project).
-
-## Write path
-
-To add, edit, remove, or update progress on a goal, the `/om` skill runs the codify
-ceremony (`operations/codify-level-a.md`): snapshot → propose → confirm → write → typecheck →
-Zod parse → rollback on failure. Pass `targetFile` as
-`core/config/organization-model/profile.ts` for split projects, or
-`core/config/organization-model.ts` for unsplit projects. Only the `objectives` array is written;
-no other keys in the target file are touched. For progress-only updates (changing `currentValue`
-on an existing outcome), a targeted edit is preferred over rewriting the entire goals block.
-
----
-
-**Read via `/om`** (legacy `/knowledge` alias also accepted) — natural-language queries like
-"what are our goals this quarter?" or "what's the current MRR against target?" route to this
-domain via the skill's intent classifier.

package/reference/claude-config/skills/om/operations/identity.md

@@ -1,97 +0,0 @@
-# Identity domain
-
-The `identity` domain captures the organization's legal identity, purpose, and operational anchors.
-It is distinct from `branding` (display identity: logos, product names) — editing identity fields
-here does not touch any visual or branding configuration.
-
-## Schema
-
-Source: `packages/core/src/organization-model/domains/identity.ts`
-
-```typescript
-IdentityDomainSchema = z.object({
-  mission:          z.string().trim().max(1000).default(''),
-  vision:           z.string().trim().max(1000).default(''),
-  legalName:        z.string().trim().max(200).default(''),
-  entityType:       z.string().trim().max(100).default(''),    // e.g. "LLC", "Corporation"
-  jurisdiction:     z.string().trim().max(200).default(''),    // e.g. "United States – Delaware"
-  industryCategory: z.string().trim().max(200).default(''),    // e.g. "Marketing Agency"
-  geographicFocus:  z.string().trim().max(200).default(''),    // e.g. "North America"
-  timeZone:         z.string().trim().max(100).default('UTC'), // IANA identifier
-  businessHours:    BusinessHoursSchema                        // per-day { open, close } in HH:MM
-})
-```
-
-`BusinessHoursSchema` is an object with optional keys `monday` through `sunday`, each holding
-`{ open: "HH:MM", close: "HH:MM" }`. An empty object `{}` means not configured.
-
-## Field reference
-
-| Field              | Type   | Max  | Notes                                                    |
-| ------------------ | ------ | ---- | -------------------------------------------------------- |
-| `mission`          | string | 1000 | Why the organization exists                              |
-| `vision`           | string | 1000 | Where the organization is headed long-term               |
-| `legalName`        | string | 200  | Registered legal name                                    |
-| `entityType`       | string | 100  | e.g. "LLC", "Corporation", "Sole Proprietor"             |
-| `jurisdiction`     | string | 200  | e.g. "United States – Delaware", "Canada – Ontario"      |
-| `industryCategory` | string | 200  | e.g. "Marketing Agency", "SaaS", "Professional Services" |
-| `geographicFocus`  | string | 200  | e.g. "North America", "Global", "Southeast Asia"         |
-| `timeZone`         | string | 100  | IANA identifier, e.g. `America/Los_Angeles`              |
-| `businessHours`    | object | --   | Per-day `{ open: "HH:MM", close: "HH:MM" }`              |
-
-## Validation rules
-
-- All string fields default to empty string `''`; none are required to be non-empty at schema level
-- `timeZone` defaults to `"UTC"` when not set; agents should treat a value of `"UTC"` as
-  potentially unconfigured and surface it for review
-- `businessHours` defaults to `{}` (not configured); an empty object is valid
-- Per-day entries must follow `"HH:MM"` 24-hour format; the schema does not enforce range bounds
-  but convention is `00:00`–`23:59`
-- `jurisdiction` should use the format `"Country – Region"` (em dash, not hyphen) for
-  consistency across agents that parse it
-
-## Examples
-
-```typescript
-identity: {
-  mission:          "We help SMBs automate complex operations using AI.",
-  vision:           "A world where every business operates at the efficiency of a Fortune 500.",
-  legalName:        "Acme Operations LLC",
-  entityType:       "LLC",
-  jurisdiction:     "United States – Delaware",
-  industryCategory: "AI Automation / Professional Services",
-  geographicFocus:  "North America",
-  timeZone:         "America/Chicago",
-  businessHours: {
-    monday:    { open: "09:00", close: "17:00" },
-    tuesday:   { open: "09:00", close: "17:00" },
-    wednesday: { open: "09:00", close: "17:00" },
-    thursday:  { open: "09:00", close: "17:00" },
-    friday:    { open: "09:00", close: "17:00" }
-  }
-}
-```
-
-## Where it lives in the adapter
-
-**Split projects:** `core/config/organization-model/profile.ts` under the `identity` key of
-`defineOrganizationModel({...})`.
-
-**Unsplit projects:** `core/config/organization-model.ts` under the same key.
-
-To read the current values: open the appropriate file and inspect the `identity` block directly,
-or use `pnpm exec elevasis-sdk om:cat identity` (external project).
-
-## Write path
-
-To edit any field, the `/om` skill runs the codify ceremony
-(`operations/codify-level-a.md`): snapshot → propose → confirm → write → typecheck → Zod parse →
-rollback on failure. Pass `targetFile` as `core/config/organization-model/profile.ts` for split
-projects, or `core/config/organization-model.ts` for unsplit projects. Only the confirmed fields
-are written; no other top-level keys in the target file are touched.
-
----
-
-**Read via `/om`** (legacy `/knowledge` alias also accepted) — natural-language queries like
-"what's our identity set to?" or "what timezone are we in?" route to this domain via the skill's
-intent classifier.

package/reference/claude-config/skills/om/operations/labels.md

@@ -1,110 +0,0 @@
-# Labels domain
-
-`label` is an inline display field carried by status entries, stage entries, System entries,
-knowledge nodes, registry entries, and sidebar surfaces in the OrganizationModel. Labels control what users see in the UI and what
-agents say when narrating state. Editing a label does not change the entry's `id` or
-`semanticClass` -- only the human-readable display string. This is Level A only (config-only
-edits to a single file under `core/config/`).
-
-## What carries labels
-
-The following model elements have editable inline `label` fields:
-
-**Status / stage entries.** Each domain that carries an enum-like array exposes per-entry labels:
-
-- `sales.statuses` -- deal pipeline stages.
-- `prospecting.statuses` -- lead lifecycle stages.
-- `projects.statuses` -- project and task stages.
-
-Source of platform defaults: `packages/core/src/organization-model/domains/{sales,prospecting,projects}.ts`.
-
-Each status entry shape:
-
-```typescript
-{ id: 'new', label: 'New Lead', semanticClass: 'active', color: 'blue' }
-```
-
-**Systems.** The `label` field on a System entry. Editing it changes agent narration and any
-System-derived shell text, but it does not change the System `id`, route path, or graph node id.
-
-**Sidebar surfaces.** Routeable leaves under `navigation.sidebar.primary` and
-`navigation.sidebar.bottom` carry labels. Editing changes nav item and breadcrumb display without
-changing the route path or target System refs.
-
-**Knowledge/domain entries.** Knowledge nodes, customers, offerings, goals, roles, resources,
-actions, entities, and policies may carry labels or titles depending on the domain. Edit only the
-display field that already exists on the entry.
-
-## What is NOT in scope
-
-`id` and `semanticClass` of any entry must never change in a label edit -- they are structural
-anchors used by code, hooks, and workflow adapters. Only `label` (and optionally `color` or
-`icon`) are in scope. To rename an `id`, escalate to a separate Level B refactor with explicit
-confirmation, because every consumer that references the old `id` must be updated in the same
-change.
-
-## Validation rules
-
-- `label` is non-empty, max 120 characters.
-- `id` and `semanticClass` are unchanged from the previous state.
-- Entries not being edited remain byte-identical in the output -- partial array rewrites are
-  preferred over wholesale array replacement to minimize diff surface.
-
-## Realistic examples
-
-Rename two sales statuses:
-
-```
-Domain: sales (deal pipeline)
-  new:           "New Lead"        -> "Inbound Lead"
-  proposal:      "Proposal Sent"   -> "Proposal Out"
-  negotiation:   (unchanged)
-```
-
-Rename a System label without changing its ID:
-
-```
-systems:
-  sales.crm:     label "CRM"            -> "Sales Pipeline"
-  (id stays 'sales.crm'; graph node remains 'system:sales.crm')
-```
-
-Rename a sidebar surface:
-
-```
-navigation.sidebar.primary:
-  sales.crm:     label "Pipeline"       -> "Deal Pipeline"
-```
-
-## Where it lives
-
-**Split projects:** the target file depends on what carries the label being edited:
-
-- Status/stage entries and System entries -- `core/config/organization-model/systems.ts`
-- Sidebar navigation surfaces -- `core/config/organization-model/navigation.ts`
-- Business-profile domain entries (customers, offerings, roles, goals) -- `core/config/organization-model/profile.ts`
-
-**Unsplit projects:** `core/config/organization-model.ts` for all label edits.
-
-Pass the appropriate path as `targetFile` when invoking `operations/codify-level-a.md`.
-
-**Note:** `labels` is not currently authored as a standalone top-level domain key in either the
-template or reference tenant model. Label fields are inline properties on the entries listed
-above. Do not invent a top-level `labels` key in `profile.ts`.
-
-## Validation gate
-
-Every label change must pass before codify completes:
-
-1. `pnpm -C operations check-types`.
-2. `resolveOrganizationModel()` and `OrganizationModelSchema.parse()` succeed on the merged result.
-
-On failure, the codify ceremony rolls back. See `operations/codify-level-a.md` for the rollback
-procedure.
-
----
-
-> **Read via `/om`** (legacy `/knowledge` alias also accepted) -- natural-language queries like
-> "what's the label for the proposal stage?" or "what do we call the SEO System?" route to this
-> domain via the skill's intent classifier. To rename one or more labels, the `/om` skill triggers
-> the codify ceremony when intent classifies as Codify.

package/reference/claude-config/skills/om/operations/offerings.md

@@ -1,114 +0,0 @@
-# Offerings domain
-
-The `offerings` domain describes what the organization sells or delivers — a catalog of products
-and services modeled after the Business Model Canvas "Value Propositions". Agents use offerings
-for quoting, proposal generation, and scope-of-work reasoning.
-
-## Schema
-
-Source: `packages/core/src/organization-model/domains/offerings.ts`
-
-```typescript
-OfferingsDomainSchema = z.object({
-  products: z.array(ProductSchema).default([])
-})
-
-ProductSchema = z.object({
-  id:                z.string().trim().min(1).max(100),       // stable ID, e.g. "product-starter-plan"
-  name:              z.string().trim().max(200).default(''),  // display name
-  description:       z.string().trim().max(2000).default(''), // what it delivers
-  pricingModel:      PricingModelSchema.default('custom'),    // 'one-time' | 'subscription' | 'usage-based' | 'custom'
-  price:             z.number().min(0).default(0),            // base price amount (>= 0)
-  currency:          z.string().trim().max(10).default('USD'),// ISO 4217, e.g. "USD", "EUR"
-  targetSegmentIds:  z.array(z.string()).default([]),         // must ref customers.segments[].id
-  deliverySystemId: z.string().optional()                     // optional ref to systems[].id
-})
-```
-
-`pricingModel` values:
-
-- `one-time` -- single purchase (setup fee, project fee)
-- `subscription` -- recurring (monthly/annual SaaS, retainer)
-- `usage-based` -- metered by consumption (API calls, seats)
-- `custom` -- negotiated or bespoke pricing
-
-## Field reference
-
-| Field              | Type     | Max  | Notes                                                    |
-| ------------------ | -------- | ---- | -------------------------------------------------------- |
-| `id`               | string   | 100  | Stable key, min 1 char; e.g. `"product-starter-plan"`    |
-| `name`             | string   | 200  | Display name                                             |
-| `description`      | string   | 2000 | What this product or service delivers                    |
-| `pricingModel`     | enum     | --   | `one-time`, `subscription`, `usage-based`, or `custom`   |
-| `price`            | number   | --   | Base price amount, min 0; use 0 for fully custom pricing |
-| `currency`         | string   | 10   | ISO 4217 code; defaults to `"USD"`                       |
-| `targetSegmentIds` | string[] | --   | Each entry must reference a `customers.segments[].id`    |
-| `deliverySystemId` | string   | --   | Optional reference to a `systems[].id`                   |
-
-## Validation rules
-
-- `id` is the stable key; changing it after creation is a breaking change for any downstream
-  references
-- `targetSegmentIds` entries must exist in `customers.segments[].id`; the schema enforces this
-  at parse time — missing references cause `resolveOrganizationModel()` to fail
-- `deliverySystemId` (when present) must exist in `systems[].id`; same parse-time enforcement
-- `price` must be >= 0; use 0 when pricing is fully custom or not yet set
-- `currency` must be a valid ISO 4217 code by convention (the schema only validates length)
-- Cross-reference: if a product is removed, surface any `targetSegmentIds` in other products
-  that reference the removed ID
-
-## Examples
-
-```typescript
-offerings: {
-  products: [
-    {
-      id:               "product-full-service-retainer",
-      name:             "Full-Service Retainer",
-      description:      "End-to-end campaign delivery, reporting, and optimization for SMB clients.",
-      pricingModel:     "subscription",
-      price:            2500,
-      currency:         "USD",
-      targetSegmentIds: ["segment-smb-agencies"],
-      deliverySystemId: undefined
-    },
-    {
-      id:               "product-one-time-audit",
-      name:             "One-Time Operations Audit",
-      description:      "Single-engagement review of current workflows with a remediation roadmap.",
-      pricingModel:     "one-time",
-      price:            1500,
-      currency:         "USD",
-      targetSegmentIds: ["segment-smb-agencies"],
-      deliverySystemId: undefined
-    }
-  ]
-}
-```
-
-## Where it lives in the adapter
-
-**Split projects:** `core/config/organization-model/profile.ts` under the `offerings` key of
-`defineOrganizationModel({...})`.
-
-**Unsplit projects:** `core/config/organization-model.ts` under the same key.
-
-To read current products: open the appropriate file and inspect the `offerings.products` array,
-or use `pnpm exec elevasis-sdk om:cat offerings` (external project).
-
-## Write path
-
-To add, edit, or remove a product, the `/om` skill runs the codify ceremony
-(`operations/codify-level-a.md`): snapshot → propose → confirm → write → typecheck → Zod parse →
-rollback on failure. Pass `targetFile` as `core/config/organization-model/profile.ts` for split
-projects, or `core/config/organization-model.ts` for unsplit projects. Only the `products` array
-is written; no other keys in the target file are touched. Before writing, the skill verifies all
-`targetSegmentIds` and `deliverySystemId` references resolve. When adding, append to the array.
-When editing, replace by `id`. When removing, filter out — and surface any dangling references
-first.
-
----
-
-**Read via `/om`** (legacy `/knowledge` alias also accepted) — natural-language queries like
-"what do we sell?" or "what's the pricing on the retainer?" route to this domain via the skill's
-intent classifier.

package/reference/claude-config/skills/om/operations/roles.md

@@ -1,104 +0,0 @@
-# Roles domain
-
-The `roles` domain describes who does what inside the organization — a role chart inspired by the
-EOS Accountability Chart but using plain-language field names throughout. Agents use this domain
-for HITL routing, escalation logic, and approval-rights reasoning.
-
-Field names are developer-facing; when narrating to users, say "role", "responsibilities",
-"reports to", and "held by". Do not say "seat", "accountability", or "EOS".
-
-## Schema
-
-Source: `packages/core/src/organization-model/domains/roles.ts`
-
-```typescript
-RolesDomainSchema = z.object({
-  roles: z.array(RoleSchema).default([])
-})
-
-RoleSchema = z.object({
-  id:               z.string().trim().min(1).max(100),              // stable ID, e.g. "role-ceo"
-  title:            z.string().trim().min(1).max(200),              // display title, e.g. "CEO"
-  responsibilities: z.array(z.string().trim().max(500)).default([]),// what this role owns
-  reportsToId:      z.string().trim().min(1).max(100).optional(),   // must ref another roles[].id
-  heldBy:           z.string().trim().max(200).optional()           // name or email, free-form
-})
-```
-
-## Field reference
-
-| Field              | Type     | Max | Notes                                                           |
-| ------------------ | -------- | --- | --------------------------------------------------------------- |
-| `id`               | string   | 100 | Stable key, min 1 char; e.g. `"role-ceo"`                       |
-| `title`            | string   | 200 | Display title; min 1 char required                              |
-| `responsibilities` | string[] | 500 | Each item: one thing this role is accountable for               |
-| `reportsToId`      | string   | 100 | Optional; must reference another `roles[].id` in the collection |
-| `heldBy`           | string   | 200 | Optional; name or email of the person holding this role         |
-
-## Validation rules
-
-- `reportsToId` (when present) must resolve to another `roles[].id` in the same collection;
-  enforced at parse time by `OrganizationModelSchema.superRefine()`
-- Absence of `reportsToId` indicates a top-level role (no reporting line)
-- Cycle detection is not enforced by the schema (known limitation); agents should surface
-  obvious cycles (e.g. role A reports to role B which reports to role A)
-- `heldBy` is free-form; no validation beyond max length
-- An empty roles array means no HITL routing or escalation rules are available
-
-## Examples
-
-```typescript
-roles: {
-  roles: [
-    {
-      id:               "role-ceo",
-      title:            "CEO",
-      responsibilities: [
-        "Set company direction",
-        "Final approval on deals >$10K",
-        "Manage investor relations"
-      ],
-      reportsToId: undefined,
-      heldBy:      "Alice Johnson"
-    },
-    {
-      id:               "role-head-of-client-success",
-      title:            "Head of Client Success",
-      responsibilities: [
-        "Own client health scores",
-        "Lead quarterly business reviews",
-        "Handle escalations"
-      ],
-      reportsToId: "role-ceo",
-      heldBy:      undefined
-    }
-  ]
-}
-```
-
-## Where it lives in the adapter
-
-**Split projects:** `core/config/organization-model/profile.ts` under the `roles` key of
-`defineOrganizationModel({...})`.
-
-**Unsplit projects:** `core/config/organization-model.ts` under the same key.
-
-To read the current role chart: open the appropriate file and inspect the `roles.roles` array,
-or use `pnpm exec elevasis-sdk om:cat roles` (external project).
-
-## Write path
-
-To add, edit, or remove a role, the `/om` skill runs the codify ceremony
-(`operations/codify-level-a.md`): snapshot → propose → confirm → write → typecheck → Zod parse →
-rollback on failure. Pass `targetFile` as `core/config/organization-model/profile.ts` for split
-projects, or `core/config/organization-model.ts` for unsplit projects. Only the `roles` array is
-written; no other keys in the target file are touched. Before writing, the skill verifies all
-`reportsToId` references resolve to IDs that will exist after the write. When removing a role,
-the skill surfaces any other roles that `reportsToId` to it and asks whether to clear those
-reporting lines before proceeding.
-
----
-
-**Read via `/om`** (legacy `/knowledge` alias also accepted) — natural-language queries like
-"who is responsible for client escalations?" or "list my roles" route to this domain via the
-skill's intent classifier.