@elevasis/sdk 1.8.2 → 1.9.0

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

@@ -1,128 +1,128 @@
-# Configure: labels
-
-Guides the user through editing inline display labels on enum entries in the organization model.
-
-Labels are the `label` field carried by status entries, stage entries, and other enum-like
-elements in the model. They 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 operation is Level A only (config-only edits to `foundations/config/organization-model.ts`).
-No new TypeScript files are created.
-
-## What has labels
-
-The following model elements carry inline `label` fields that are editable here:
-
-**Statuses (sales domain -- deal pipeline stages):**
-Located in `foundations/config/organization-model.ts` under `sales.statuses` or in the platform
-defaults at `packages/core/src/organization-model/domains/sales.ts`.
-
-Each status entry shape (example):
-
-```typescript
-{ id: 'new', label: 'New Lead', semanticClass: 'active', color: 'blue' }
-```
-
-**Statuses (prospecting domain -- lead lifecycle stages):**
-Located under `prospecting.statuses` or in `packages/core/src/organization-model/domains/prospecting.ts`.
-
-**Statuses (projects domain -- project and task stages):**
-Located under `projects.statuses` or in `packages/core/src/organization-model/domains/projects.ts`.
-
-**Features (`label` field):**
-The display label on a feature entry (e.g. changing "CRM" to "Sales Pipeline"). Editing this
-changes sidebar nav text and any agent narration that references the feature by label.
-
-**Navigation surfaces (`label` field):**
-Surface entries in the `navigation.surfaces` array each carry a `label`. Editing changes
-breadcrumb text and nav item display.
-
-The `id` and `semanticClass` of any entry must never be changed here -- those are structural
-anchors. Only `label` (and optionally `color` or `icon`) are in scope for this operation.
-
----
-
-## Process
-
-### Step 1: Read current state
-
-Ask the user which domain's labels they want to edit:
-
-- Deal pipeline stages (sales)
-- Lead lifecycle stages (prospecting)
-- Project/task stages (projects)
-- Feature names
-- Navigation surface names
-
-Read `foundations/config/organization-model.ts` and the relevant platform defaults file for the
-selected domain. Present all current label values for that domain:
-
-```
-Current labels -- sales (deal pipeline stages):
-  new              "New Lead"
-  contacted        "Contacted"
-  qualified        "Qualified"
-  proposal         "Proposal Sent"
-  negotiation      "In Negotiation"
-  closed_won       "Closed Won"
-  closed_lost      "Closed Lost"
-```
-
-### Step 2: Gather changes
-
-Ask which labels the user wants to change. Work one at a time or accept a list:
-
-- "Which label do you want to rename? (by current label or ID)"
-- "What should it say instead?"
-
-Validate:
-
-- Max 120 characters
-- Non-empty
-- No change to the `id` or `semanticClass`
-
-If the user wants to change a `color` or `icon` alongside the label, accept that too.
-
-### Step 3: Confirm before writing
-
-Present a diff:
-
-```
-Proposed label changes -- sales:
-  new:          "New Lead" -> "Inbound Lead"
-  proposal:     "Proposal Sent" -> "Proposal Out"
-  negotiation:  (unchanged)
-
-Apply? (yes/no)
-```
-
-### Step 4: Codify
-
-Execute `.claude/skills/configure/operations/codify-level-a.md`.
-
-The write targets only the affected entries in the selected domain array. Entries not being
-changed are left exactly as they are. The `id` and `semanticClass` of every entry must remain
-unchanged in the output.
-
-### Step 5: Report
-
-After successful validation:
-
-```
-Labels updated.
-  Domain: {domain name}
-  Changed: {list of id: "old" -> "new"}
-  foundations/config/organization-model.ts -- {domain}.statuses updated
-  Type-check: PASS
-  Schema validation: PASS
-```
-
-If validation failed and rollback occurred:
-
-```
-Labels update rolled back.
-  Reason: {error message}
-  foundations/config/organization-model.ts -- restored to previous state
-  No changes persisted.
-```
+# Configure: labels
+
+Guides the user through editing inline display labels on enum entries in the organization model.
+
+Labels are the `label` field carried by status entries, stage entries, and other enum-like
+elements in the model. They 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 operation is Level A only (config-only edits to `foundations/config/organization-model.ts`).
+No new TypeScript files are created.
+
+## What has labels
+
+The following model elements carry inline `label` fields that are editable here:
+
+**Statuses (sales domain -- deal pipeline stages):**
+Located in `foundations/config/organization-model.ts` under `sales.statuses` or in the platform
+defaults at `packages/core/src/organization-model/domains/sales.ts`.
+
+Each status entry shape (example):
+
+```typescript
+{ id: 'new', label: 'New Lead', semanticClass: 'active', color: 'blue' }
+```
+
+**Statuses (prospecting domain -- lead lifecycle stages):**
+Located under `prospecting.statuses` or in `packages/core/src/organization-model/domains/prospecting.ts`.
+
+**Statuses (projects domain -- project and task stages):**
+Located under `projects.statuses` or in `packages/core/src/organization-model/domains/projects.ts`.
+
+**Features (`label` field):**
+The display label on a feature entry (e.g. changing "CRM" to "Sales Pipeline"). Editing this
+changes sidebar nav text and any agent narration that references the feature by label.
+
+**Navigation surfaces (`label` field):**
+Surface entries in the `navigation.surfaces` array each carry a `label`. Editing changes
+breadcrumb text and nav item display.
+
+The `id` and `semanticClass` of any entry must never be changed here -- those are structural
+anchors. Only `label` (and optionally `color` or `icon`) are in scope for this operation.
+
+---
+
+## Process
+
+### Step 1: Read current state
+
+Ask the user which domain's labels they want to edit:
+
+- Deal pipeline stages (sales)
+- Lead lifecycle stages (prospecting)
+- Project/task stages (projects)
+- Feature names
+- Navigation surface names
+
+Read `foundations/config/organization-model.ts` and the relevant platform defaults file for the
+selected domain. Present all current label values for that domain:
+
+```
+Current labels -- sales (deal pipeline stages):
+  new              "New Lead"
+  contacted        "Contacted"
+  qualified        "Qualified"
+  proposal         "Proposal Sent"
+  negotiation      "In Negotiation"
+  closed_won       "Closed Won"
+  closed_lost      "Closed Lost"
+```
+
+### Step 2: Gather changes
+
+Ask which labels the user wants to change. Work one at a time or accept a list:
+
+- "Which label do you want to rename? (by current label or ID)"
+- "What should it say instead?"
+
+Validate:
+
+- Max 120 characters
+- Non-empty
+- No change to the `id` or `semanticClass`
+
+If the user wants to change a `color` or `icon` alongside the label, accept that too.
+
+### Step 3: Confirm before writing
+
+Present a diff:
+
+```
+Proposed label changes -- sales:
+  new:          "New Lead" -> "Inbound Lead"
+  proposal:     "Proposal Sent" -> "Proposal Out"
+  negotiation:  (unchanged)
+
+Apply? (yes/no)
+```
+
+### Step 4: Codify
+
+Execute `.claude/skills/configure/operations/codify-level-a.md`.
+
+The write targets only the affected entries in the selected domain array. Entries not being
+changed are left exactly as they are. The `id` and `semanticClass` of every entry must remain
+unchanged in the output.
+
+### Step 5: Report
+
+After successful validation:
+
+```
+Labels updated.
+  Domain: {domain name}
+  Changed: {list of id: "old" -> "new"}
+  foundations/config/organization-model.ts -- {domain}.statuses updated
+  Type-check: PASS
+  Schema validation: PASS
+```
+
+If validation failed and rollback occurred:
+
+```
+Labels update rolled back.
+  Reason: {error message}
+  foundations/config/organization-model.ts -- restored to previous state
+  No changes persisted.
+```

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

