@elevasis/sdk 1.20.2 → 1.21.0

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

@@ -48,11 +48,11 @@ Review the current conversation to identify:
    - `core/config/organization-model.ts` -> Foundations layer, Organization Model
    - `core/types/index.ts` -> Foundations layer, Workflow Contracts
    - `ui/src/routes/__root.tsx` -> UI Shell Runtime composition
-   - `ui/src/features/**/manifest.ts` or any file defining a `FeatureModule` -> Features layer
+   - `ui/src/features/**/manifest.ts` or any file defining a `SystemModule` -> Systems layer
    - `operations/src/index.ts` or `operations/elevasis.config.ts` -> core/Deployment (DeploymentSpec)
    - Any file inside `ui/src/features/<feature>/` combined with manifest, nav, or sidebar changes -> Features + Toolkit layers
 
-   Record which OS layers were touched: `foundations`, `features`, `shell-runtime`, `toolkit`, `deployment`. If none matched, OS awareness stays dormant for the rest of this run.
+   Record which OS layers were touched: `foundations`, `systems`, `shell-runtime`, `toolkit`, `deployment`. If none matched, OS awareness stays dormant for the rest of this run.
 
 ### Step 3: Update Knowledge Docs
 

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

@@ -272,4 +272,4 @@ Running `/setup` more than once is safe:
 4. Installs dependencies and verifies the build
 5. Hands off to `/knowledge` for full org-model configuration
 
-`/knowledge` owns all other structural org-model editing (identity fields beyond clientBrief, customers, offerings, roles, goals, techStack, features, labels). It is idempotent, confirm-before-overwrite, and includes a runtime validation gate. Re-run `/knowledge` any time organizational reality changes — no need to re-run `/setup`.
+`/knowledge` owns all other structural org-model editing (identity fields beyond clientBrief, customers, offerings, roles, goals, techStack, systems, actions, labels, and legacy feature compatibility). It is idempotent, confirm-before-overwrite, and includes a runtime validation gate. Re-run `/knowledge` any time organizational reality changes — no need to re-run `/setup`.

package/reference/claude-config/skills/tutorial/technical.md

@@ -31,7 +31,7 @@ SECTION B -- Build your first thing                     (5 items)
 SECTION C -- The Organization Model                     (3 items)
   9  /knowledge ceremony -- identity, customers,         [ ]
      offerings via the layered flow
- 10  Features and labels                                 [ ]
+ 10  Systems, actions, and labels                        [ ]
  11  Entity extensions -- BaseProject, BaseDeal          [ ]
 
 SECTION D -- Modules (load on demand)                   (6 items)
@@ -103,7 +103,7 @@ every session and uses it to route task classes, resolve boundaries, and choose
 **SDK reference scaffold.** After `pnpm install`, the entry point
 `node_modules/@elevasis/sdk/reference/scaffold/index.mdx` gives access to canonical recipes, UI
 patterns, the gating model, contracts, and a glossary. Whenever the user wants the authoritative
-answer on a scaffold surface (how to add a feature, extend an entity, wire a workflow), that
+answer on a scaffold surface (how to add a System or UI feature, extend an entity, wire a workflow), that
 index is the starting point.
 
 **Verification:** Ask the user: "Where does the agent look first when entering a session?" (Answer:
@@ -137,7 +137,7 @@ If the user skips, mark complete and move on.
 Otherwise, read the Slash Commands table in `CLAUDE.md` aloud. Then explain the skill system:
 
 **Invocation pattern.** Every slash command is a skill. Type `/<name>` (optionally with args,
-e.g., `/knowledge features`). The agent reads `.claude/skills/<name>/SKILL.md` and follows its
+e.g., `/knowledge systems`). The agent reads `.claude/skills/<name>/SKILL.md` and follows its
 instructions. Skills may be context-forked (they run in a subagent) or inline. The frontmatter
 `context: fork` means a subagent handles it.
 
@@ -219,7 +219,7 @@ never sees the classification.
 - **Navigate** -- "Let's focus on the onboarding flow." Agent updates scope, narrates the shift.
 - **Codify** -- "We track deals by Shopify platform." Agent detects new organizational reality
   and delegates to `/knowledge`.
