@elevasis/sdk 1.20.1 → 1.21.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elevasis/sdk",
-  "version": "1.20.1",
+  "version": "1.21.0",
   "description": "SDK for building Elevasis organization resources",
   "type": "module",
   "bin": {
@@ -57,9 +57,9 @@
     "tsup": "^8.0.0",
     "typescript": "5.9.2",
     "zod": "^4.1.0",
-    "@repo/core": "0.22.0",
-    "@repo/eslint-config": "0.0.0",
-    "@repo/typescript-config": "0.0.0"
+    "@repo/core": "0.23.0",
+    "@repo/typescript-config": "0.0.0",
+    "@repo/eslint-config": "0.0.0"
   },
   "scripts": {
     "lint": "eslint src --max-warnings 0",

package/reference/_navigation.md

@@ -1,3 +1,5 @@
+<!-- @generated by scripts/monorepo/generate-reference-artifacts.js -- DO NOT EDIT -->
+
 # SDK Reference Navigation
 
 Auto-generated from the package reference manifests.
@@ -20,7 +22,7 @@ Package entries indexed: 55.
 
 | Resource | Location | Description | When to Load |
 | --- | --- | --- | --- |
-| Knowledge | `packages/core/src/knowledge/README.md` | Published knowledge query layer: byFeature/byKind/byOwner/governs/governedBy queries, parsePath, and output formatters. | (not specified) |
+| Knowledge | `packages/core/src/knowledge/README.md` | Published knowledge query layer: bySystem/byKind/byOwner/governs/governedBy queries, parsePath, and output formatters. | (not specified) |
 
 ## @elevasis/core / Organization Model
 
@@ -153,17 +155,17 @@ Universal scaffold documentation for all SDK projects. Source locations are co-l
 | Document | Bundle Path | Description |
 | --- | --- | --- |
 | Scaffold Index | `scaffold/index.mdx` | Discovery entry point and navigation map |
-| Add a Feature | `scaffold/recipes/add-a-feature.md` | End-to-end feature addition recipe |
+| Add a System | `scaffold/recipes/add-a-feature.md` | End-to-end system addition recipe |
 | Add a Resource | `scaffold/recipes/add-a-resource.md` | Workflow/agent authoring recipe |
-| Gate by Feature/Admin | `scaffold/recipes/gate-by-feature-or-admin.md` | Access control patterns |
+| Gate by System/Admin | `scaffold/recipes/gate-by-feature-or-admin.md` | Access control patterns |
 | UI Recipes | `scaffold/ui/recipes.md` | Copy-paste UI recipes |
-| Feature Flags & Gating | `scaffold/ui/feature-flags-and-gating.md` | Three-concept gating model |
-| Customizing Features | `scaffold/ui/customization.md` | Sidebar composition patterns |
-| Feature Shell | `scaffold/ui/feature-shell.mdx` | FeatureModule manifest and provider |
+| System Flags & Gating | `scaffold/ui/feature-flags-and-gating.md` | Three-concept gating model |
+| Customizing Systems | `scaffold/ui/customization.md` | Sidebar composition patterns |
+| System Shell | `scaffold/ui/feature-shell.mdx` | SystemModule manifest and provider |
 | Composition & Extensibility | `scaffold/ui/composition-extensibility.mdx` | Layout primitives and overrides |
 | Organization Model | `scaffold/core/organization-model.mdx` | Semantic contract and schema |
 | Organization Graph | `scaffold/core/organization-graph.mdx` | Graph derivation and Cytoscape |
 | Workflow Recipes | `scaffold/operations/workflow-recipes.md` | Workflow anatomy and adapters |
 | Glossary | `scaffold/reference/glossary.md` | Term definitions |
 | Contracts | `scaffold/reference/contracts.md` | Auto-generated type contracts |
-| Feature Registry | `scaffold/reference/feature-registry.md` | Auto-generated feature catalog |
+| System Registry | `scaffold/reference/feature-registry.md` | Auto-generated system catalog |

package/reference/_reference-manifest.json

@@ -35,7 +35,7 @@
       "subpath": "./knowledge",
       "kind": "subpath",
       "title": "Knowledge",
-      "description": "Published knowledge query layer: byFeature/byKind/byOwner/governs/governedBy queries, parsePath, and output formatters.",
+      "description": "Published knowledge query layer: bySystem/byKind/byOwner/governs/governedBy queries, parsePath, and output formatters.",
       "group": "Knowledge",
       "order": 1,
       "sourcePath": "packages/core/src/knowledge/index.ts",

package/reference/claude-config/rules/agent-start-here.md

@@ -182,6 +182,7 @@ Load first:
 - `operations/src/README.md`
 - `.claude/rules/active-change-index.md`
 - Read `operations/src/index.ts` for deployment assembly, `core/config/organization-model.ts` for resource descriptors, or run `pnpm elevasis-sdk project:list --pretty` for live DB state
+- For "why didn't this run?", "why is this still pending?", "what needs approval?", or schedule/queue debugging, inspect live operations state with `pnpm elevasis-sdk schedule:list --pretty`, `pnpm elevasis-sdk queue:list --status pending --pretty`, and `pnpm elevasis-sdk queue:status --pretty`.
 
 Then inspect:
 
@@ -189,12 +190,15 @@ Then inspect:
 - resource definitions
 - related UI route and feature files
 - related core contracts
+- pending HITL items via `elevasis-sdk queue:get <id>` before selecting or expiring an action
+- recurring automation via `elevasis-sdk schedule:get <id>` before pausing, resuming, or cancelling it
 
 Verify with:
 
 - resource registration and relationship declarations
 - generated maps
 - package and source ownership boundaries
+- `queue:*` or `schedule:*` CLI output when runtime state is part of the question
 
 ### 5. Platform Extension / Package Contract Work
 

package/reference/claude-config/rules/frontend.md

@@ -36,8 +36,8 @@ When building pages that display external data, use published `@elevasis/ui` com
 ## Detailed Reference
 
 - `node_modules/@elevasis/sdk/reference/scaffold/ui/recipes.md` -- add a page, add a nav item, theme tokens, feature-scoped components, route patterns (static, nested, dynamic)
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-flags-and-gating.md` -- `featureKey` / `FeatureGuard` / `AdminGuard` model
+- `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-flags-and-gating.md` -- `systemKey` / `SystemGuard` / `AdminGuard` model
 - `node_modules/@elevasis/sdk/reference/scaffold/ui/customization.md` -- sidebar composition via manifest overrides
-- `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` -- TypeScript shapes (`FeatureModule`, `NavItem`, `OrganizationModel`)
+- `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` -- TypeScript shapes (`SystemModule`, `NavItem`, `OrganizationModel`)
 - `ui/src/config/theme.ts` -- theme configuration and CSS variable definitions
 - `ui/src/config/nav-items.ts` -- sidebar navigation entries

package/reference/claude-config/rules/organization-model.md

@@ -9,7 +9,7 @@ paths:
 
 `core/config/organization-model.ts` is the single source of truth for this
 project's organizational identity -- it encodes customers, offerings, roles, goals,
-features, statuses, Systems, and Resources descriptors that agents, workflows, and the
+Systems, Actions, statuses, and Resources descriptors that agents, workflows, and the
 UI shell all consume at runtime.
 
 ## Preferred Entry Point: `/knowledge`
@@ -24,7 +24,7 @@ Direct edits to `organization-model.ts` are discouraged. Instead, use `/knowledg
    is verified. On failure the file is rolled back automatically.
 
 Use `/knowledge <domain>` for targeted edits: `identity`, `customers`, `offerings`,
-`roles`, `goals`, `techStack`, `features`, or `labels`. Resource identity and
+`roles`, `goals`, `techStack`, `systems`, `actions`, or `labels`. Resource identity and
 governance metadata belong in `resources.entries`; operations code derives runtime
 `resourceId` / `type` from those descriptors.
 
@@ -43,3 +43,45 @@ to explicit user confirmation before scaffolding a new `.ts` file.
 
 This is a soft guide, not a hard block. The ceremony exists to prevent silent schema
 drift and to keep the model's editorial history visible.
+
+## Resource System Attachment
+
+Every resource in `organizationModel.resources.entries` declares which System it belongs to
+via `systemPath` -- a dot-separated path that resolves against the OM system tree
+(e.g. `"sys.lead-gen"`, `"business.sales.crm"`):
+
+```ts
+{
+  id: 'apify-website-crawl',
+  systemPath: 'sys.lead-gen',   // canonical system attachment
+  kind: 'workflow',
+  ...
+}
+```
+
+`systemPath` is validated at parse time by `SystemPathSchema` and cross-checked by
+`OrganizationModelSchema.superRefine` -- an unresolvable path causes a Zod error at
+schema validation. Use `getResourcesForSystem(model, path)` (from `@elevasis/core`) to
+query resources for a system at runtime. Pass `{ includeDescendants: true }` to include
+all descendant systems (segment-aware -- `'sales'` does NOT match `'salesforce.foo'`).
+
+Some external templates may carry a `systemId` compatibility mirror while published
+`@elevasis/core` releases catch up to the current source contract. Treat that field as
+legacy adapter data only; author new resource relationships against `systemPath`.
+
+Do not fetch resources for every system-oriented read by default. For agent workflows, start
+with the user's requested OM/knowledge context and query resources only when the task involves
+runtime ownership, executable implementation, observability, deployment, or resource governance.
+Use the descendant rollup only when parent-system scope is intended.
+
+`resource.category` and `resource.links[].nodeId` are **runtime filter overlays** -- they
+drive UI faceted filtering in the Command Center but do NOT define system membership.
+System membership is `systemPath` only.
+
+```ts
+// category and links power UI filter chips; systemPath is the
+// canonical OM attachment used for graph edges and getResourcesForSystem queries.
+```
+
+See `.claude/rules/system-shaping.md` (in the monorepo) for the substrate-shaping
+propagation checklist that governs renames of this shape.

package/reference/claude-config/rules/organization-os.md

@@ -1,13 +1,13 @@
 # Organization OS
 
-Organization OS is the semantic contract layer defining how organizations, features, domains, surfaces, entities, capabilities, and resources relate. This project consumes Organization OS through the SDK and foundations config.
+Organization OS is the semantic contract layer defining how organizations, Systems, Actions, domains, surfaces, entities, and resources relate. This project consumes Organization OS through published `@elevasis/core` / `@elevasis/sdk` configuration and does not maintain the monorepo schema.
 
 ## Key Files in This Project
 
 - `core/config/organization-model.ts` -- project-specific org model definition, Systems, and Resources descriptor catalog (`organizationModel.resources.entries`)
 - `core/config/extensions/` -- project-owned entity extension schemas
 - `core/types/entities.ts` -- typed entity contracts (Project, Deal, etc.). Extends `BaseProject`, `BaseDeal` from `@elevasis/core/entities` with project-specific metadata. Read this when authoring workflows that operate on these entities.
-- `ui/src/routes/__root.tsx` -- wires `ElevasisFeaturesProvider` with `canonicalOrganizationModel`
+- `ui/src/routes/__root.tsx` -- wires `ElevasisSystemsProvider` with `canonicalOrganizationModel`
 - `ui/src/app-config.ts` -- references the org model
 - `operations/src/index.ts` -- `DeploymentSpec` registry for workflows and agents
 
@@ -15,21 +15,21 @@ Organization OS is the semantic contract layer defining how organizations, featu
 
 As of the 2026-05 resource-governance expansion, `OrganizationModel` includes platform configuration, organizational reality, and governance domains:
 
-**Platform configuration:** `features`, `branding`, `navigation`, `sales` (formerly `crm`), `prospecting` (formerly `leadGen`), `projects` (formerly `delivery`)
+**Platform configuration:** `systems`, `actions`, `branding`, `navigation`, `sales` (formerly `crm`), `prospecting` (formerly `leadGen`), `projects` (formerly `delivery`)
 
 **Organizational reality:** `identity`, `customers`, `offerings`, `roles`, `goals`
 
-**Governance:** `systems`, `resources`
+**Governance:** `resources` and System-to-Action relationships
 
 **Vibe layer:** `statuses`, `operations`
 
-Resource identity is authored once in `resources.entries`. Operations imports those descriptors and derives runtime `resourceId` / `type` while assembling the `DeploymentSpec`.
+Resource identity is authored once in `resources.entries`. Each resource attaches to a System via `systemPath`; some templates may include a temporary `systemId` compatibility mirror for older published `@elevasis/core` packages. Operations imports those descriptors and derives runtime `resourceId` / `type` while assembling the `DeploymentSpec`.
 
 ### Domain Rename Note
 
-Three field names changed in the 2026-04-20 expansion. Feature ID constants and consumer-facing feature IDs are unchanged:
+Three field names changed in the 2026-04-20 expansion. Legacy UI feature constants and consumer-facing route keys are unchanged:
 
-| Old field  | New field     | Feature ID (unchanged) | Constant (unchanged)  |
+| Old field  | New field     | Legacy key (unchanged) | UI constant (unchanged) |
 | ---------- | ------------- | ---------------------- | --------------------- |
 | `crm`      | `sales`       | `'crm'`                | `CRM_FEATURE_ID`      |
 | `leadGen`  | `prospecting` | `'lead-gen'`           | `LEAD_GEN_FEATURE_ID` |
@@ -46,7 +46,7 @@ All paths under `node_modules/@elevasis/sdk/reference/scaffold/`:
 - `node_modules/@elevasis/sdk/reference/scaffold/index.mdx` -- scaffold root and navigation
 - `node_modules/@elevasis/sdk/reference/scaffold/core/organization-model.mdx` -- semantic contract, all 14 domains, adapter authoring, validation gate, `/knowledge` entry point
 - `node_modules/@elevasis/sdk/reference/scaffold/core/organization-graph.mdx` -- graph derivation, node/edge taxonomy, lenses
-- `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-shell.mdx` -- FeatureModule manifest, provider runtime
+- `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-shell.mdx` -- SystemModule manifest, provider runtime
 - `node_modules/@elevasis/sdk/reference/scaffold/ui/composition-extensibility.mdx` -- layout primitives, router abstraction
 - `node_modules/@elevasis/sdk/reference/scaffold/ui/recipes.md` -- copy-paste UI recipes for pages, nav items, components
 - `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-flags-and-gating.md` -- three-concept gating model
@@ -68,8 +68,8 @@ All paths under `node_modules/@elevasis/sdk/reference/scaffold/`:
 
 ## Published Subpaths and Constants
 
-- `@elevasis/core/organization-model` -- the curated organization-model barrel. Exports `defineOrganizationModel`, `resolveOrganizationModel`, `OrganizationModelSchema`, `DEFAULT_ORGANIZATION_MODEL`, organization-model types, and typed feature/surface constants.
-  - Feature IDs: `CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`, `PROJECTS_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, `MONITORING_FEATURE_ID`, `SETTINGS_FEATURE_ID`, `SEO_FEATURE_ID`
+- `@elevasis/core/organization-model` -- the curated organization-model barrel. Exports `defineOrganizationModel`, `resolveOrganizationModel`, `OrganizationModelSchema`, `DEFAULT_ORGANIZATION_MODEL`, organization-model types, and typed System/Action plus legacy UI feature/surface constants.
+  - Legacy UI feature IDs: `CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`, `PROJECTS_FEATURE_ID`, `OPERATIONS_FEATURE_ID`, `MONITORING_FEATURE_ID`, `SETTINGS_FEATURE_ID`, `SEO_FEATURE_ID`
   - Headline surface IDs: `CRM_PIPELINE_SURFACE_ID`, `LEAD_GEN_LISTS_SURFACE_ID`, `PROJECTS_INDEX_SURFACE_ID`, `OPERATIONS_ORGANIZATION_GRAPH_SURFACE_ID`
   - Reality domain types: `OrganizationModelIdentity`, `OrganizationModelCustomers`, `OrganizationModelCustomerSegment`, `OrganizationModelOfferings`, `OrganizationModelProduct`, `OrganizationModelRoles`, `OrganizationModelRole`, `OrganizationModelGoals`, `OrganizationModelObjective`, `OrganizationModelKeyResult`
   - Vibe domain types: `OrganizationModelStatuses`, `OrganizationModelOperations`
@@ -83,7 +83,7 @@ All paths under `node_modules/@elevasis/sdk/reference/scaffold/`:
 - **Building or extending CRM:** Start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-crm.md`. CRM spans Organization OS sales semantics, shared UI primitives, deal hooks, workflow adapters, and generated contracts.
 - **Building or extending lead gen:** Start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md`. Lead gen spans Organization OS prospecting semantics, shared UI primitives, list/member hooks, artifact hooks, workflow adapters, and generated contracts.
 - **Customizing CRM deal actions:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/customize-crm-actions.md`. Do not add `sales.actions` to the org model; the v1 server-side override surface is intentionally deferred.
-- **Adding a feature:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-feature.md`. For toggling an existing feature, use `/knowledge features`.
+- **Adding or toggling a System:** Follow the current scaffold recipes when they mention UI features, but translate Organization OS changes to Systems, navigation surfaces, and Actions. Use `/knowledge systems` for availability/routing changes.
 - **Adding a resource:** Follow `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-resource.md`.
 - **Extending entities:** Start with `core/types/entities.ts` for the demo extension pattern. Base shapes come from `@elevasis/core/entities`.
 - **Authoring a workflow that takes a Project/Deal/etc.:** Reference entity types from `core/types/entities.ts` in the input schema -- do not redeclare them.
@@ -103,7 +103,7 @@ All paths under `node_modules/@elevasis/sdk/reference/scaffold/`:
 - `/knowledge roles` -- role chart with responsibilities, reporting lines, and holders
 - `/knowledge goals` -- organizational goals with period and measurable outcomes
 - `/knowledge techStack` -- external-SaaS and integration context; resource identity still belongs in OM Resources descriptors
-- `/knowledge features` -- enable, disable, or add features
+- `/knowledge systems` -- enable, disable, or add Systems; route invokable behavior through Actions
 - `/knowledge labels` -- edit display labels on enum entries (statuses, stages)
 
 Every write is gated: `resolveOrganizationModel()` must succeed (Zod cross-refs pass) and `pnpm -C operations check-types` must pass. On failure the change is rolled back.

package/reference/claude-config/rules/ui.md

@@ -10,16 +10,16 @@ paths:
 
 ## App Shell Overview
 
-The template frontend is a React 19 + TanStack Router app that composes a local dashboard shell with published feature manifests from `@elevasis/ui`.
+The template frontend is a React 19 + TanStack Router app that composes a local dashboard shell with published System modules from `@elevasis/ui`.
 
 The main join points are:
 
 - `ui/src/main.tsx` -- boots the app with `ElevasisUIProvider`, query client, theme config, WorkOS AuthKit, notifications, and the generated route tree
-- `ui/src/routes/__root.tsx` -- composes the authenticated shell with `ElevasisFeaturesProvider`, published feature manifests, app-local dashboard nav, shell runtime dependencies, and `FeatureShell`
+- `ui/src/routes/__root.tsx` -- composes the authenticated shell with `ElevasisSystemsProvider`, published System modules, app-local dashboard nav, shell runtime dependencies, and `SystemShell`
 - `ui/src/config/nav-items.ts` -- keeps the host-local dashboard entry separate from the published feature manifests
-- `core/config/organization-model.ts` -- is the template's semantic source of truth, adapting `@elevasis/core/organization-model` into the preserved branding, dashboard label, quick-access, feature-label, resource descriptors, and shell helpers
+- `core/config/organization-model.ts` -- is the template's semantic source of truth, adapting `@elevasis/core/organization-model` into the preserved branding, dashboard label, quick-access, System labels, resource descriptors, and shell helpers
 
-Published feature manifests mounted by the template shell:
+Published System modules mounted by the template shell:
 
 - `lead-gen`
 - `crm`
@@ -30,7 +30,7 @@ Published feature manifests mounted by the template shell:
 
 Important distinction:
 
-- shared manifests gate on grouped org-model keys such as `acquisition` and `delivery`
+- shared modules gate on current org-model System keys such as `sales.lead-gen` and `projects`
 - template routes and local nav may still use legacy aliases such as `crm`, `lead-gen`, and `projects`
 - `core/config/organization-model.ts` and `ui/src/lib/hooks/useFeatureAccess.ts` are the bridge between those two vocabularies
 
@@ -40,7 +40,7 @@ This template should be treated as the downstream reference implementation for t
 
 - foundations owns the organization/runtime semantics
 - `ui/src/config/nav-items.ts` preserves the host-local dashboard entry instead of pushing that concern into shared manifests
-- `ui/src/routes/__root.tsx` threads `canonicalOrganizationModel` from foundations into `ElevasisFeaturesProvider` so the shared shell/runtime uses the same semantic source of truth as the local template helpers
+- `ui/src/routes/__root.tsx` threads `canonicalOrganizationModel` from foundations into `ElevasisSystemsProvider` so the shared shell/runtime uses the same semantic source of truth as the local template helpers
 - host-local customizations still stay local: dashboard remains app-owned nav, branding stays in app config, and quick-access/dashboard UX stays in the template app
 
 ## Auth and Initialization
@@ -126,10 +126,10 @@ Current top-level app sections:
 Section guards currently follow this pattern:
 
 - `ProtectedRoute` for all authenticated sections
-- `FeatureGuard` on all feature sections that should hard-stop when a feature is disabled: `crm`, `lead-gen`, `projects`, `operations`, and `monitoring`
-- provider-level shell gating for shared feature nav and sub-shell behavior
+- `SystemGuard` on sections that should hard-stop when a System is disabled: `crm`, `lead-gen`, `projects`, `operations`, and `monitoring`
+- provider-level shell gating for shared System nav and sub-shell behavior
 
-The app shell in `__root.tsx` derives visible nav from `shellModel.navItems`, filters admin-only entries locally using the signed-in profile, and passes `canonicalOrganizationModel` into `ElevasisFeaturesProvider` so shared nav labels, paths, and graph runtime behavior resolve from the same foundations-backed semantic model.
+The app shell in `__root.tsx` derives visible nav from `shellModel.systems` and `getSidebarLinks()`, filters admin-only entries locally using the signed-in profile, and passes `canonicalOrganizationModel` into `ElevasisSystemsProvider` so shared nav labels, paths, and graph runtime behavior resolve from the same foundations-backed semantic model.
 
 ## Dashboard and Feature Areas
 
@@ -165,14 +165,14 @@ The main template-owned customization surfaces are:
 - `ui/src/config/background.tsx` -- shared background treatment
 - `ui/src/config/loader.tsx` -- global loader element
 - `ui/src/config/nav-items.ts` -- app-local nav entries, including the preserved dashboard/home entry
-- `core/config/organization-model.ts` -- product labels, feature enablement, resource descriptors, semantic surfaces, canonical-to-legacy surface aliases, and quick-access behavior
+- `core/config/organization-model.ts` -- product labels, System availability, resource descriptors, semantic surfaces, canonical-to-legacy surface aliases, and quick-access behavior
 - `ui/src/config/README.md` -- the deeper guide for those config files
 
-## Customizing Feature Sidebars
+## Customizing System Sidebars
 
-The template demonstrates one override pattern in `ui/src/routes/__root.tsx`: it extends `CRM_ITEMS` with a template-owned Reports link and replaces `crmManifest` with `customCrmManifest` in the feature manifest array. The backing route lives at `ui/src/routes/crm/reports.tsx` -- delete both the nav item and the route if you don't need them.
+The template demonstrates one override pattern in `ui/src/routes/__root.tsx`: it extends `CRM_ITEMS` with a template-owned Reports link and replaces `crmManifest` with `customCrmManifest` in the System module array. The backing route lives at `ui/src/routes/crm/reports.tsx` -- delete both the nav item and the route if you don't need them.
 
-Two customization layers are available for every shared feature sidebar:
+Two customization layers are available for every shared System sidebar:
 
 1. **Nav-item shortcut (`items` prop)** -- when you just need to swap or extend the nav array, spread the published items constant and pass the result to `*SidebarMiddle`. The template's CRM customization uses this path.
 
@@ -189,7 +189,7 @@ Two customization layers are available for every shared feature sidebar:
 
 `manifest.sidebar` accepts any component, so arbitrary customization is always available. The `items` prop is an abstraction barrier for the common case, not a limit.
 
-See `node_modules/@elevasis/sdk/reference/scaffold/ui/customization.md` for the decision tree, page-wrapping pattern, and delivery's three-section variant. For broader CRM extension work across pages, hooks, actions, workflows, and org-model boundaries, start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-crm.md`. For broader lead-gen extension work across pages, hooks, list/member state, artifacts, workflows, and org-model boundaries, start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md`. See `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` for `NavItem`, `FeatureModule`, CRM platform primitives, Lead Gen platform primitives, and related TypeScript shapes.
+See `node_modules/@elevasis/sdk/reference/scaffold/ui/customization.md` for the decision tree, page-wrapping pattern, and delivery's three-section variant. For broader CRM extension work across pages, hooks, actions, workflows, and org-model boundaries, start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-crm.md`. For broader lead-gen extension work across pages, hooks, list/member state, artifacts, workflows, and org-model boundaries, start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md`. See `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` for `NavItem`, `SystemModule`, CRM platform primitives, Lead Gen platform primitives, and related TypeScript shapes.
 
 For CRM deal action buttons, read `node_modules/@elevasis/sdk/reference/scaffold/recipes/customize-crm-actions.md` before changing `crmActions`, `DealDetailPage`, `DealDrawer`, or custom workflow buttons. Start with the shared `crmActions` provider path for action visibility, labels, ordering, and render-time configuration. In v1, platform-known/default action endpoint behavior is server-constrained; use project-owned UI that calls the workflow directly when a custom key sits outside that server-dispatched set.
 

package/reference/claude-config/rules/vibe.md

@@ -30,25 +30,27 @@ The user wants to record something new -- a task, a note, a piece of information
 | ------------------------------------------------- | ------------------------------------------- |
 | "Add a task to follow up with the Shopify client" | Explicit "add a task" with a described item |
 | "Remember to run the campaign report on Friday"   | "Remember to" signals something to persist  |
+| "Run the campaign report every Friday at 9am"     | Repeating schedule vocabulary to persist    |
 | "Track this conversation as a deal note"          | Explicit "track" with a described artifact  |
 
-**Agent action:** draft the capture in plain language, confirm with the user, then execute via `elevasis-sdk project:*` commands. Never write without confirmation.
+**Agent action:** draft the capture in plain language, confirm with the user, then execute via `elevasis-sdk project:*` commands for project records or `elevasis-sdk schedule:create` for recurring automation. Use repetition vocabulary ("every", "daily", "weekly", "monthly") for schedules; one-shot future reminders stay project tasks with due dates. Never write without confirmation.
 
 ### 2. Query
 
 The user wants to know something about current state -- task priorities, what is pending, what is running, what failed.
 
-**Recognize by:** questions about the current list, status, or queue of things. Includes both static-model queries ("what features are on?") and runtime-entity queries ("what's pending in the queue?"). Route Query to static-model sources (org model, features config) or runtime sources (operations domain) based on the referenced entity.
+**Recognize by:** questions about the current list, status, or queue of things. Includes both static-model queries ("what systems are on?") and runtime-entity queries ("what's pending in the queue?"). Route Query to static-model sources (org model, Systems/Actions config) or runtime sources (operations domain) based on the referenced entity.
 
 **Fixture examples:**
 
-| Input                                         | Why it's Query                              |
-| --------------------------------------------- | ------------------------------------------- |
-| "What should I work on next?"                 | Asking for prioritized task list            |
-| "What's pending in the HITL queue?"           | Runtime-entity query about operations state |
-| "What features are enabled for this project?" | Static-model query about features config    |
+| Input                                        | Why it's Query                              |
+| -------------------------------------------- | ------------------------------------------- |
+| "What should I work on next?"                | Asking for prioritized task list            |
+| "What's pending in the HITL queue?"          | Runtime-entity query about operations state |
+| "What runs this week?"                       | Runtime query about upcoming schedules      |
+| "What systems are enabled for this project?" | Static-model query about Systems config     |
 
-**Agent action:** read the relevant source (org model, `prj_tasks`, operations domain as available) and narrate the answer in plain language. No writes.
+**Agent action:** read the relevant source and narrate the answer in plain language. Use org model or `project:*` for project state, `elevasis-sdk queue:list --status pending --pretty` and `queue:status --pretty` for HITL queue state, and `elevasis-sdk schedule:list --status active --pretty` for upcoming recurring automation. No writes.
 
 ### 3. Describe
 
@@ -61,10 +63,10 @@ The user wants the agent to explain something -- a scope, an entity, a concept w
 | Input                                      | Why it's Describe                                     |
 | ------------------------------------------ | ----------------------------------------------------- |
 | "What's going on with the ZentaraHQ deal?" | Asking for a plain-language description of an entity  |
-| "Tell me about the CRM feature"            | Asking the agent to narrate what a model element does |
+| "Tell me about the CRM system"             | Asking the agent to narrate what a model element does |
 | "Where am I in this project?"              | Asking for current scope narration                    |
 
-**Agent action:** read the relevant org-model label, entity, or scope. Narrate in plain language using label fields from the model -- never invent vocabulary not present in the model. Phase-1 scope covers Model, Features, and Foundations layers only.
+**Agent action:** read the relevant org-model label, entity, or scope. Narrate in plain language using label fields from the model -- never invent vocabulary not present in the model. Phase-1 scope covers Model, Systems/Actions, and Foundations layers only.
 
 **Stage/state/catalog sub-routing:** when the noun being described is a stage, state, status
 bucket, catalog entry, progress step, pipeline column, or similarly closed business vocabulary,
@@ -90,12 +92,14 @@ The user wants to change the status of a task or entity.
 | "Done with the proposal draft"                | "Done" + named artifact = status transition |
 | "Stuck -- blocked waiting on client feedback" | "Stuck" + reason = blocked transition       |
 | "Mark the onboarding task as complete"        | Explicit status-change vocabulary           |
+| "Approve the pending checkpoint"              | Selects an action from the HITL queue       |
+| "Pause the Friday report"                     | Changes schedule state                      |
 
-**Agent action:** identify the task or entity being transitioned, confirm the new status with the user, then apply the transition via `elevasis-sdk project:task:save` or equivalent. Never auto-transition without confirmation if the target entity is ambiguous.
+**Agent action:** identify the task, queue item, schedule, or entity being transitioned, confirm the new status/action with the user, then apply it via `elevasis-sdk project:task:save`, `elevasis-sdk queue:select <id> --action-id <id>`, `elevasis-sdk queue:expire <id>`, `elevasis-sdk schedule:pause <id>`, `schedule:resume <id>`, or `schedule:cancel <id>` as appropriate. Never auto-transition without confirmation if the target entity is ambiguous.
 
 ### 5. Navigate
 
-The user wants to shift focus -- to a different task, project, feature, or layer of the model.
+The user wants to shift focus -- to a different task, project, System, Action, or layer of the model.
 
 **Recognize by:** focus-shift vocabulary -- "focus on", "let's look at", "switch to", "back to", "move to", "open", "go to" -- followed by a scope target.
 
@@ -123,7 +127,7 @@ The user describes organizational reality that is not yet expressed in the model
 | "We track deal stage as discovery, scoping, proposal, closed"                    | Describes custom CRM stages that should replace defaults |
 | "Add a project type called 'retainer' with monthly billing and a contract field" | Explicit request to add a new entity extension           |
 
-**Agent action:** delegate immediately to `/knowledge`. Do not attempt the ceremony yourself. Invoke with the relevant domain: `/knowledge crm` for deal/contact changes, `/knowledge projects` for project types, `/knowledge features` for feature toggles. Plain-language summary of what was detected is acceptable before delegating, but the actual draft-confirm-write ceremony belongs to `/knowledge`.
+**Agent action:** delegate immediately to `/knowledge`. Do not attempt the ceremony yourself. Invoke with the relevant domain: `/knowledge sales` for deal/contact changes, `/knowledge projects` for project types, `/knowledge systems` for availability/routing toggles, and `/knowledge actions` for invokable operation changes. Plain-language summary of what was detected is acceptable before delegating, but the actual draft-confirm-write ceremony belongs to `/knowledge`.
 
 **Stage/state/catalog impact preview:** if the Codify intent adds, renames, removes, reorders, or
 re-scopes a stage, state, status bucket, catalog member, pipeline step, or progress vocabulary,
@@ -139,7 +143,7 @@ change and does not expose monorepo-only commands.
 
 This routing applies to both codify levels (decision #21 -- Codify ceremony delegated to `/knowledge`):
 
-- **Level A** (config-only edits to `organization-model.ts`, feature toggles, label renames): delegate to `/knowledge <domain>` immediately.
+- **Level A** (config-only edits to `organization-model.ts`, System availability/routing toggles, label renames): delegate to `/knowledge <domain>` immediately.
 - **Level B** (new Zod extension files in `core/config/extensions/`): also delegate to `/knowledge <domain>`; `/knowledge` gates Level B to explicit user asks before scaffolding a new TS file.
 
 Vibe detects the intent and delegates in both cases. It does not run either pipeline itself.
@@ -159,37 +163,37 @@ Heuristics for when to propose codification (passed to `/knowledge` as context):
 
 ### 7. Toggle
 
-The user wants to enable or disable a feature.
+The user wants to enable or disable a System.
 
-**Recognize by:** feature-control vocabulary -- "turn on", "enable", "disable", "turn off", "activate", "deactivate" -- followed by a feature name or description.
+**Recognize by:** system-control vocabulary -- "turn on", "enable", "disable", "turn off", "activate", "deactivate" -- followed by a System name or description.
 
 **Fixture examples:**
 
-| Input                           | Why it's Toggle                               |
-| ------------------------------- | --------------------------------------------- |
-| "Turn on the lead-gen feature"  | Explicit "turn on" + feature name             |
-| "Disable monitoring for now"    | "Disable" + feature reference                 |
-| "We don't use SEO, turn it off" | Declarative + "turn it off" = feature disable |
+| Input                           | Why it's Toggle                              |
+| ------------------------------- | -------------------------------------------- |
+| "Turn on the lead-gen system"   | Explicit "turn on" + System name             |
+| "Disable monitoring for now"    | "Disable" + System reference                 |
+| "We don't use SEO, turn it off" | Declarative + "turn it off" = System disable |
 
-**Agent action:** delegate to `/knowledge features`. The ceremony (confirm + edit `core/config/organization-model.ts` + typecheck) belongs to `/knowledge`, not to the ambient rule.
+**Agent action:** delegate to `/knowledge systems`. The ceremony (confirm + edit `core/config/organization-model.ts` + typecheck) belongs to `/knowledge`, not to the ambient rule.
 
 ## Quick Reference Table
 
-| Intent     | Trigger signal                                                  | Routed to                                  |
-| ---------- | --------------------------------------------------------------- | ------------------------------------------ |
-| Capture    | "add", "remember", "track", "log" + a thing                     | Agent -- draft + confirm + `project:*` CLI |
-| Query      | "what's next", "what's pending", "what failed", "what features" | Agent -- read + narrate                    |
-| Describe   | "what is", "tell me about", "explain", "where am I"             | Agent -- narrate from org model labels     |
-| Transition | "done", "stuck", "blocked", "finished", "complete"              | Agent -- confirm + `project:task:save`     |
-| Navigate   | "focus on", "switch to", "back to", "look at"                   | Agent -- update scope + narrate            |
-| Codify     | "we are X", "we track Y", repeated attribute, "add type/field"  | Delegate to `/knowledge \<domain>`         |
-| Toggle     | "enable", "disable", "turn on/off" + feature                    | Delegate to `/knowledge features`          |
+| Intent     | Trigger signal                                                         | Routed to                                                               |
+| ---------- | ---------------------------------------------------------------------- | ----------------------------------------------------------------------- |
+| Capture    | "add", "remember", "track", "log" + a thing                            | Agent -- draft + confirm + `project:*` or `schedule:create` CLI         |
+| Query      | "what's next", "what's pending", "what failed", "what systems"         | Agent -- read with `project:*`, `queue:*`, or `schedule:*` + narrate    |
+| Describe   | "what is", "tell me about", "explain", "where am I"                    | Agent -- narrate from org model labels                                  |
+| Transition | "done", "stuck", "blocked", "finished", "complete", "approve", "pause" | Agent -- confirm + `project:task:save`, `queue:select`, or `schedule:*` |
+| Navigate   | "focus on", "switch to", "back to", "look at"                          | Agent -- update scope + narrate                                         |
+| Codify     | "we are X", "we track Y", repeated attribute, "add type/field"         | Delegate to `/knowledge \<domain>`                                      |
+| Toggle     | "enable", "disable", "turn on/off" + system                            | Delegate to `/knowledge systems`                                        |
 
 ## Source of Truth for Plain Language
 
 All plain-language labels come from the OrganizationModel itself -- never from hardcoded strings in this rule file. Every status, entity kind, and layer name in the model carries an inline `label` field (e.g., `{ id: 'revision_requested', label: 'changes needed', semanticClass: 'blocked' }`). When narrating state or confirming an action, read the label from the model and use it verbatim. Do not invent synonyms or fallback vocabulary.
 
-The unified manifest (delivered via `@elevasis/core/organization-model`) is the canonical vocabulary surface. Vibe classifies against it -- capabilities, features, statuses, operations entities, and resource kinds are all discoverable from the manifest without hardcoding.
+The unified manifest (delivered via `@elevasis/core/organization-model`) is the canonical vocabulary surface. Vibe classifies against it -- Systems, Actions, statuses, operations entities, and resource kinds are all discoverable from the manifest without hardcoding.
 
 ## Ambiguous Intent
 
@@ -218,7 +222,7 @@ Override per project in `core/config/organization-model.ts` under `vibe.classifi
 This rule covers Phase 1 of the vibe layer rollout. The layers the ambient classifier can narrate and codify in Phase 1 are:
 
 - Layer 1 (Model): narrate schema shape, propose codification edits via `/knowledge`
-- Layer 4 (Features): describe which features are on/off, propose enabling one via `/knowledge`
+- Layer 4 (Systems/Actions): describe which Systems are on/off, propose enabling one via `/knowledge`
 - Layer 7 (Foundations): explain and edit `organization-model.ts` and `extensions/` via `/knowledge`
 
 Layers 2 (Public API), 3 (UI Shell Runtime), 5 (Toolkit), and 6 (Graph) require runtime read APIs that are not yet available. Do not attempt to narrate or classify against those layers in Phase 1. If the user's input clearly references one of those layers, acknowledge the scope and explain that full support arrives in a later phase.

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

@@ -17,9 +17,9 @@ Before orienting, scan the user's query for Organization OS terminology. If any
 
 **OS vocabulary triggers:**
 
-- Feature layer: `feature`, `features`, `FeatureModule`, `feature key`, `feature gate`, `feature access`, `gate`, `gating`, `access`, `enable`, `disable`
+- System layer: `system`, `systems`, `SystemModule`, `system key`, `system gate`, `system access`, `gate`, `gating`, `access`, `enable`, `disable`
 - Shell / nav: `manifest`, `shell`, `sub-shell`, `sidebar`, `nav`, `navigation`, `route`
-- Auth / guards: `guard`, `FeatureGuard`, `AdminGuard`, `ProtectedRoute`, `admin`
+- Auth / guards: `guard`, `SystemGuard`, `AdminGuard`, `ProtectedRoute`, `admin`
 - Org model: `organization`, `org model`, `organization model`, `domain`, `surface`
 - Foundations: `foundation`, `foundations`, `@core/`, `adapter`
 - Platform ops: `workflow`, `agent`, `deployment`, `resource`
@@ -29,7 +29,7 @@ Before orienting, scan the user's query for Organization OS terminology. If any
 1. Read `.claude/rules/active-change-index.md` immediately. If the target area is flagged as under active refactor, surface the watch-area warning to the user before proceeding — include the "Load:" doc paths listed in that entry so investigation does not rely on stale scaffold prose.
 2. Build the OS context bundle to pass into Step 3:
    - Always: `node_modules/@elevasis/sdk/reference/scaffold/reference/glossary.md`, `.claude/rules/active-change-index.md`, `.claude/rules/agent-start-here.md`
-   - Features / Shell / Gating queries: add `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-flags-and-gating.md` + `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md`
+   - Systems / Shell / Gating queries: add `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-flags-and-gating.md` + `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md`
    - Workflow / Operations queries: add `.claude/rules/operations.md` + glob `operations/src/**`
    - Organization-model queries: add `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` + `core/config/README.md`
 
@@ -37,9 +37,9 @@ Before orienting, scan the user's query for Organization OS terminology. If any
 
 | Query intent                             | Primary OS layers                | Key reference                                                                            |
 | ---------------------------------------- | -------------------------------- | ---------------------------------------------------------------------------------------- |
-| "Why doesn't my feature show up?"        | Features + UI Shell Runtime      | `glossary.md` (accessFeatureKey, FEATURE_KEY_ALIASES), `feature-flags-and-gating.md`     |
-| "How do I add a nav item?"               | Features + Toolkit               | `feature-flags-and-gating.md`, `contracts.md`                                            |
-| "How does admin gating work?"            | Features + UI Shell Runtime      | `glossary.md` (AdminGuard, requiresAdmin, ProtectedRoute), `feature-flags-and-gating.md` |
+| "Why doesn't my system show up?"         | Systems + UI Shell Runtime       | `glossary.md` (SystemModule, SystemGuard), `feature-flags-and-gating.md`                 |
+| "How do I add a nav item?"               | Systems + Toolkit                | `feature-flags-and-gating.md`, `contracts.md`                                            |
+| "How does admin gating work?"            | Systems + UI Shell Runtime       | `glossary.md` (AdminGuard, requiresAdmin, ProtectedRoute), `feature-flags-and-gating.md` |
 | "What runs when this workflow triggers?" | Platform Public API + Operations | `.claude/rules/operations.md`, `resources.md`                                            |
 | "Why does the foundations adapter fail?" | Foundations                      | `glossary.md` (domain vs surface, settings asymmetry), `core/config/README.md`    |