@@ -1,159 +1,159 @@
-# Configure: offerings
-
-Guides the user through reviewing and updating the `offerings` domain of the organization model.
-
-The `offerings` domain describes what the organization sells or delivers — a catalog of products
-and services modeled after Business Model Canvas "Value Propositions". Agents use offerings for
-quoting, proposal generation, and scope-of-work reasoning.
-
-## Schema reference
-
-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
-  deliveryFeatureId: z.string().optional()                   // optional ref to features[].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
-
-Cross-reference constraints enforced at parse time:
-
-- `targetSegmentIds` entries must exist in `customers.segments[].id`
-- `deliveryFeatureId` (when present) must exist in `features[].id`
-
-Where this lands in the adapter: `foundations/config/organization-model.ts` under the `offerings`
-key of `defineOrganizationModel({...})`.
-
----
-
-## Process
-
-### Step 1: Read current state
-
-Read `foundations/config/organization-model.ts` and extract the current `offerings.products` array.
-Also extract `customers.segments` (for cross-reference display) and `features` (for
-`deliveryFeatureId` reference).
-
-Present a summary:
-
-```
-Current offerings (N):
-  1. {name} ({id}) — {pricingModel} — {price} {currency}
-     Targets: {segment names or "(none)"}
-  (none defined yet)
-```
-
-### Step 2: Establish intent
-
-Ask whether the user wants to:
-
-- **Add** a new product/service
-- **Edit** an existing product (by name or number)
-- **Remove** a product
-- **Review all** in detail
-
-### Step 3: Gather product details
-
-For each product being added or edited:
-
-**Core identity:**
-
-- "What's the name of this offering? (e.g. 'Starter Plan', 'Full-Service Retainer', 'One-Time Audit')"
-- "Give it a stable ID — lowercase with hyphens, like `product-starter-plan`."
-- "Describe what this product/service delivers in one or two sentences."
-
-**Pricing:**
-
-- "How is this priced? Options: one-time payment, subscription (recurring), usage-based (metered),
-  or custom/negotiated."
-- "What's the base price? (Enter 0 if pricing is fully custom or not yet set.)"
-- "What currency? (Default: USD)"
-
-**Targeting:**
-
-- "Which customer segments does this offering target?"
-  Show the available segments by name. The user can select by name; translate to IDs.
-  If no segments are defined yet, note this and suggest configuring customers first.
-
-**Platform delivery (optional):**
-
-- "Is there a platform feature responsible for delivering this offering? (e.g. the CRM feature,
-  the Projects feature)" Show available feature IDs. This field is optional.
-
-If a field already has a value, show it and ask "Keep this or update it?"
-
-### Step 4: Confirm before writing
-
-Present a diff for the affected product(s):
-
-```
-Proposed offerings change:
-
-ADD product "Full-Service Retainer" (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"]
-  deliveryFeatureId: (not set)
-
-Apply? (yes/no)
-```
-
-### Step 5: Cross-reference validation
-
-Before writing, verify:
-
-1. Every `targetSegmentIds` entry exists in the current `customers.segments[].id` array in the
-   adapter. If any are missing, surface the discrepancy and ask whether to add the missing segment
-   first or proceed without the reference.
-2. If `deliveryFeatureId` is provided, verify it exists in `features[].id`. If not found, surface
-   a warning and offer to omit the field.
-
-### Step 6: Codify
-
-Execute `.claude/skills/configure/operations/codify-level-a.md` with the proposed `offerings`
-block. Only the `products` array is written — no other keys in the adapter are touched.
-
-When adding a product, append to the array. When editing, replace by `id`. When removing, filter
-out and also surface any `targetSegmentIds` in other products referencing the removed ID.
-
-### Step 7: Report
-
-After successful validation:
-
-```
-Offerings updated.
-  Products: {total count} ({N added / N edited / N removed})
-  foundations/config/organization-model.ts — offerings.products updated
-  Type-check: PASS
-  Schema validation: PASS
-```
-
-If validation failed and rollback occurred:
-
-```
-Offerings update rolled back.
-  Reason: {error message}
-  foundations/config/organization-model.ts — restored to previous state
-  No changes persisted.
-```
+# Configure: offerings
+
+Guides the user through reviewing and updating the `offerings` domain of the organization model.
+
+The `offerings` domain describes what the organization sells or delivers — a catalog of products
+and services modeled after Business Model Canvas "Value Propositions". Agents use offerings for
+quoting, proposal generation, and scope-of-work reasoning.
+
+## Schema reference
+
+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
+  deliveryFeatureId: z.string().optional()                   // optional ref to features[].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
+
+Cross-reference constraints enforced at parse time:
+
+- `targetSegmentIds` entries must exist in `customers.segments[].id`
+- `deliveryFeatureId` (when present) must exist in `features[].id`
+
+Where this lands in the adapter: `foundations/config/organization-model.ts` under the `offerings`
+key of `defineOrganizationModel({...})`.
+
+---
+
+## Process
+
+### Step 1: Read current state
+
+Read `foundations/config/organization-model.ts` and extract the current `offerings.products` array.
+Also extract `customers.segments` (for cross-reference display) and `features` (for
+`deliveryFeatureId` reference).
+
+Present a summary:
+
+```
+Current offerings (N):
+  1. {name} ({id}) — {pricingModel} — {price} {currency}
+     Targets: {segment names or "(none)"}
+  (none defined yet)
+```
+
+### Step 2: Establish intent
+
+Ask whether the user wants to:
+
+- **Add** a new product/service
+- **Edit** an existing product (by name or number)
+- **Remove** a product
+- **Review all** in detail
+
+### Step 3: Gather product details
+
+For each product being added or edited:
+
+**Core identity:**
+
+- "What's the name of this offering? (e.g. 'Starter Plan', 'Full-Service Retainer', 'One-Time Audit')"
+- "Give it a stable ID — lowercase with hyphens, like `product-starter-plan`."
+- "Describe what this product/service delivers in one or two sentences."
+
+**Pricing:**
+
+- "How is this priced? Options: one-time payment, subscription (recurring), usage-based (metered),
+  or custom/negotiated."
+- "What's the base price? (Enter 0 if pricing is fully custom or not yet set.)"
+- "What currency? (Default: USD)"
+
+**Targeting:**
+
+- "Which customer segments does this offering target?"
+  Show the available segments by name. The user can select by name; translate to IDs.
+  If no segments are defined yet, note this and suggest configuring customers first.
+
+**Platform delivery (optional):**
+
+- "Is there a platform feature responsible for delivering this offering? (e.g. the CRM feature,
+  the Projects feature)" Show available feature IDs. This field is optional.
+
+If a field already has a value, show it and ask "Keep this or update it?"
+
+### Step 4: Confirm before writing
+
+Present a diff for the affected product(s):
+
+```
+Proposed offerings change:
+
+ADD product "Full-Service Retainer" (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"]
+  deliveryFeatureId: (not set)
+
+Apply? (yes/no)
+```
+
+### Step 5: Cross-reference validation
+
+Before writing, verify:
+
+1. Every `targetSegmentIds` entry exists in the current `customers.segments[].id` array in the
+   adapter. If any are missing, surface the discrepancy and ask whether to add the missing segment
+   first or proceed without the reference.
+2. If `deliveryFeatureId` is provided, verify it exists in `features[].id`. If not found, surface
+   a warning and offer to omit the field.
+
+### Step 6: Codify
+
+Execute `.claude/skills/configure/operations/codify-level-a.md` with the proposed `offerings`
+block. Only the `products` array is written — no other keys in the adapter are touched.
+
+When adding a product, append to the array. When editing, replace by `id`. When removing, filter
+out and also surface any `targetSegmentIds` in other products referencing the removed ID.
+
+### Step 7: Report
+
+After successful validation:
+
+```
+Offerings updated.
+  Products: {total count} ({N added / N edited / N removed})
+  foundations/config/organization-model.ts — offerings.products updated
+  Type-check: PASS
+  Schema validation: PASS
+```
+
+If validation failed and rollback occurred:
+
+```
+Offerings update rolled back.
+  Reason: {error message}
+  foundations/config/organization-model.ts — restored to previous state
+  No changes persisted.
+```