-- **Toggle** -- "Turn on the lead-gen feature." Agent delegates to `/knowledge features`.
+- **Toggle** -- "Turn on the lead-gen system." Agent delegates to `/knowledge systems`.
 
 **Important behavioral rules.** Codify and Toggle delegate immediately to `/knowledge` -- the
 vibe layer detects intent but does NOT run the ceremony itself. The ceremony (snapshot, propose,
@@ -235,7 +235,7 @@ working inside the monorepo (`apps/`, `packages/`, etc.), vibe does not fire.
 the rule file.
 
 **Verification:** Ask "What happens when you type 'turn on SEO'?" Answer: Vibe classifies it as
-Toggle intent and delegates to `/knowledge features` without running the ceremony itself.
+Toggle intent and delegates to `/knowledge systems` without running the ceremony itself.
 
 **Completion signal:** Mark `[ ] 3 The vibe layer` as `[x] YYYY-MM-DD` in
 `.claude/memory/tutorial-progress.md`.
@@ -660,7 +660,7 @@ Tell the user:
 **Why direct edits are blocked.** Read `core/config/organization-model.ts`. The file calls
 `resolveOrganizationModel()` which runs Zod cross-reference validation: every customer segment
 referenced in offerings must exist in `customers`, every resource mapping must reference a valid
-feature ID, and so on. A direct edit that passes TypeScript can still fail the cross-ref check,
+system ID, and so on. A direct edit that passes TypeScript can still fail the cross-ref check,
 leaving the project in a broken state. The `/knowledge` ceremony runs both checks and rolls back
 on failure.
 
@@ -699,33 +699,31 @@ rollback step exists.
 
 ---
 
-### Item 10: Features and labels
+### Item 10: Systems, actions, and labels
 
-**Goal:** The user can enable/disable a feature via `/knowledge features` and rename a display
-label via `/knowledge labels`.
+**Goal:** The user can enable/disable a System via `/knowledge systems`, understand Actions as
+invokable operations, and rename a display label via `/knowledge labels`.
 
 **Estimated time:** 15 min
 
-**Files referenced:** `.claude/skills/knowledge/operations/features.md`,
+**Files referenced:** `.claude/skills/knowledge/operations/features.md` (legacy compatibility),
 `.claude/skills/knowledge/operations/labels.md`, `core/config/organization-model.ts`
 
 **Flow:**
 
-**Features.** The org model has a `features` domain that controls which platform features are
-active for this project. Toggle by running:
+**Systems.** The org model uses Systems for availability, routing, ownership, navigation
+grouping, and knowledge mounts. Toggle availability by running:
 
 ```
-/knowledge features
+/knowledge systems
 ```
 
 The ceremony proposes the change (e.g., `seo: false -> true`), asks for confirmation, writes,
-and validates. The TypeScript constant names are stable (`CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`,
-`PROJECTS_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, `MONITORING_FEATURE_ID`, `SETTINGS_FEATURE_ID`,
-`SEO_FEATURE_ID`) -- use these constants instead of magic strings when writing workflow code that
-references feature IDs.
+and validates. Older scaffold recipes and UI packages may still say "feature"; translate that to
+System when discussing Organization OS availability or routing.
 
-Feature toggles affect the UI shell: a disabled feature removes its nav entry and routes from
-the shell. The org model is the single gate for all feature visibility.
+System toggles affect the UI shell: a disabled System removes its nav entry and routes from
+the shell. Actions are the invokable operations owned or exposed by a System.
 
 **Labels.** The `labels` domain controls display strings on enum entries -- CRM pipeline stages,
 lead-gen lifecycle statuses, project statuses, and so on. Rename by running:
@@ -740,11 +738,11 @@ should not change -- it maps to semantic behavior like `blocked`, `in_progress`,
 
 Show an example: renaming the `discovery` CRM stage to `qualification`.
 
-**Verification:** Ask: "What is the difference between a feature toggle and a label rename?"
+**Verification:** Ask: "What is the difference between a System toggle and a label rename?"
 (Toggle controls visibility/routing. Label rename changes display text on an existing enum
 entry without changing its semantic ID or behavior.)
 
-**Completion signal:** Mark `[ ] 10 Features and labels` as `[x] YYYY-MM-DD` in
+**Completion signal:** Mark `[ ] 10 Systems, actions, and labels` as `[x] YYYY-MM-DD` in
 `.claude/memory/tutorial-progress.md`.
 
 ---
@@ -804,9 +802,8 @@ shape. This ensures the workflow contract stays in sync with the entity definiti
 
 **Domain rename note.** In `core/config/organization-model.ts`, the domain config fields were
 renamed in the 2026-04-20 expansion: `crm` -> `sales`, `leadGen` -> `prospecting`,
-`delivery` -> `projects`. The feature ID constants (`CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`,
-`PROJECTS_FEATURE_ID`) are unchanged -- use the constants, not the field names, when referencing
-features in code.
+`delivery` -> `projects`. Older feature ID constants may still appear in UI package code and
+scaffold recipes; treat them as implementation constants, not live Organization OS primitives.
 
 **Verification:** The user can explain when to use Pattern 1 vs Pattern 2 and name two base
 entity types they could extend.
@@ -1185,7 +1182,7 @@ auto-load). Key files:
 - `agent-start-here.md` -- always-loaded canonical first-read; task-class routing and boundary
   resolution
 - `vibe.md` -- always-loaded ambient intent classifier
-- `organization-os.md` -- loaded when touching org model, feature access, or entity work
+- `organization-os.md` -- loaded when touching org model, System access, Action routing, or entity work
 - `deployment.md` -- loaded when deploying resources
 - `error-handling.md` -- loaded when authoring handlers with error concerns
 - `execution.md` -- loaded when reasoning about the runtime model
@@ -1294,7 +1291,7 @@ following closing script:
 >   LLM integration, error handling, and composition. Start with the domain most relevant to your
 >   project and use `/project create` to track the work.
 > - **SDK reference scaffold.** `node_modules/@elevasis/sdk/reference/scaffold/index.mdx` is the
->   canonical recipe index for anything you want to build: adding a feature, extending lead-gen,
+>   canonical recipe index for anything you want to build: adding a System or UI feature, extending lead-gen,
 >   customizing CRM actions, authoring agents. Read it whenever you are starting something new.
 > - **Explore the codebase.** `/explore` is your tool for open-ended questions about how things
 >   are wired. Use it before making changes in unfamiliar parts of the project.

package/reference/claude-config/skills/tutorial/vibe-coder.md

@@ -197,7 +197,7 @@ Say:
 Say:
 
 > "If you want me to explain what something is or what it does, tell me. 'Tell me about
-> the lead follow-up automation.' 'What does the CRM feature do?' 'Where am I in this
+> the lead follow-up automation.' 'What does the CRM system do?' 'Where am I in this
 > project?' -- those all work. I'll describe it in plain language, not technical terms."
 
 ---
@@ -251,8 +251,8 @@ end of the lesson as a follow-up.
 Say:
 
 > "Some things in your setup can be switched on or off. If you don't use a particular
-> feature, you can say 'Turn off the SEO tools' and I'll take care of it. Or 'Enable
-> the lead-gen feature.' You'll see what's changing and confirm before it's done."
+> system, you can say 'Turn off the SEO tools' and I'll take care of it. Or 'Enable
+> the lead-gen system.' You'll see what's changing and confirm before it's done."
 
 ---
 
@@ -508,10 +508,10 @@ Say:
 
 **Step 1 -- Orient to the main sections.**
 
-[Hidden action]: Read `core/config/organization-model.ts` to identify which features
+[Hidden action]: Read `core/config/organization-model.ts` to identify which Systems
 are enabled, so you can tailor the tour to what's actually visible.
 
-Describe the dashboard in plain terms, based on the features that are on:
+Describe the dashboard in plain terms, based on the Systems that are on:
 
 > "When you open your dashboard, you'll see a few main areas. Your automations live
 > in one section -- that's where you can see which ones are active, when they last
@@ -553,8 +553,8 @@ Describe the dashboard in plain terms, based on the features that are on:
 
 ### Hidden actions summary
 
-- Read org model features section to determine which dashboard sections are visible.
-- Tailor the tour to only mention visible/enabled features.
+- Read org model Systems section to determine which dashboard sections are visible.
+- Tailor the tour to only mention visible/enabled Systems.
 
 ### Completion signal
 
@@ -712,8 +712,8 @@ ceremony silently. Confirm with the user before writing.
 
 **Step 5 -- Teach the toggle pattern.**
 
-> "And if you want to turn a whole feature on or off -- say you're not using the
-> lead-gen tools right now -- just tell me: 'Turn off the lead-gen feature for now.'
+> "And if you want to turn a whole system on or off -- say you're not using the
+> lead-gen tools right now -- just tell me: 'Turn off the lead-gen system for now.'
 > Done. Turn it back on anytime the same way."
 
 **Step 6 -- Reassure about iteration.**

package/reference/claude-config/sync-notes/2026-05-12-sdk-ready-release-train.md

@@ -0,0 +1,30 @@
+# SDK Ready Release Train
+
+## Why this note exists
+
+This release train carries SDK CLI, Organization OS/Knowledge scaffold, shared UI, and external template guidance changes from the monorepo into template-derived projects. Downstream projects need an operative sync note because the train includes `external/_template/.claude/**`, package baseline cascades, and generated/reference surfaces that are not handled by ordinary git merge alone.
+
+## Applies to
+
+- Template-derived external projects, including `external/ZentaraHQ` when its local worktree is ready for reconciliation.
+- Managed Claude skill/rule/registry surfaces under `.claude/**`.
+- Package dependency baselines for `@elevasis/core`, `@elevasis/ui`, and `@elevasis/sdk` after the publish stages complete.
+
+## Required actions
+
+- Run the prepared `/external sync --all` scope from `_external-sync-prep.json` after `/sdk ship` completes publish and deploy stages.
+- Preserve project-owned files such as tenant `CLAUDE.md`, operations runtime code, and knowledge nodes unless the sync manifest marks a path as managed.
+- Reconcile dirty tenant worktrees before applying managed `.claude` skill/rule writes.
+
+## Verification
+
+- Run the external sync planner/verify flow for each target project before applying writes.
+- Confirm queue, schedule, note, Knowledge, and Organization OS guidance renders in the downstream `.claude` command/skill surfaces.
+- Regenerate downstream knowledge/scaffold artifacts where the sync report requires generated freshness.
+
+## Not handled by /git-sync
+
+- Publishing `@elevasis/core`, `@elevasis/ui`, or `@elevasis/sdk`.
+- Deploying the SDK resources bundle.
+- Tenant-specific conflict resolution in dirty external project repositories.
+- Manual review of project-owned `CLAUDE.md`, operations source, and knowledge content.

package/reference/cli.mdx

@@ -625,6 +625,146 @@ For exact required flags and accepted enum values, see the command source under
 
 ---
 
+## elevasis-sdk note:\*
+
+`elevasis-sdk note:*` is the agent-facing surface for pushing and reading personal user notes. Workflows and agents use it to surface information -- such as "deal X stalled" or "review run completed" -- directly into a user's Notes panel in the Command Center, without sending an email or notification.
+
+Notes are personal to the target user and scoped to the calling organization. The external API surface exposes `GET + POST` only; `note:update` and `note:delete` are not yet available via SDK CLI. Users edit and delete notes through the right-panel view in the Command Center.
+
+### note:create
+
+Create a personal note for a user.
+
+**Synopsis:**
+
+```
+elevasis-sdk note:create --content <text>
+                         [--user <email>]
+                         [--title <text>]
+                         [--priority low|normal|high|urgent]
+                         [--pinned]
+                         [--source <id>]
+                         [--api-url <url>] [--pretty]
+```
+
+**Flags:**
+
+| Flag                      | Description                                                                               |
+| ------------------------- | ----------------------------------------------------------------------------------------- |
+| `--content <text>`      | Required. The note body text                                                              |
+| `--user <email>`        | Target user email. Defaults to the API key owner when omitted                             |
+| `--title <text>`        | Optional note title                                                                       |
+| `--priority <priority>` | Priority level: `low`, `normal` (default), `high`, or `urgent`                            |
+| `--pinned`                | Pin the note to the top of the panel                                                      |
+| `--source <id>`         | Source identifier -- set this to the workflow or agent ID when calling from agent runtime |
+| `--api-url <url>`       | Override the API base URL                                                                 |
+| `--pretty`                | Human-readable terminal output instead of raw JSON                                        |
+
+**Behavior:**
+
+- Posts to `POST /api/external/user-notes`
+- When `--user` is omitted the note is created for the identity bound to the API key (the caller)
+- When `--user` is provided the platform resolves the email to a Supabase user UUID and verifies the resolved user is an active member of the calling organization before writing
+- The `--source` flag is recorded as the `source` column in `user_notes`; agent runtimes should pass their resource ID here so users can see which workflow created the note
+- Priority `normal` produces no badge in the UI; `high` renders orange, `urgent` renders red, `low` renders dimmed gray
+
+**Examples:**
+
+```bash
+# Create a note for the API key owner
+elevasis-sdk note:create --content "Deal X has stalled -- follow up needed"
+
+# Create a high-priority pinned note for a specific user
+elevasis-sdk note:create \
+  --content "Review run completed for batch_abc123" \
+  --user ops@acme.com \
+  --priority high \
+  --pinned \
+  --source "report-review-workflow" \
+  --pretty
+```
+
+```
+  Note created
+    ID:       note_550e8400-...
+    Priority: high
+```
+
+---
+
+### note:list
+
+List notes for a user.
+
+**Synopsis:**
+
+```
+elevasis-sdk note:list --user <email>
+                       [--priority <p>] [--pinned]
+                       [--limit <n>] [--offset <n>]
+                       [--api-url <url>] [--pretty]
+```
+
+**Flags:**
+
+| Flag                      | Description                                              |
+| ------------------------- | -------------------------------------------------------- |
+| `--user <email>`        | Required. The user whose notes to retrieve               |
+| `--priority <priority>` | Filter by priority: `low`, `normal`, `high`, or `urgent` |
+| `--pinned`                | Return only pinned notes                                 |
+| `--limit <n>`           | Maximum number of results to return                      |
+| `--offset <n>`          | Pagination offset                                        |
+| `--api-url <url>`       | Override the API base URL                                |
+| `--pretty`                | Human-readable terminal output instead of raw JSON       |
+
+**Behavior:**
+
+- Queries `GET /api/external/user-notes?user_email=<email>`
+- `--user` is required -- the external GET endpoint requires an explicit user target
+- Results are sorted by the platform: pinned first, then by priority (`urgent` > `high` > `normal` > `low`), then by most recently updated
+- Organization scope is derived from the API key -- only notes belonging to users in the calling organization are returned
+
+**Examples:**
+
+```bash
+# List all notes for a user
+elevasis-sdk note:list --user ops@acme.com
+
+# List only high-priority pinned notes, human-readable
+elevasis-sdk note:list --user ops@acme.com --priority high --pinned --pretty
+```
+
+```
+  Notes (2):
+
+  (no title) [pinned] [high]
+    ID: note_abc001
+    Review run completed for batch_abc123
+
+  Deal X stalled [pinned] [high]
+    ID: note_abc002
+    Deal X has stalled -- follow up needed
+```
+
+---
+
+### Shared Flags
+
+| Flag                | Description                                        |
+| ------------------- | -------------------------------------------------- |
+| `--pretty`          | Human-readable terminal output instead of raw JSON |
+| `--api-url <url>` | Override the API base URL                          |
+
+### Command Boundary
+
+- `note:create` and `note:list` operate on the **personal notes** surface -- not project notes. For project-scoped notes use `project:note:*`.
+- `note:update` and `note:delete` are not yet available via SDK CLI. Edit and delete notes using the Notes panel in the Command Center.
+- The Notes panel view (`NotesPanelView`) is registered in the right-panel registry alongside Overview, Recent Executions, and Notifications.
+
+**Implementation:** `packages/sdk/src/cli/commands/notes.ts` -- delegates to `POST /api/external/user-notes` and `GET /api/external/user-notes`
+
+---
+
 ## elevasis-sdk ui:use-local / ui:use-published
 
 Switch the `@elevasis/ui` dependency in an external project between a local tarball build and the published npm package.

package/reference/deployment/provided-features.mdx

@@ -4,15 +4,15 @@ description: Shared UI and API surfaces for packaged business systems like Lead
 loadWhen: "Building against packaged app features, list-oriented lead gen, CRM, or project-management surfaces"
 ---
 
-The SDK includes more than workflow execution. The published `@elevasis/ui` package provides feature manifests, pages, hooks, and headless provider exports for building shell-aware applications.
+The SDK includes more than workflow execution. The published `@elevasis/ui` package provides system manifests, pages, hooks, and headless provider exports for building shell-aware applications.
 
 ## Shared Shell Contract
 
-`ElevasisFeaturesProvider` reads a flat `OrganizationModel.features` list and exposes a shell model with feature-tree helpers. Feature manifests provide implementation hooks such as icons and sidebars; they do not own structural navigation.
+`ElevasisSystemsProvider` reads the canonical `OrganizationModel`, including `navigation.sidebar`, and exposes a shell model plus sidebar projection helpers. System manifests provide implementation hooks such as icons and subshell sidebars; they do not own structural navigation.
 
 ```tsx
 import { Outlet } from '@tanstack/react-router'
-import { ElevasisFeaturesProvider, FeatureShell } from '@elevasis/ui/provider'
+import { ElevasisSystemsProvider, FeatureShell } from '@elevasis/ui/provider'
 import { leadGenManifest } from '@elevasis/ui/features/lead-gen'
 import { crmManifest } from '@elevasis/ui/features/crm'
 import { deliveryManifest } from '@elevasis/ui/features/delivery'
@@ -30,11 +30,11 @@ const features = [
 
 export function AppShell() {
   return (
-    <ElevasisFeaturesProvider features={features} organizationModel={canonicalOrganizationModel}>
+    <ElevasisSystemsProvider systems={features} organizationModel={canonicalOrganizationModel}>
       <FeatureShell>
         <Outlet />
       </FeatureShell>
-    </ElevasisFeaturesProvider>
+    </ElevasisSystemsProvider>
   )
 }
 ```
@@ -47,7 +47,7 @@ Host apps still own TanStack route registration, topbar behavior, branding, auth
 | --- | --- | --- |
 | Manifest-backed shared subshell features | Feature manifest plus shared sidebar/pages, mounted through `@elevasis/ui/provider` | Lead Gen, CRM, Projects, Operations |
 | Shared feature pages and hooks | Pages, hooks, and helpers that can be composed inside host routes | Monitoring, Settings, Dashboard widgets |
-| Headless provider contract | Provider, hooks, and shell model helpers | `ElevasisFeaturesProvider`, `useElevasisFeatures`, `FeatureShell` |
+| Headless provider contract | Provider, hooks, and shell model helpers | `ElevasisSystemsProvider`, `useElevasisSystems`, `FeatureShell` |
 | Compatibility barrel | Existing imports remain available while newer integrations prefer feature/provider subpaths | `@elevasis/ui/components` |
 
 ## System Map
@@ -64,22 +64,36 @@ Host apps still own TanStack route registration, topbar behavior, branding, auth
 
 ## Organization Model Alignment
 
-Feature IDs in manifests must match Organization Model feature IDs:
+Manifest `systemId` values must match Organization Model System IDs. Sidebar placement is authored separately under `navigation.sidebar`:
 
 ```ts
-features: [
-  { id: 'dashboard', label: 'Dashboard', enabled: true, path: '/', uiPosition: 'sidebar-primary' },
-  { id: 'sales', label: 'Sales', enabled: true, uiPosition: 'sidebar-primary' },
-  { id: 'sales.crm', label: 'CRM', enabled: true, path: '/crm' },
-  { id: 'operations.resources', label: 'Resources', enabled: true, path: '/operations/resources' }
-]
+systems: {
+  dashboard: { id: 'dashboard', order: 10, label: 'Dashboard', lifecycle: 'active' },
+  clients: { id: 'clients', order: 20, label: 'Clients', lifecycle: 'active' }
+},
+navigation: {
+  sidebar: {
+    primary: {
+      dashboard: { type: 'surface', order: 10, label: 'Dashboard', path: '/', surfaceType: 'dashboard', targets: { systems: ['dashboard'] } },
+      business: {
+        type: 'group',
+        order: 20,
+        label: 'Business',
+        children: {
+          clients: { type: 'surface', order: 20, label: 'Clients', path: '/clients', surfaceType: 'list', targets: { systems: ['clients'] } }
+        }
+      }
+    },
+    bottom: {}
+  }
+}
 ```
 
-Sidebar hierarchy is derived from dotted IDs. Containers omit `path`; leaves provide `path`.
+Dashboard appears before Business in the primary sidebar. Business is a navigation group only; `/clients` is the canonical client route.
 
 ## Choosing The Right Surface
 
-- Need packaged sidebar/page composition? Use `ElevasisFeaturesProvider`, `FeatureShell`, and manifests from `@elevasis/ui/features/*`.
+- Need packaged sidebar/page composition? Use `ElevasisSystemsProvider`, `FeatureShell`, and manifests from `@elevasis/ui/features/*`.
 - Need a root dashboard? Keep that route host-owned and compose dashboard components.
 - Need list-scoped lead-gen runtime behavior? Use the `list` adapter, then `acqDb` for broader acquisition CRUD.
 - Need project/task automation? Use `elevasis-sdk project:*`.

package/reference/examples/organization-model.ts

@@ -174,7 +174,7 @@ export const workflowResourceDescriptorsExample = defineResources({
     kind: 'workflow',
     systemId: 'sys.prospecting',
     ownerRoleId: 'role-ops-lead',
-    capabilityKey: 'prospecting.lead-enrichment',
+    actionKey: 'prospecting.lead-enrichment',
     status: 'active' as const
   }
 })

package/reference/packages/core/src/knowledge/README.md

@@ -1,4 +1,4 @@
-# @elevasis/core/knowledge
+# @elevasis/core/knowledge
 
 Pure query layer over the organization graph. Browser-safe (no Node APIs); shared by the SDK CLI, platform CLI, and the `@elevasis/ui/knowledge` browser.
 
@@ -6,18 +6,18 @@ Pure query layer over the organization graph. Browser-safe (no Node APIs); share
 
 | Export                                        | Purpose                                                                                                                             |
 | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
-| `byFeature(graph, featureId, knowledgeNodes)` | Knowledge nodes that govern the given feature.                                                                                      |
+| `bySystem(graph, systemId, knowledgeNodes)` | Knowledge nodes that govern the given system.                                                                                      |
 | `byKind(graph, kind, knowledgeNodes)`         | Filter knowledge nodes by `OrgKnowledgeKind`.                                                                                       |
 | `byOwner(graph, ownerId, knowledgeNodes)`     | Knowledge nodes whose `ownerIds` includes the given owner.                                                                          |
-| `governs(graph, nodeId)`                      | Outgoing `governs` targets (governed-feature ids) from a knowledge node.                                                            |
-| `governedBy(graph, nodeId)`                   | Incoming `governs` sources (governing knowledge-node ids) into a feature.                                                           |
-| `parsePath(pathString)`                       | Parse `/by-feature/$id`, `/by-kind/$kind`, `/by-owner/$id`, `/graph/$id/{governs,governed-by}`, or `/$id`. Throws on invalid input. |
+| `governs(graph, nodeId)`                      | Outgoing `governs` targets (governed-system ids) from a knowledge node.                                                            |
+| `governedBy(graph, nodeId)`                   | Incoming `governs` sources (governing knowledge-node ids) into a system.                                                           |
+| `parsePath(pathString)`                       | Parse `/by-system/$id`, `/by-kind/$kind`, `/by-owner/$id`, `/graph/$id/{governs,governed-by}`, or `/$id`. Throws on invalid input. |
 | `formatText`, `formatJson`, `formatIdsOnly`   | Output formatters used by the `knowledge:*` CLI subcommands.                                                                        |
 
 ## Path syntax
 
 ```
-/by-feature/<featureId>
+/by-system/<systemId>
 /by-kind/<playbook|strategy|reference>
 /by-owner/<ownerId>
 /graph/<nodeId>/governs
@@ -27,6 +27,7 @@ Pure query layer over the organization graph. Browser-safe (no Node APIs); share
 
 ## JSON envelope
 
-`formatJson` returns `{ path, mount, args, results }` — the same wrapped envelope used by `pnpm exec elevasis knowledge:ls --json` and `pnpm exec elevasis-sdk knowledge:ls --json`.
+`formatJson` returns `{ path, mount, args, results }` — the same wrapped envelope used by `pnpm exec elevasis knowledge:ls --json` and `pnpm exec elevasis-sdk knowledge:ls --json`.
 
 `governs` and `governedBy` accept either bare or graph-namespaced ids (`knowledge.foo` or `knowledge:knowledge.foo`).
+