@elevasis/sdk 1.21.0 → 1.22.1

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

@@ -1,99 +1,99 @@
-# 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
-
-`core/config/organization-model.ts` under the `roles` key of
-`defineOrganizationModel({...})`.
-
-To read the current role chart: open the adapter file and inspect the `roles.roles` array, or
-use `pnpm exec elevasis-sdk knowledge:cat roles` (external project).
-
-## Write path
-
-To add, edit, or remove a role, the `/knowledge` skill runs the codify ceremony
-(`operations/codify-level-a.md`): snapshot → propose → confirm → write → typecheck → Zod parse →
-rollback on failure. Only the `roles` array is written; no other keys in the adapter 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 `/knowledge`** — natural-language queries like "who is responsible for client
-escalations?" or "list my roles" route to this domain via the skill's intent classifier.
+# 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
+
+`core/config/organization-model.ts` under the `roles` key of
+`defineOrganizationModel({...})`.
+
+To read the current role chart: open the adapter file and inspect the `roles.roles` array, or
+use `pnpm exec elevasis-sdk knowledge:cat roles` (external project).
+
+## Write path
+
+To add, edit, or remove a role, the `/knowledge` skill runs the codify ceremony
+(`operations/codify-level-a.md`): snapshot → propose → confirm → write → typecheck → Zod parse →
+rollback on failure. Only the `roles` array is written; no other keys in the adapter 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 `/knowledge`** — natural-language queries like "who is responsible for client
+escalations?" or "list my roles" route to this domain via the skill's intent classifier.

package/reference/claude-config/skills/knowledge/operations/techStack.md

@@ -1,30 +1,30 @@
-# TechStack Context
-
-Tech stack information is no longer modeled through `resourceMappings`. Resource identity and governance metadata live in OM Resources descriptors under `organizationModel.resources.entries`; external platform context belongs on the relevant integration descriptor or in project knowledge when the descriptor schema does not expose a dedicated field yet.
-
-## Current Resource-Governance Contract
-
-- Resource IDs are authored once in `core/config/organization-model.ts`.
-- Runtime workflows, agents, and integrations derive `resourceId` / `type` from OM descriptors during deployment assembly.
-- `DeploymentSpec` remains the runtime/deploy bundle, not an independent identity catalog.
-- `pnpm -C operations check` validates descriptor/code alignment before deploy.
-
-## Where To Look
-
-- `core/config/organization-model.ts` -- Systems and Resources descriptors.
-- `operations/src/index.ts` -- deployment assembly that binds executable behavior to descriptors.
-- `pnpm elevasis-sdk project:list --pretty` -- live deployed resource surface.
-- Project knowledge nodes -- narrative details such as credential owner, setup notes, and system-of-record rationale when they do not fit the descriptor shape.
-
-## Write Path
-
-When the user wants to document or change integration ownership, credential status, or system-of-record context:
-
-1. Inspect `core/config/organization-model.ts` for the relevant integration Resource descriptor.
-2. If the descriptor identity, System membership, owner role, or status is wrong, update the descriptor through the `/knowledge` ceremony where possible.
-3. If the requested detail is operational narrative rather than descriptor schema, capture it in a knowledge node or project documentation instead of recreating `resourceMappings`.
-4. Run `pnpm -C operations check` after descriptor or deployment assembly changes.
-
----
-
-**Read via `/knowledge`** -- natural-language queries like "what integrations are configured?" or "is HubSpot our system of record for contacts?" route here for inspection and recommendation.
+# TechStack Context
+
+Tech stack information is no longer modeled through `resourceMappings`. Resource identity and governance metadata live in OM Resources descriptors under the id-keyed `organizationModel.resources` map; external platform context belongs on the relevant integration descriptor or in project knowledge when the descriptor schema does not expose a dedicated field yet.
+
+## Current Resource-Governance Contract
+
+- Resource IDs are authored once in `core/config/organization-model.ts`.
+- Runtime workflows, agents, and integrations derive `resourceId` / `type` from OM descriptors during deployment assembly.
+- `DeploymentSpec` remains the runtime/deploy bundle, not an independent identity catalog.
+- `pnpm -C operations check` validates descriptor/code alignment before deploy.
+
+## Where To Look
+
+- `core/config/organization-model.ts` -- Systems and Resources descriptors.
+- `operations/src/index.ts` -- deployment assembly that binds executable behavior to descriptors.
+- `pnpm elevasis-sdk project:list --pretty` -- live deployed resource surface.
+- Project knowledge nodes -- narrative details such as credential owner, setup notes, and system-of-record rationale when they do not fit the descriptor shape.
+
+## Write Path
+
+When the user wants to document or change integration ownership, credential status, or system-of-record context:
+
+1. Inspect `core/config/organization-model.ts` for the relevant integration Resource descriptor.
+2. If the descriptor identity, System membership, owner role, or status is wrong, update the descriptor through the `/knowledge` ceremony where possible.
+3. If the requested detail is operational narrative rather than descriptor schema, capture it in a knowledge node or project documentation instead of recreating `resourceMappings`.
+4. Run `pnpm -C operations check` after descriptor or deployment assembly changes.
+
+---
+
+**Read via `/knowledge`** -- natural-language queries like "what integrations are configured?" or "is HubSpot our system of record for contacts?" route here for inspection and recommendation.