@elevasis/sdk 1.15.1 → 1.17.0

package/reference/scaffold/reference/feature-registry.md

@@ -16,6 +16,7 @@ description: Auto-generated catalog of registered feature manifests. Do not edit
 | --- | --- | --- | --- | --- |
 | `crm` | `sales.crm` | — | — | — |
 | `delivery` | `projects` | — | — | — |
+| `knowledge` | `knowledge` | — | — | — |
 | `lead-gen` | `sales.lead-gen` | — | — | — |
 | `monitoring` | `monitoring` | — | — | — |
 | `operations` | `operations` | — | — | — |
@@ -30,7 +31,7 @@ Feature IDs defined in `DEFAULT_ORGANIZATION_MODEL.features` (`packages/core/src
 
 ```typescript
 // FeatureSchema: { id, label, enabled, color?, icon?, entityIds, surfaceIds, resourceIds, capabilityIds }
-type DefaultFeatureId = 'dashboard' | 'sales' | 'sales.crm' | 'sales.lead-gen' | 'projects' | 'operations' | 'operations.command-view' | 'operations.overview' | 'operations.resources' | 'operations.command-queue' | 'operations.sessions' | 'operations.task-scheduler' | 'monitoring' | 'monitoring.activity-log' | 'monitoring.execution-logs' | 'monitoring.execution-health' | 'monitoring.cost-analytics' | 'monitoring.notifications' | 'monitoring.submitted-requests' | 'settings' | 'settings.account' | 'settings.appearance' | 'settings.roles' | 'settings.organization' | 'settings.credentials' | 'settings.api-keys' | 'settings.webhooks' | 'settings.deployments' | 'admin' | 'admin.system-health' | 'admin.organizations' | 'admin.users' | 'admin.design-showcase' | 'admin.debug' | 'archive' | 'archive.agent-chat' | 'archive.execution-runner' | 'seo'
+type DefaultFeatureId = 'dashboard' | 'identity' | 'platform' | 'finance' | 'sales' | 'sales.crm' | 'sales.lead-gen' | 'projects' | 'operations' | 'knowledge.command-view' | 'operations.overview' | 'operations.resources' | 'operations.command-queue' | 'operations.sessions' | 'operations.task-scheduler' | 'monitoring' | 'monitoring.activity-log' | 'monitoring.execution-logs' | 'monitoring.execution-health' | 'monitoring.cost-analytics' | 'monitoring.notifications' | 'monitoring.submitted-requests' | 'settings' | 'settings.account' | 'settings.appearance' | 'settings.roles' | 'settings.organization' | 'settings.credentials' | 'settings.api-keys' | 'settings.webhooks' | 'settings.deployments' | 'admin' | 'admin.system-health' | 'admin.organizations' | 'admin.users' | 'admin.design-showcase' | 'admin.debug' | 'archive' | 'archive.agent-chat' | 'archive.execution-runner' | 'seo' | 'knowledge' | 'knowledge.base'
 ```
 
 These are the built-in feature IDs. The `featureId` field on a `FeatureModule` manifest must match the `id` of a feature in the organization model to enable access-flag gating.

package/reference/scaffold/ui/composition-extensibility.mdx

@@ -211,6 +211,23 @@ All primitives above flow through published subpaths (`@elevasis/ui/features/<fe
 
 The published barrel (`packages/ui/src/provider/published.ts`) remains headless -- no Mantine-dependent visual pieces leak into the external contract.
 
+## Knowledge Browser Customization
+
+The Knowledge Browser follows the same pattern described in this document. The three tiers map directly:
+
+- **Tier 1** -- import `knowledgeManifest` from `@elevasis/ui/features/knowledge` and pass it to `ElevasisFeaturesProvider`. No further code required.
+- **Tier 2** -- spread the manifest, override `sidebar` to a component that composes `KnowledgeSidebar` + `KnowledgeSidebarMiddle items={customItems}`. Same shape as the CRM example above.
+- **Tier 3** -- skip the manifest, own the route, call `byFeature` / `byKind` / `byOwner` from `@elevasis/core/knowledge` directly.
+
+One additional wiring step is required for Knowledge Browser that does not apply to CRM or Lead Gen: add `knowledgePlugin()` from `@elevasis/ui/vite-plugin-knowledge` to `vite.config.ts`. The plugin runs build-time MDX codegen so rendered body components are available at runtime.
+
+See [recipes/customize-knowledge-browser.md](../recipes/customize-knowledge-browser.md) for the full walkthrough including code examples, the CSS import requirement, and the full exports reference.
+
+Phase 1.5 adds two further extension surfaces documented in the same recipe file under the "Phase 1.5" section:
+
+- **Extending the SegmentedControl** -- supply a `segments` prop to `KnowledgeSidebarMiddle` to add custom mount-axis tabs beyond the default five (By Feature, By Kind, By Owner, Governs, Governed By).
+- **Replacing `DescribeNodeView`** -- override the `/knowledge/:nodeId` route component to swap the entire main-pane dispatcher, or use `createDescribeNodeDispatcher` from `@elevasis/ui/knowledge` to override only specific node-kind views while keeping the platform defaults for the rest.
+
 ## What Not to Do
 
 - **Don't fork sidebar files into your app tree.** You own upstream drift forever.

package/reference/claude-config/skills/configure/SKILL.md

@@ -1,98 +0,0 @@
----
-name: configure
-description: "Recurring organization model editor — layered QA flow across identity, customers, offerings, roles, goals, and techStack. Idempotent, confirm-before-overwrite. Codifies changes to core/config/organization-model.ts with runtime validation gate."
-argument-hint: "[identity|customers|offerings|roles|goals|techStack|features|labels]"
-context: fork
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
----
-
-# Configure
-
-Recurring, safe-to-re-run org model editor for external projects. Reads the organization model as the single source of truth and guides the user through structured updates — either across all domains in a layered flow, or targeted at a single domain by argument.
-
-**Usage:**
-
-- `/configure` -- Layered flow: walks identity → customers → offerings → roles → goals → techStack in sequence
-- `/configure identity` -- Target only the identity domain
-- `/configure customers` -- Target only the customers domain
-- `/configure offerings` -- Target only the offerings domain
-- `/configure roles` -- Target only the roles domain
-- `/configure goals` -- Target only the goals domain
-- `/configure techStack` -- Target only the techStack domain (resource mapping extensions)
-- `/configure features` -- Enable, disable, or add features; Level A (defaults) or Level B (new extension TS files)
-- `/configure labels` -- Edit inline display labels on enum entries (statuses, stages, categories)
-
-**Distinction from `/setup`:** `/setup` is for first-time bootstrap (placeholder replacement, dependency install, build verification). `/configure` is for recurring org-model updates. After first run, `/setup` delegates here.
-
----
-
-## Goal
-
-Keep `core/config/organization-model.ts` accurate and validated. Every edit proposed by this skill ends with `resolveOrganizationModel()` + `OrganizationModelSchema.parse()` confirming the merged result is valid — and a full TypeScript type-check via `pnpm -C operations check-types` to catch static errors. If validation fails, the change is rolled back.
-
----
-
-## Pre-Flight: Read the Current Model
-
-Before any domain flow, read the current organization model adapter:
-
-```
-Read("core/config/organization-model.ts")
-```
-
-This is the single source of truth. All proposals must start from what is currently in this file, not from stale context.
-
----
-
-## Mode Detection
-
-- **No argument:** run the layered flow (all domains, one at a time in the order below).
-- **Argument matches a domain name** (`identity`, `customers`, `offerings`, `roles`, `goals`, `techStack`): run only that domain's operation.
-- **Argument is `features`:** run the features operation.
-- **Argument is `labels`:** run the labels operation.
-- **Argument is unrecognized:** ask the user which domain they meant.
-
----
-
-## Layered Flow (Default)
-
-When run without an argument, execute operations in this order. After each domain, ask "Ready to move on to [next domain]?" and pause for confirmation. The user can stop after any domain — partial updates are valid.
-
-1. `identity` -- EXECUTE `.claude/skills/configure/operations/identity.md`
-2. `customers` -- EXECUTE `.claude/skills/configure/operations/customers.md`
-3. `offerings` -- EXECUTE `.claude/skills/configure/operations/offerings.md`
-4. `roles` -- EXECUTE `.claude/skills/configure/operations/roles.md`
-5. `goals` -- EXECUTE `.claude/skills/configure/operations/goals.md`
-6. `techStack` -- EXECUTE `.claude/skills/configure/operations/techStack.md`
-
----
-
-## Operations
-
-| Operation        | File                                                    | Description                                                                                                      |
-| ---------------- | ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
-| `identity`       | `.claude/skills/configure/operations/identity.md`       | Legal identity, mission, vision, industry, geography, timezone, business hours                                   |
-| `customers`      | `.claude/skills/configure/operations/customers.md`      | Customer segments with jobs-to-be-done, pains, gains, firmographics, value props                                 |
-| `offerings`      | `.claude/skills/configure/operations/offerings.md`      | Products and services with pricing model, price, currency, and segment/feature refs                              |
-| `roles`          | `.claude/skills/configure/operations/roles.md`          | Role chart with responsibilities, reporting lines, and role holders                                              |
-| `goals`          | `.claude/skills/configure/operations/goals.md`          | Organizational goals with period and measurable outcomes                                                         |
-| `techStack`      | `.claude/skills/configure/operations/techStack.md`      | External integration registry — platform, purpose, credential status, system-of-record flag                      |
-| `features`       | `.claude/skills/configure/operations/features.md`       | Enable/disable features or add new ones (Level A config edit vs Level B extension file)                          |
-| `labels`         | `.claude/skills/configure/operations/labels.md`         | Edit inline display labels on enum entries (statuses, stages, categories)                                        |
-| `codify-level-a` | `.claude/skills/configure/operations/codify-level-a.md` | Codify pipeline for config-only edits (Level A): propose, confirm, write, validate, rollback                     |
-| `codify-level-b` | `.claude/skills/configure/operations/codify-level-b.md` | Codify pipeline for new extension TS files (Level B): scaffold file, propose, confirm, write, validate, rollback |
-
----
-
-## Validation Gate (MANDATORY)
-
-Every codify operation (Level A or B) must end with this validation sequence before reporting success:
-
-1. **TypeScript type-check:** `pnpm -C operations check-types` (catches static errors in the generated extension files)
-2. **Runtime schema parse:** confirm that the adapter calls `resolveOrganizationModel()` and `OrganizationModelSchema.parse()` is satisfied (Zod cross-refs, enum values, required fields)
-
-If either fails: roll back the file to its pre-edit state and report the error to the user. See `codify-level-a.md` and `codify-level-b.md` for the full rollback procedure.
-
----
-
-**Last Updated:** 2026-04-20

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

@@ -1,150 +0,0 @@
-# Configure: customers
-
-Guides the user through reviewing and updating the `customers` domain of the organization model.
-
-The `customers` domain describes who the organization serves — distinct buyer archetypes modeled
-after the Value Proposition Canvas (BMC / VPC). Each segment captures jobs-to-be-done, pains,
-gains, firmographics, and a value proposition. Agents use these segments for targeting, outreach
-context, and personalization.
-
-## Schema reference
-
-Source: `packages/core/src/organization-model/domains/customers.ts`
-
-```typescript
-CustomersDomainSchema = z.object({
-  segments: z.array(CustomerSegmentSchema).default([])
-})
-
-CustomerSegmentSchema = z.object({
-  id:           z.string().trim().min(1).max(100),             // stable ID, e.g. "segment-smb-agencies"
-  name:         z.string().trim().max(200).default(''),        // display name
-  description:  z.string().trim().max(2000).default(''),       // who this segment is
-  jobsToBeDone: z.string().trim().max(2000).default(''),       // the goal they hire you to accomplish
-  pains:        z.array(z.string().trim().max(500)).default([]),
-  gains:        z.array(z.string().trim().max(500)).default([]),
-  firmographics: FirmographicsSchema.default({}),              // industry, companySize, region
-  valueProp:    z.string().trim().max(2000).default('')         // why your offering fits this segment
-})
-
-FirmographicsSchema = z.object({
-  industry:    z.string().trim().max(200).optional(),  // e.g. "Marketing Agency"
-  companySize: z.string().trim().max(100).optional(),  // e.g. "11–50"
-  region:      z.string().trim().max(200).optional()   // e.g. "North America"
-})
-```
-
-Where this lands in the adapter: `foundations/config/organization-model.ts` under the `customers`
-key of `defineOrganizationModel({...})`.
-
----
-
-## Process
-
-### Step 1: Read current state
-
-Read `foundations/config/organization-model.ts` and extract the current `customers.segments` array.
-Present it as a summary table:
-
-```
-Current customer segments (N):
-  1. {name} ({id}) — {description truncated to 80 chars}
-  2. ...
-  (none defined yet)
-```
-
-### Step 2: Establish intent
-
-Ask whether the user wants to:
-
-- **Add** a new segment
-- **Edit** an existing segment (by name or number)
-- **Remove** a segment
-- **Review all** segments in detail
-
-Handle one segment at a time unless the user explicitly asks to work on multiple at once.
-
-### Step 3: Gather segment details
-
-For each segment being added or edited, work through the fields conversationally:
-
-**Core identity:**
-
-- "What's a good name for this segment? (e.g. 'SMB Marketing Agencies', 'Enterprise SaaS Companies')"
-- "Give it a stable ID I'll use as a key — lowercase with hyphens, like `segment-smb-agencies`."
-- "How would you describe who this segment is in one or two sentences?"
-
-**Jobs-to-be-done:**
-
-- "What is the main job this segment is trying to get done? The goal they hire you to accomplish —
-  describe it in their terms, not yours."
-
-**Pains and gains:**
-
-- "What are two or three frustrations or obstacles this segment runs into when trying to get that
-  job done?"
-- "What outcomes or benefits are they hoping for — beyond just fixing the pain?"
-
-**Firmographics (optional):**
-
-- "Do you want to capture firmographic filters for targeting? Things like industry vertical,
-  typical company size, and geographic region."
-
-**Value proposition:**
-
-- "How does your organization's offering uniquely address this segment's needs? One or two sentences."
-
-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 segment(s):
-
-```
-Proposed customers change:
-
-ADD segment "SMB Marketing Agencies" (segment-smb-agencies):
-  name:         "SMB Marketing Agencies"
-  description:  "Owner-operated agencies with 1–15 employees running campaign delivery for SMB clients."
-  jobsToBeDone: "Deliver consistent client results without adding headcount."
-  pains:        ["Manual campaign QA", "Client reporting takes hours", "Hard to scale without hiring"]
-  gains:        ["More client capacity without more staff", "Predictable delivery timelines"]
-  firmographics: { industry: "Marketing Agency", companySize: "1–15", region: "North America" }
-  valueProp:    "Automates the repetitive delivery and reporting work so agencies can take on more clients."
-
-Apply? (yes/no)
-```
-
-For edits to existing segments, show only the fields that changed.
-
-### Step 5: Codify
-
-Execute `.claude/skills/configure/operations/codify-level-a.md` with the proposed `customers`
-block. Only the `segments` array is written — no other keys in the adapter are touched.
-
-When adding a segment, append to the array. When editing, replace the matching entry by `id`.
-When removing, filter it out.
-
-Cross-reference note: if `offerings.products[].targetSegmentIds` references a segment being
-removed, surface a warning and ask the user whether to clean up those references before writing.
-
-### Step 6: Report
-
-After successful validation:
-
-```
-Customers updated.
-  Segments: {total count} ({N added / N edited / N removed})
-  foundations/config/organization-model.ts — customers.segments updated
-  Type-check: PASS
-  Schema validation: PASS
-```
-
-If validation failed and rollback occurred:
-
-```
-Customers 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/features.md

@@ -1,162 +0,0 @@
-# Configure: features
-
-Guides the user through enabling, disabling, or adding features in the organization model.
-
-Features are the top-level capability switches in the platform. Enabling a feature makes its nav
-items and routes visible; disabling hides them without removing the feature from the model. Adding
-a new feature may require only a config edit (Level A) or a new extension TypeScript file
-(Level B), depending on whether the feature already exists in the platform defaults.
-
-This operation handles both toggling existing features and introducing custom features.
-
-## Background: Level A vs Level B
-
-- **Level A (config-only edit):** The feature exists in the platform defaults (see
-  `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` for the default feature
-  set). The adapter in `foundations/config/organization-model.ts` overrides its `enabled` flag or
-  adjusts metadata. No new TypeScript files needed.
-
-- **Level B (new extension file):** The feature does not exist in platform defaults. A new
-  feature ID and manifest need to be declared. This requires a new TypeScript file under
-  `foundations/config/extensions/` plus wiring it into the adapter. Level B is only offered when
-  the user explicitly asks to create a custom feature.
-
-## Schema reference
-
-Source: `node_modules/@elevasis/core/organization-model` (published types) or
-`node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` (auto-generated shapes)
-
-```typescript
-FeatureSchema = z.object({
-  id:           ModelIdSchema,               // lowercase, e.g. "crm", "lead-gen", "seo"
-  label:        LabelSchema,                 // display label
-  description:  DescriptionSchema.optional(),
-  enabled:      z.boolean().default(true),
-  color:        ColorTokenSchema.optional(),
-  icon:         IconNameSchema.optional(),
-  entityIds:    ReferenceIdsSchema,
-  surfaceIds:   ReferenceIdsSchema,
-  resourceIds:  ReferenceIdsSchema,
-  capabilityIds: ReferenceIdsSchema
-})
-```
-
-Platform default feature IDs (from `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md`):
-`crm`, `lead-gen`, `projects`, `operations`, `monitoring`, `settings`, `seo`
-
-Where this lands in the adapter: `foundations/config/organization-model.ts` under the `features`
-array of `defineOrganizationModel({...})`. The `features` array replaces entirely (no element
-merge), so the adapter must redeclare all features it wants to override.
-
----
-
-## Process
-
-### Step 1: Read current state
-
-Read `foundations/config/organization-model.ts` and extract the current `features` array from the
-adapter. Also read `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` to see
-what the platform defaults look like.
-
-Present a combined view:
-
-```
-Platform features (current state):
-  crm          [enabled]  -- CRM (adapter override or platform default)
-  lead-gen     [enabled]  -- Lead Generation
-  projects     [enabled]  -- Projects
-  operations   [enabled]  -- Operations
-  monitoring   [enabled]  -- Monitoring
-  settings     [enabled]  -- Settings
-  seo          [disabled] -- SEO (disabled in platform default)
-
-Custom features (adapter-only):
-  (none)
-```
-
-### Step 2: Establish intent
-
-Ask what the user wants to do:
-
-- **Enable** a disabled feature
-- **Disable** an enabled feature
-- **Add a custom feature** (Level B -- will ask for explicit confirmation)
-- **Edit metadata** on an existing feature (label, color, icon)
-
-For enable/disable: this is Level A. For custom add: escalate to Level B branch.
-
-### Step 3a: Level A -- Enable or disable
-
-For an enable or disable request:
-
-- Identify the target feature by name or ID.
-- Read the current `enabled` value.
-- Confirm the proposed change:
-
-```
-Proposed feature change:
-
-DISABLE feature "SEO" (seo):
-  enabled: true -> false
-
-This will hide the SEO nav item and gate its routes.
-Apply? (yes/no)
-```
-
-After confirmation, execute `.claude/skills/configure/operations/codify-level-a.md`.
-
-The write either adds or updates the matching entry in the `features` array of the adapter.
-Because the array replaces entirely, verify that the adapter redeclares all features that should
-remain in their current state.
-
-### Step 3b: Level B -- Add a custom feature
-
-Only proceed here when the user explicitly asks to add a new custom feature that does not exist in
-the platform defaults.
-
-State clearly: "Adding a custom feature creates a new TypeScript extension file in
-`foundations/config/extensions/`. This is a bigger change than a config toggle. Want to proceed?"
-
-If yes, gather:
-
-- "What should the feature ID be? Lowercase, hyphens only (e.g. `client-portal`)."
-- "What's the display label? (e.g. 'Client Portal')"
-- "Optional: a short description of what this feature represents."
-- "Which surfaces, entities, or resources does this feature relate to? (IDs -- leave blank to add
-  later)"
-
-Then execute `.claude/skills/configure/operations/codify-level-b.md` to scaffold the extension
-file and wire it into the adapter.
-
-### Step 4: Validation
-
-All changes -- Level A and Level B -- must pass:
-
-1. `pnpm -C operations check-types`
-2. `resolveOrganizationModel()` and `OrganizationModelSchema.parse()` succeed on the merged result
-
-On failure, roll back and report. See `codify-level-a.md` and `codify-level-b.md` for the
-rollback procedure.
-
-### Step 5: Report
-
-After successful validation:
-
-```
-Features updated.
-  {feature label} ({id}): {old enabled} -> {new enabled}   (Level A)
-  Custom feature "{label}" ({id}): added                   (Level B, if applicable)
-  foundations/config/organization-model.ts -- features array updated
-  foundations/config/extensions/{id}.ts -- created          (Level B only)
-  Type-check: PASS
-  Schema validation: PASS
-```
-
-If validation failed and rollback occurred:
-
-```
-Features update rolled back.
-  Reason: {error message}
-  All files restored to previous state.
-  No changes persisted.
-```

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

@@ -1,147 +0,0 @@
-# Configure: goals
-
-Guides the user through reviewing and updating the `goals` domain of the organization model.
-
-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 reference
-
-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)
-})
-```
-
-Cross-reference constraint: `periodEnd` must be strictly after `periodStart`. Enforced at parse
-time by `OrganizationModelSchema.superRefine()`.
-
-The field name in the schema is `objectives` (not `goals`) and the measurable-outcome array is
-`keyResults` (not `outcomes`) — these are internal field names, not user-facing vocabulary.
-
-Where this lands in the adapter: `foundations/config/organization-model.ts` under the `goals`
-key of `defineOrganizationModel({...})`.
-
----
-
-## Process
-
-### Step 1: Read current state
-
-Read `foundations/config/organization-model.ts` and extract the current `goals.objectives` array.
-Present as a plain-language summary:
-
-```
-Current goals (N):
-  1. "{description truncated to 80 chars}" ({id})
-     Period: {periodStart} → {periodEnd}
-     Measurable outcomes: {count}
-  (no goals defined yet)
-```
-
-### Step 2: Establish intent
-
-Ask whether the user wants to:
-
-- **Add** a new goal
-- **Edit** an existing goal (by description or number)
-- **Remove** a goal
-- **Update progress** on a measurable outcome (update `currentValue`)
-
-### Step 3: Gather goal details
-
-For each goal being added or edited:
-
-**Core goal:**
-
-- "What is the organization working toward? Describe the goal in plain language — one or two sentences."
-- "Give it a stable ID — lowercase with hyphens, e.g. `goal-grow-arr-q1-2026`."
-- "What period does this goal cover? (Start date and end date — e.g. 2026-01-01 to 2026-03-31)"
-
-Validate that the end date is strictly after the start date before proceeding.
-
-**Measurable outcomes (optional but recommended):**
-
-- "Do you want to add any measurable outcomes under this goal? These help track whether you're
-  on track."
-- For each outcome: "What are you measuring? (e.g. monthly revenue, NPS score, trial-to-paid
-  conversion rate)"
-- "What's the target value? (Optional — leave blank if the outcome is directional.)"
-- "What's the current value?"
-- "Give this outcome an ID — e.g. `kr-revenue-q1`."
-
-Capture as many outcomes as the user wants. One at a time is fine.
-
-### Step 4: Confirm before writing
-
-Present a diff:
-
-```
-Proposed goals change:
-
-ADD goal "Reach $50K MRR by end of Q1 2026" (goal-arr-q1-2026):
-  period:  2026-01-01 → 2026-03-31
-  outcomes:
-    kr-mrr-q1: "Grow monthly recurring revenue"
-      metric:  "monthly recurring revenue (MRR)"
-      current: 32000
-      target:  50000
-    kr-churn-q1: "Reduce churn rate"
-      metric:  "monthly churn rate (%)"
-      current: 4.2
-      target:  2.5
-
-Apply? (yes/no)
-```
-
-### Step 5: Codify
-
-Execute `.claude/skills/configure/operations/codify-level-a.md` with the proposed `goals` block.
-Only the `objectives` array is written — no other keys in the adapter are touched.
-
-When updating progress only (updating `currentValue` on an existing outcome), make a targeted
-edit rather than rewriting the entire goals block.
-
-### Step 6: Report
-
-After successful validation:
-
-```
-Goals updated.
-  Goals: {total count} ({N added / N edited / N removed})
-  foundations/config/organization-model.ts — goals.objectives updated
-  Type-check: PASS
-  Schema validation: PASS
-```
-
-If validation failed and rollback occurred:
-
-```
-Goals update rolled back.
-  Reason: {error message}
-  foundations/config/organization-model.ts — restored to previous state
-  No changes persisted.
-```