@elevasis/sdk 1.47.0 → 1.49.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/cli.cjs +1034 -319
- package/dist/index.d.ts +687 -49
- package/dist/index.js +297 -47
- package/dist/node/index.d.ts +110 -26
- package/dist/test-utils/index.d.ts +649 -36
- package/dist/test-utils/index.js +275 -45
- package/dist/worker/index.d.ts +687 -53
- package/dist/worker/index.js +121 -6
- package/package.json +2 -2
- package/reference/_navigation.md +7 -6
- package/reference/_reference-manifest.json +12 -2
- package/reference/core/index.mdx +6 -4
- package/reference/index.mdx +11 -5
- package/reference/packages/core/src/README.md +46 -44
- package/reference/packages/core/src/content/README.md +13 -12
- package/reference/packages/core/src/organization-model/README.md +9 -6
- package/reference/rules/content.md +27 -0
- package/reference/rules/organization-model.md +9 -3
- package/reference/rules/organization-os.md +2 -2
- package/reference/rules/ui.md +1 -1
- package/reference/rules/vibe-intents.md +19 -16
- package/reference/rules/vibe.md +32 -12
- package/reference/scaffold/recipes/add-a-feature.md +1 -1
- package/reference/scaffold/recipes/customize-organization-model.md +2 -2
- package/reference/scaffold/recipes/extend-content.md +172 -30
- package/reference/scaffold/reference/glossary.md +2 -2
- package/reference/scaffold/reference/system-interface-capabilities.md +26 -6
- package/reference/sdk/cli-management.mdx +246 -41
- package/reference/sdk/cli.mdx +103 -64
- package/reference/sdk/define-builders.mdx +1 -1
- package/reference/sdk/deployment/command-center.mdx +2 -2
- package/reference/sdk/deployment/index.mdx +1 -1
- package/reference/sdk/exports.mdx +4 -4
- package/reference/sdk/framework/agent.mdx +4 -3
- package/reference/sdk/framework/index.mdx +1 -1
- package/reference/sdk/framework/project-structure.mdx +34 -23
- package/reference/sdk/framework/tutorial-system.mdx +1 -1
- package/reference/sdk/getting-started.mdx +25 -52
- package/reference/sdk/index.mdx +3 -3
- package/reference/sdk/platform-tools/adapters-integration.mdx +1 -1
- package/reference/sdk/platform-tools/adapters-platform.mdx +5 -5
- package/reference/sdk/platform-tools/type-safety.mdx +1 -1
- package/reference/sdk/resources/patterns.mdx +10 -11
- package/reference/sdk/resources/types.mdx +15 -9
- package/reference/sdk/templates/data-enrichment.mdx +1 -1
- package/reference/sdk/templates/email-sender.mdx +1 -1
- package/reference/sdk/templates/index.mdx +47 -47
- package/reference/sdk/templates/lead-scorer.mdx +1 -1
- package/reference/sdk/templates/pdf-generator.mdx +42 -24
- package/reference/sdk/templates/recurring-job.mdx +20 -15
- package/reference/sdk/templates/text-classifier.mdx +1 -1
- package/reference/sdk/templates/web-scraper.mdx +9 -5
- package/reference/ui/exports.mdx +1 -1
- package/reference/ui/index.mdx +2 -2
|
@@ -6,18 +6,19 @@ The helpers live here rather than in `@repo/ui` because they have three consumer
|
|
|
6
6
|
|
|
7
7
|
## Surface
|
|
8
8
|
|
|
9
|
-
| Export
|
|
10
|
-
|
|
|
11
|
-
| `ContentItemResponseSchema`, `CreateContentItemRequestSchema`, `UpdateContentItemRequestSchema`
|
|
12
|
-
| `ContentProcessingStateSchema`
|
|
13
|
-
| `ContentPayloadEnvelopeSchema`
|
|
14
|
-
| `ReviewContentItemRequestSchema`
|
|
15
|
-
| `ContentItemAttemptResponseSchema`, `CreateContentItemAttemptRequestSchema`
|
|
16
|
-
| `ContentDistributionResponseSchema`, `CreateContentDistributionRequestSchema`, `UpdateContentDistributionRequestSchema`
|
|
17
|
-
| `
|
|
18
|
-
| `
|
|
19
|
-
| `
|
|
20
|
-
| `
|
|
9
|
+
| Export | Purpose |
|
|
10
|
+
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
11
|
+
| `ContentItemResponseSchema`, `CreateContentItemRequestSchema`, `UpdateContentItemRequestSchema` | `content_items` transport shape. `processingState` is intentionally absent from create/update — factory-write-only. |
|
|
12
|
+
| `ContentProcessingStateSchema` | `{ stepKey: { status, data? } }`, keyed by `ContentStepKeySchema` — a content-specific key, not lead-gen's `LeadGenStageKeySchema`. |
|
|
13
|
+
| `ContentPayloadEnvelopeSchema` | The producer's immutable emission stored in `payload`. Never edited — `body` is the human's canonical text. |
|
|
14
|
+
| `ReviewContentItemRequestSchema` | Approve, or reject with a required `rejectReason`. Writes `reviewed_at` / `reviewed_by`. |
|
|
15
|
+
| `ContentItemAttemptResponseSchema`, `CreateContentItemAttemptRequestSchema` | `content_item_attempts` transport shape. No `attemptNumber` field on create — the API service assigns it inside the write. `stepKey` is producer-supplied and nullable. |
|
|
16
|
+
| `ContentDistributionResponseSchema`, `CreateContentDistributionRequestSchema`, `UpdateContentDistributionRequestSchema` | `content_distributions` transport shape, including the manual-publish fields (`publishMethod`, `platformPostId`, `platformUrl`). |
|
|
17
|
+
| `ContentItemSourceAssetResponseSchema`, `ContentItemSourceAssetInputSchema`, `UpdateContentItemSourceAssetRequestSchema`, `ReorderContentItemSourceAssetsRequestSchema`, `ContentAssetCropSchema` | `content_item_source_assets` transport shape — an item's ordered source assets, `position` 0 is the cover. `crop` is per-MEMBERSHIP normalized fractions, because the same photo crops differently in different items. The initial set rides `CreateContentItemRequestSchema.sourceAssets`; every later mutation is its own method, and `UpdateContentItemRequestSchema` deliberately never touches membership. `derivativePath` / `derivativeCrop` / `derivativeRenderedAt` carry the rendered crop: a stored JPEG in the `content-derivatives` bucket, so the cropped image exists as a file rather than only as CSS. Stale is derived — the two crops differ — never stored as a flag. |
|
|
18
|
+
| `PlatformContent`, `YouTubeContent`, `LinkedInContent`, `InstagramContent`, `XContent`, `AnyPlatformContent`, `PlatformContentMap`, `Platform` | Typed interfaces for platform-specific content stored in `content_distributions.platform_content`. |
|
|
19
|
+
| `isOpenContentReviewGate`, `getOpenContentReviewGates` | The one predicate deciding whether a `processing_state` entry is an open, unreviewed `queued` gate. Consumed by the `/queue` handler, `reviewItem`'s `stepKey` validation, and the review page. |
|
|
20
|
+
| `deriveContentBoard`, `ContentBoard`, `ContentBoardCard`, `ContentBoardColumn`, `ContentBoardGate` | Placement: `(items, pipeline, now)` to columns, gates, waiting counts, plus the `done` and `unplaced` buckets. Pure. Consumed by the Command Center board and `elevasis-sdk content:board`. |
|
|
21
|
+
| `getContentItemIdentity` | Names an item for display when `title` cannot — first non-blank line of `body`, then the first string payload field, then `title`, then `'Untitled'`. |
|
|
21
22
|
|
|
22
23
|
## Step catalog reconciliation
|
|
23
24
|
|
|
@@ -35,24 +35,27 @@ The model is versioned and currently validates against `version: 1`.
|
|
|
35
35
|
Top-level fields:
|
|
36
36
|
|
|
37
37
|
- `version`
|
|
38
|
+
- `snapshotHash`
|
|
38
39
|
- `domainMetadata`
|
|
39
40
|
- `branding`
|
|
40
41
|
- `navigation`
|
|
41
|
-
- `sales`
|
|
42
|
-
- `prospecting`
|
|
43
|
-
- `projects`
|
|
44
42
|
- `identity`
|
|
43
|
+
- `clients`
|
|
45
44
|
- `customers`
|
|
46
45
|
- `offerings`
|
|
47
46
|
- `roles`
|
|
48
47
|
- `goals`
|
|
49
48
|
- `systems`
|
|
49
|
+
- `ontology`
|
|
50
50
|
- `resources`
|
|
51
|
-
- `
|
|
52
|
-
- `
|
|
51
|
+
- `topology`
|
|
52
|
+
- `actions`
|
|
53
|
+
- `entities`
|
|
53
54
|
- `knowledge`
|
|
54
55
|
|
|
55
|
-
|
|
56
|
+
`sales`, `prospecting`, `projects`, `statuses`, and `policies` were removed from the top-level contract; do not author against them.
|
|
57
|
+
|
|
58
|
+
The pure collection domains are id-keyed maps: `systems`, `roles`, `goals`, `clients`, `customers`, `offerings`, `resources`, `actions`, `entities`, and `knowledge`. `ontology` is an `OntologyScope` object (not an id-keyed map at the top level) and `topology` is a relationships record. The map key must match the entry `id` for id-keyed domains. Entries carry `order` for deterministic ordered views; use `listDomain(record)` when order matters.
|
|
56
59
|
|
|
57
60
|
Resource identity is authored in `resources`. Runtime workflows, agents, integrations, and scripts import those descriptors, derive `resourceId` and kind from them, and attach executable behavior in operations code.
|
|
58
61
|
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Building the content System behind the shipped pipeline, item, and distribution routes -- which recipe to read, and the catalog vocabulary that is model-owned rather than coded
|
|
3
|
+
paths:
|
|
4
|
+
- ui/src/routes/content.tsx
|
|
5
|
+
- ui/src/routes/content/**
|
|
6
|
+
---
|
|
7
|
+
<!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
|
|
8
|
+
<!-- Regenerate: pnpm scaffold:sync -->
|
|
9
|
+
|
|
10
|
+
|
|
11
|
+
# Content
|
|
12
|
+
|
|
13
|
+
- **These routes render and do nothing until the System behind them is built.** Unlike CRM and lead-gen, `content` has no entry yet in `core/config/organization-model/systems.ts` -- the routes gate on `accessKey="content"` with no System, ontology, or resources behind it on a fresh project.
|
|
14
|
+
- **One recipe covers this surface and no other rule names it.** `extend-content.md` covers the System, its pipeline/step/status/pillar/platform catalogs, and the `content` workflow adapter. Read it before authoring.
|
|
15
|
+
- **A pipeline is data, not code.** Pipelines and their ordered steps are catalog records (`content:catalog/pipeline`, `content:catalog/{pipelineId}-steps`); adding one is an org-model edit plus one workflow per step, never a shared-UI or route change.
|
|
16
|
+
- **Pipeline, step, status, and pillar vocabulary is model-owned, never a local constant.** Copying catalog entries into a `const` is architecturally excluded -- every project owns its own model, so the copy rots silently. Read catalog entries from the resolved model.
|
|
17
|
+
- **`apiInterface` is adopt-only here.** Content uses the flat `system.apiInterface` marker on the `content` System path; readiness is derived from scoped resources, ontology bindings, and required catalogs -- never invent a readiness profile.
|
|
18
|
+
|
|
19
|
+
## Related Rules
|
|
20
|
+
|
|
21
|
+
- **organization-model.md** -- authoring the System, its ontology catalogs, and the resource descriptors
|
|
22
|
+
- **operations.md** -- registering the per-step workflows so they actually deploy
|
|
23
|
+
- **ui.md** -- the navigation and surface declarations these pages bind to
|
|
24
|
+
|
|
25
|
+
## References
|
|
26
|
+
|
|
27
|
+
- `operations/node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-content.md` -- the System, catalog model, and content workflow adapter build recipe
|
|
@@ -11,7 +11,7 @@ paths:
|
|
|
11
11
|
|
|
12
12
|
# Organization Model Edit Guide
|
|
13
13
|
|
|
14
|
-
`core/config/organization-model.ts` is the single source of truth for this project's organizational identity -- it encodes customers, offerings, roles, goals, Systems, ontology,
|
|
14
|
+
`core/config/organization-model.ts` is the single source of truth for this project's organizational identity -- it encodes customers, offerings, roles, goals, Systems, ontology, Knowledge, config, and Resources descriptors that agents, workflows, and the UI shell all consume at runtime. This rule owns the edit rules for that file; `organization-os.md` is the orientation and reference index around it.
|
|
15
15
|
|
|
16
16
|
New semantic authoring should start in system-colocated `ontology` scopes. Top-level `entities` and top-level `actions` remain compatibility mirrors while published consumers finish moving to compiled ontology indexes. `System.content` is retired.
|
|
17
17
|
|
|
@@ -53,7 +53,7 @@ Bare `/om` runs the layered flow (identity → customers → offerings → roles
|
|
|
53
53
|
- `System.config` owns system-local JSON settings and defaults.
|
|
54
54
|
- `resources` own executable workflow/agent descriptors, `systemPath`, owners, governance status, code references, and runtime implementation links. Resource identity is authored once in the id-keyed `resources` map; operations imports those descriptors and derives runtime `resourceId` / `type` while assembling the `DeploymentSpec`.
|
|
55
55
|
- `resource.ontology.actions` describes the ontology actions a Resource performs, `resource.ontology.primaryAction` names the default/selectable action when a Resource has one, and `resource.ontology` also describes reads, writes, catalog use, and emitted events.
|
|
56
|
-
- `topology.relationships` owns durable operational wiring between Systems, Resources, ontology nodes,
|
|
56
|
+
- `topology.relationships` owns durable operational wiring between Systems, Resources, ontology nodes, roles, triggers, checkpoints, and external resources. Keep credential values, provider webhook mechanics, deployment environment settings, execution logs, and per-run scheduler state outside the OM.
|
|
57
57
|
- `knowledge` owns long-form playbooks, strategies, references, and governance context.
|
|
58
58
|
- Top-level `entities` and top-level `actions` are compatibility mirrors only. Keep them aligned when current published consumers still need them, rather than inventing a separate source of truth, but do not treat them as the primary authoring surface.
|
|
59
59
|
|
|
@@ -63,7 +63,13 @@ Do not add `sales.actions` to the org model -- the v1 server-side override surfa
|
|
|
63
63
|
|
|
64
64
|
## `System.apiInterface`
|
|
65
65
|
|
|
66
|
-
`System.apiInterface` is an adopt-only marker for platform-provided API capabilities, with derived readiness requirements. Use only cataloged profiles from `scaffold/reference/system-interface-capabilities.md`, on their convention-locked System paths
|
|
66
|
+
`System.apiInterface` is an adopt-only marker for platform-provided API capabilities, with derived readiness requirements. Use only cataloged profiles from `scaffold/reference/system-interface-capabilities.md`, on their convention-locked System paths -- `sales.lead-gen`, `sales.crm`, and `content`. Satisfy readiness through ontology/resources/catalogs/topology authoring. A System that adopts no cataloged capability does not declare `apiInterface` and must not invent a readiness profile; route that behavior through workflows/operations and the OM layers this project owns.
|
|
67
|
+
|
|
68
|
+
**Why the catalog is closed, and why that is not a ceiling.** A `readinessProfile` is not a label you choose -- it names a capability the platform API actually gates a route on, so only the platform can mint one. `SystemInterfaceReadinessProfileSchema` accepts any non-empty string, but that permissiveness lives at the schema layer and is not a statement that any id is meaningful: an uncataloged id names no route, so the System computes as **ready** and every call still fails. That is strictly worse than a missing marker, which at least reports `missing-interface`. If your project needs an API capability that is not cataloged, that is a platform request -- adding a route and a catalog entry -- not something to work around locally by inventing an id.
|
|
69
|
+
|
|
70
|
+
**Adopting `content`.** `content.api` gates every `/api/content/*` and `/api/external/content/*` route. It is cataloged and adoptable, and unlike the three `sales.*` profiles it is **contract-validated**: its structural requirements differ per project (each declares its own pipeline step catalog), so a System adopting it MUST declare a `readinessContract` alongside it. Omitting the contract produces `missing-readiness-contract` at deploy preflight.
|
|
71
|
+
|
|
72
|
+
`registerBuiltInReadinessProfile` is **not** available to you as an extension point, despite what older guidance said. It mutates an in-process registry, and the readiness assertion that gates the API runs in the API process -- a registration made from your worker is never seen by it. `readinessContract` is your route to structural readiness.
|
|
67
73
|
|
|
68
74
|
A System with no `apiInterface` is the designed opt-out for a capability this project does not use. That absence is silent by construction and is NOT a defect -- never "fix" it by adding a marker. The anomaly is a stub marker with `resourceIds: []`, which the deploy gate rejects.
|
|
69
75
|
|
|
@@ -7,7 +7,7 @@ description: Organization OS orientation -- what the semantic contract layer is,
|
|
|
7
7
|
|
|
8
8
|
# Organization OS
|
|
9
9
|
|
|
10
|
-
Organization OS is the semantic contract layer defining how organizations, Systems, Actions, ontology, resources,
|
|
10
|
+
Organization OS is the semantic contract layer defining how organizations, Systems, Actions, ontology, resources, roles, goals, knowledge, and runtime surfaces relate. This project consumes it through published `@elevasis/core` / `@elevasis/sdk` configuration and does not maintain the upstream schema.
|
|
11
11
|
|
|
12
12
|
**This rule is orientation and an index only.** The concrete edit rules -- the `/om` ceremony and its gates, `System.apiInterface` versus ontology `interface` records, resource identity and `systemPath` attachment, the ontology/config/knowledge authoring boundary, and validation -- live in `organization-model.md`. Read that rule before changing anything under `core/config/`; never author org-model changes from this rule alone.
|
|
13
13
|
|
|
@@ -26,7 +26,7 @@ Organization OS is the semantic contract layer defining how organizations, Syste
|
|
|
26
26
|
|
|
27
27
|
- **Platform configuration:** `systems`, `branding`, `navigation`
|
|
28
28
|
- **Organizational reality:** `identity`, `customers`, `offerings`, `roles`, `goals`
|
|
29
|
-
- **Governance:** `resources
|
|
29
|
+
- **Governance:** `resources` and resource-to-System relationships
|
|
30
30
|
- **Ontology, config, and knowledge:** `System.ontology` owns durable semantic contracts (object types, action types, catalog types, link types, event types, interfaces, surfaces). `System.config` owns system-local JSON settings and defaults. `knowledge` is a flat id-keyed map of playbooks, strategies, and references that explain or govern systems and ontology records.
|
|
31
31
|
|
|
32
32
|
`System.apiInterface` is a flat, adopt-only System field marking a platform-provided API capability -- not an ontology record and not a general extension point. Its authoring rules, readiness requirements, and opt-out semantics are owned by `organization-model.md`.
|
package/reference/rules/ui.md
CHANGED
|
@@ -295,7 +295,7 @@ For CRM deal action buttons, read `operations/node_modules/@elevasis/sdk/referen
|
|
|
295
295
|
|
|
296
296
|
## Topbar Actions
|
|
297
297
|
|
|
298
|
-
`navigation.topbar` is the organization-model region for topbar action items. Topbar actions are a **distinct node type**, not navigation surfaces: they trigger behavior (open a modal, open docs) rather than route somewhere, so they have no `path` and no nesting, and the `surfaceType` enum (`page | dashboard | list | detail | graph | settings`) does not apply to them. Like sidebar surfaces, they are toggled and reordered
|
|
298
|
+
`navigation.topbar` is the organization-model region for topbar action items. Topbar actions are a **distinct node type**, not navigation surfaces: they trigger behavior (open a modal, open docs) rather than route somewhere, so they have no `path` and no nesting, and the `surfaceType` enum (`page | dashboard | list | detail | graph | settings`) does not apply to them. Like sidebar surfaces, they are toggled and reordered by editing the navigation config below -- topbar actions carry an `enabled` flag, and ordering follows authored order.
|
|
299
299
|
|
|
300
300
|
Author them in `core/config/organization-model/navigation.ts`, keyed by action id:
|
|
301
301
|
|
|
@@ -33,7 +33,7 @@ The user wants to record something new -- a task, a note, a piece of information
|
|
|
33
33
|
| "Track this conversation as a deal note" | Explicit "track" with a described artifact |
|
|
34
34
|
| "Note for myself: the client prefers morning calls" | "Note for myself" = personal note to persist |
|
|
35
35
|
|
|
36
|
-
**Agent action:** draft the capture in plain language, confirm with the user, then execute via `elevasis-sdk project:*` commands for project records, `elevasis-sdk note:create` for personal user notes (the Command Center right panel),
|
|
36
|
+
**Agent action:** draft the capture in plain language, confirm with the user, then execute via `elevasis-sdk project:*` commands for project records, `elevasis-sdk note:create` for personal user notes (the Command Center right panel), `elevasis-sdk schedule:create` for recurring automation, or `elevasis-sdk content:source-asset:create` for a new content source asset (a reusable input the content pipeline draws from -- a brand doc, a reference file, raw material). Disambiguate note scope: a note tied to a deal/task/project is `project:note:create` (a `project:*` record); a standalone personal note is `note:create`. Use repetition vocabulary ("every", "daily", "weekly", "monthly") for schedules; one-shot future reminders stay project tasks with due dates. Never write without confirmation.
|
|
37
37
|
|
|
38
38
|
### 2. Query
|
|
39
39
|
|
|
@@ -43,14 +43,15 @@ The user wants to know something about current state -- task priorities, what is
|
|
|
43
43
|
|
|
44
44
|
**Fixture examples:**
|
|
45
45
|
|
|
46
|
-
| Input | Why it's Query
|
|
47
|
-
| -------------------------------------------- |
|
|
48
|
-
| "What should I work on next?" | Asking for prioritized task list
|
|
49
|
-
| "What's pending in the HITL queue?" | Runtime-entity query about operations state
|
|
50
|
-
| "What runs this week?" | Runtime query about upcoming schedules
|
|
51
|
-
| "What systems are enabled for this project?" | Static-model query about Systems config
|
|
46
|
+
| Input | Why it's Query |
|
|
47
|
+
| -------------------------------------------- | ---------------------------------------------------- |
|
|
48
|
+
| "What should I work on next?" | Asking for prioritized task list |
|
|
49
|
+
| "What's pending in the HITL queue?" | Runtime-entity query about operations state |
|
|
50
|
+
| "What runs this week?" | Runtime query about upcoming schedules |
|
|
51
|
+
| "What systems are enabled for this project?" | Static-model query about Systems config |
|
|
52
|
+
| "What's waiting on review?" | Runtime-entity query about content review-gate state |
|
|
52
53
|
|
|
53
|
-
**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,
|
|
54
|
+
**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, `elevasis-sdk schedule:list --status active --pretty` for upcoming recurring automation, and for the content platform: `elevasis-sdk content:queue --pretty` (open review gates), `content:list --pretty` (item overview), `content:board <pipelineId> --pretty` (pipeline state), `content:get <itemId> --pretty` (one item's attempt/distribution history), `content:source-assets --pretty` (list available source assets), or `content:source-asset <id> --pretty` (one source asset's detail). No writes.
|
|
54
55
|
|
|
55
56
|
### 3. Describe
|
|
56
57
|
|
|
@@ -73,7 +74,7 @@ bucket, catalog entry, progress step, pipeline column, or similarly closed busin
|
|
|
73
74
|
also show the cross-system impact before the normal description:
|
|
74
75
|
|
|
75
76
|
1. Read `operations/node_modules/@elevasis/sdk/reference/spine/spine-primer.md` for the layering pattern.
|
|
76
|
-
2. Read the relevant domain in `core/config/organization-model.ts
|
|
77
|
+
2. Read the relevant domain in `core/config/organization-model/` -- `profile.ts` for identity/customer/offering domains, `systems.ts` for Systems/ontology/resource domains (or `core/config/organization-model.ts` in unsplit projects).
|
|
77
78
|
3. Explain the impact in vibe-coder language only: the business profile entry, the saved progress
|
|
78
79
|
on each record, the automations that produce updates, and the dashboard or reports that read it.
|
|
79
80
|
4. Route follow-up changes through `/om <domain>`. Do not mention the technical pattern name
|
|
@@ -94,8 +95,9 @@ The user wants to change the status of a task or entity.
|
|
|
94
95
|
| "Mark the onboarding task as complete" | Explicit status-change vocabulary |
|
|
95
96
|
| "Approve the pending checkpoint" | Selects an action from the HITL queue |
|
|
96
97
|
| "Pause the Friday report" | Changes schedule state |
|
|
98
|
+
| "Approve this post" | Clears a named content review gate |
|
|
97
99
|
|
|
98
|
-
**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>`,
|
|
100
|
+
**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>`, `schedule:cancel <id>`, or `elevasis-sdk content:review <itemId> --step <key> (--approve | --reject) --user <email>` as appropriate. `content:review` always requires resolving the exact `stepKey` from `content:queue` first and confirming the item/decision before executing -- never guess `--step`. Never auto-transition without confirmation if the target entity is ambiguous.
|
|
99
101
|
|
|
100
102
|
### 5. Navigate
|
|
101
103
|
|
|
@@ -145,7 +147,7 @@ change and does not expose commands that only exist inside the Elevasis platform
|
|
|
145
147
|
|
|
146
148
|
This routing applies to both codify levels:
|
|
147
149
|
|
|
148
|
-
- **Level A** (config-only edits to `organization-model.ts
|
|
150
|
+
- **Level A** (config-only edits to `organization-model/systems.ts` -- or `organization-model.ts` in unsplit projects -- System availability/routing toggles, label renames): delegate to `/om <domain>` immediately.
|
|
149
151
|
- **Level B** (new Zod extension files in `core/config/extensions/`): also delegate to `/om <domain>`; `/om` gates Level B to explicit user asks before scaffolding a new TS file.
|
|
150
152
|
|
|
151
153
|
Vibe detects the intent and delegates in both cases. It does not run either pipeline itself.
|
|
@@ -156,6 +158,8 @@ For "build/extend lead gen" / "campaign creator" / "outbound list state" asks, c
|
|
|
156
158
|
|
|
157
159
|
For "add a custom CRM action" / "Send Quote button" asks, classify as Codify, then read `operations/node_modules/@elevasis/sdk/reference/scaffold/recipes/customize-crm-actions.md` before editing. 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.
|
|
158
160
|
|
|
161
|
+
For "build/extend content" / "add a content pipeline" / "content review screen" asks, classify the structural org-model portion as Codify, then read `operations/node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-content.md` before editing. A content pipeline is a catalog record, not code -- content work often spans org-model pipeline/step/status/pillar catalogs, the `content` workflow adapter, shared review-page composition, and distribution tracking; do not reduce it to only catalog config or only UI.
|
|
162
|
+
|
|
159
163
|
Heuristics for when to propose codification (passed to `/om` as context):
|
|
160
164
|
|
|
161
165
|
- First mention of a new attribute: note to `resume_context`, do not propose yet
|
|
@@ -177,9 +181,9 @@ The user wants to enable or disable a System.
|
|
|
177
181
|
| "Disable monitoring for now" | "Disable" + System reference |
|
|
178
182
|
| "We don't use SEO, turn it off" | Declarative + "turn it off" = System disable |
|
|
179
183
|
|
|
180
|
-
**Agent action:** delegate to `/om systems`. The ceremony (confirm + edit `core/config/organization-model.ts` + typecheck) belongs to `/om`, not to the ambient rule.
|
|
184
|
+
**Agent action:** delegate to `/om systems`. The ceremony (confirm + edit `core/config/organization-model/systems.ts` -- or `core/config/organization-model.ts` in unsplit projects -- + typecheck) belongs to `/om`, not to the ambient rule.
|
|
181
185
|
|
|
182
|
-
**Tenant-local only.** Toggle operates on this project's own `core/config/organization-model.ts` — the project's own Systems. The Elevasis platform's own Systems are not in scope; this project cannot toggle them and vibe must not pretend it can. If a user names a platform-only System, surface the boundary in plain language rather than attempting a toggle.
|
|
186
|
+
**Tenant-local only.** Toggle operates on this project's own `core/config/organization-model/systems.ts` (or `core/config/organization-model.ts` in unsplit projects) — the project's own Systems. The Elevasis platform's own Systems are not in scope; this project cannot toggle them and vibe must not pretend it can. If a user names a platform-only System, surface the boundary in plain language rather than attempting a toggle.
|
|
183
187
|
|
|
184
188
|
### 8. Operate
|
|
185
189
|
|
|
@@ -235,8 +239,6 @@ The threshold controls how aggressively the classifier proposes codification fro
|
|
|
235
239
|
- `balanced` -- second mention OR explicit declaration triggers; default
|
|
236
240
|
- `loose` -- first strong signal triggers a proposal
|
|
237
241
|
|
|
238
|
-
Override per project in `core/config/organization-model.ts` under `vibe.classifierThreshold`. The override is merge-aware and will not be overwritten by template sync operations.
|
|
239
|
-
|
|
240
242
|
## Phase-1 Scope
|
|
241
243
|
|
|
242
244
|
This rule covers Phase 1 of the vibe layer rollout. The layers the ambient classifier can narrate and codify in Phase 1 are:
|
|
@@ -268,4 +270,5 @@ Layers 2 (Public API), 3 (UI Shell Runtime), 5 (Toolkit), and 6 (Graph) require
|
|
|
268
270
|
- `operations/node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-crm.md` -- CRM build/extend scope
|
|
269
271
|
- `operations/node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md` -- lead-gen build/extend scope
|
|
270
272
|
- `operations/node_modules/@elevasis/sdk/reference/scaffold/recipes/customize-crm-actions.md` -- custom CRM action keys and the `crmActions` provider
|
|
271
|
-
- `
|
|
273
|
+
- `operations/node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-content.md` -- content build/extend scope
|
|
274
|
+
- `core/config/organization-model/systems.ts` -- label vocabulary and System availability (or `core/config/organization-model.ts` in unsplit projects)
|
package/reference/rules/vibe.md
CHANGED
|
@@ -13,16 +13,16 @@ Vibe is **ambient and always on**. Every natural-language message is silently cl
|
|
|
13
13
|
|
|
14
14
|
## Quick Reference Table
|
|
15
15
|
|
|
16
|
-
| Intent | Trigger signal
|
|
17
|
-
| ---------- |
|
|
18
|
-
| Capture | "add", "remember", "track", "log", "note for myself" + a thing
|
|
19
|
-
| Query | "what's next", "what's pending", "what failed", "what systems"
|
|
20
|
-
| Describe | "what is", "tell me about", "explain", "where am I"
|
|
21
|
-
| Transition | "done", "stuck", "blocked", "finished", "complete", "approve", "pause"
|
|
22
|
-
| Navigate | "focus on", "switch to", "back to", "look at"
|
|
23
|
-
| Codify | "we are X", "we track Y", repeated attribute, "add type/field"
|
|
24
|
-
| Toggle | "enable", "disable", "turn on/off" + system
|
|
25
|
-
| Operate | "run", "execute", "launch", "trigger", "kick off", "start" + deployed resource
|
|
16
|
+
| Intent | Trigger signal | Routed to |
|
|
17
|
+
| ---------- | ------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------- |
|
|
18
|
+
| Capture | "add", "remember", "track", "log", "note for myself" + a thing | Agent -- draft + confirm + `project:*`, `note:create`, `schedule:create`, or `content:source-asset:create` CLI |
|
|
19
|
+
| Query | "what's next", "what's pending", "what failed", "what systems", "what's waiting on review" | Agent -- read with `project:*`, `queue:*`, `schedule:*`, or `content:*` + narrate |
|
|
20
|
+
| Describe | "what is", "tell me about", "explain", "where am I" | Agent -- narrate from org model labels |
|
|
21
|
+
| Transition | "done", "stuck", "blocked", "finished", "complete", "approve", "pause" | Agent -- confirm + `project:task:save`, `queue:select`, `schedule:*`, or `content:review` |
|
|
22
|
+
| Navigate | "focus on", "switch to", "back to", "look at" | Agent -- update scope + narrate |
|
|
23
|
+
| Codify | "we are X", "we track Y", repeated attribute, "add type/field" | Delegate to `/om \<domain>` |
|
|
24
|
+
| Toggle | "enable", "disable", "turn on/off" + system | Delegate to `/om systems` (tenant-local only) |
|
|
25
|
+
| Operate | "run", "execute", "launch", "trigger", "kick off", "start" + deployed resource | Delegate to `/elevasis` -- `elevasis-sdk describe` + confirm + `elevasis-sdk exec` |
|
|
26
26
|
|
|
27
27
|
## Safety Boundaries
|
|
28
28
|
|
|
@@ -30,10 +30,30 @@ Vibe is **ambient and always on**. Every natural-language message is silently cl
|
|
|
30
30
|
- **Never auto-execute a deployed resource.** Operate runs `elevasis-sdk describe` first, drafts the payload, confirms, then runs `exec`. It never deploys, never creates, never edits workflow source.
|
|
31
31
|
- **Never write the model yourself.** Codify and Toggle detect intent and delegate to `/om <domain>`; the draft-confirm-write-typecheck ceremony belongs to `/om`.
|
|
32
32
|
- **Never flip public agent exposure.** Making a deployed agent reachable on the public internet (the `agent_access_grants` row behind `/public/agents/:slug`, managed via `grant:create` / `grant:update` / `grant:disable` or the Resource-page public/private toggle) is a security boundary deliberately kept out of ambient routing -- a non-technical user describing their business must never expose an agent by accident. Do NOT classify "make my agent public" / "put the interview online" as Toggle, and do NOT auto-execute. Surface the `grant:*` CLI or the Resource-page toggle in plain language and require explicit confirmation.
|
|
33
|
-
- **Toggle is tenant-local.** It edits this project's own `core/config/organization-model.ts` only. The Elevasis platform's own Systems cannot be toggled from here; surface that boundary rather than attempting it.
|
|
33
|
+
- **Toggle is tenant-local.** It edits this project's own Systems config -- `core/config/organization-model/systems.ts`, or `core/config/organization-model.ts` in unsplit projects -- only. The Elevasis platform's own Systems cannot be toggled from here; surface that boundary rather than attempting it.
|
|
34
34
|
- **Never guess an ambiguous intent.** Ask one neutral clarifying question presenting the plausible intents. Do not apply a precedence rule and do not route to the "closest" match.
|
|
35
35
|
- **Never invent vocabulary.** Status, entity, and layer names come from the model's inline `label` fields, read verbatim -- never hardcoded synonyms.
|
|
36
36
|
|
|
37
|
+
## Deliberate Non-Routes
|
|
38
|
+
|
|
39
|
+
Not every registered CLI command gets a vibe route. `request:*` (`request:submit`, `request:list`,
|
|
40
|
+
`request:get`, `request:update`, `request:delete`) is deliberately absent from the classifier --
|
|
41
|
+
this is a decision, not an oversight. Escalation to the platform is skill-driven via
|
|
42
|
+
`submit-request`, and ambient routing of a write into the platform's inbound queue is a different
|
|
43
|
+
risk class from a route like `content:review`: a misclassified message would file a request on the
|
|
44
|
+
user's behalf with no confirmation ceremony designed for that specific write. If a future sweep
|
|
45
|
+
finds `request:` absent from this classifier corpus, that absence is this decision holding, not a
|
|
46
|
+
gap to close.
|
|
47
|
+
|
|
48
|
+
## Keeping the Classifier Current
|
|
49
|
+
|
|
50
|
+
Nothing today keeps this file and `vibe-intents.md` in step with new `elevasis-sdk` commands as
|
|
51
|
+
they ship -- a new command reaches the CLI with no gate that requires a matching classifier entry,
|
|
52
|
+
which is why `content:source-asset*` shipped in `@elevasis/sdk@1.48.0` with zero classifier hits
|
|
53
|
+
until this fix. Until an automated check exists, treat "does this new command need a vibe route"
|
|
54
|
+
as a required question on every CLI-surface change, the same way a new System's scaffold recipe is
|
|
55
|
+
a required question on every System-shaping change.
|
|
56
|
+
|
|
37
57
|
## Related Rules
|
|
38
58
|
|
|
39
59
|
- **vibe-intents.md** -- the detail body; open it when a message is hard to classify or a route needs its exact ceremony
|
|
@@ -44,4 +64,4 @@ Vibe is **ambient and always on**. Every natural-language message is silently cl
|
|
|
44
64
|
## References
|
|
45
65
|
|
|
46
66
|
- `operations/node_modules/@elevasis/sdk/reference/rules/vibe-intents.md` -- per-intent recognition signals, fixture examples, exact agent actions, stage/state sub-routing, the classifier threshold, and phase scope
|
|
47
|
-
- `core/config/organization-model.ts` -- label vocabulary
|
|
67
|
+
- `core/config/organization-model/systems.ts` -- label vocabulary and System availability (or `core/config/organization-model.ts` in unsplit projects)
|
|
@@ -94,7 +94,7 @@ Use ontology `linkTypes` when the object has durable relationships to other mode
|
|
|
94
94
|
|
|
95
95
|
## 3. Add Ontology Action Types for Stable Business Verbs
|
|
96
96
|
|
|
97
|
-
Add ontology action types for verbs that operators,
|
|
97
|
+
Add ontology action types for verbs that operators, Command View, or agents should reason about.
|
|
98
98
|
|
|
99
99
|
<!-- doc-snippet:skip: illustrative excerpt, not a standalone compilable file -->
|
|
100
100
|
|
|
@@ -100,7 +100,7 @@ System field reference:
|
|
|
100
100
|
- `lifecycle` -- draft, beta, active, deprecated, or archived.
|
|
101
101
|
- `ui` -- optional route metadata used by shell matching during migration.
|
|
102
102
|
- `requiresAdmin` -- hides the node for non-admin members; descendants inherit it.
|
|
103
|
-
- `actions`
|
|
103
|
+
- `actions` -- references to the cross-cutting actions domain.
|
|
104
104
|
- `ontology` -- System-owned object, link, action, catalog, event, surface, interface, value-type, property, or group records.
|
|
105
105
|
- `config` -- JSON-serializable settings local to this System.
|
|
106
106
|
- `systems` -- nested child Systems. Use this for new recursive authoring; `subsystems` is a compatibility alias only.
|
|
@@ -303,7 +303,7 @@ systems: {
|
|
|
303
303
|
|
|
304
304
|
Keep `semanticClass` values stable; platform analytics and triggers depend on them.
|
|
305
305
|
|
|
306
|
-
|
|
306
|
+
Role integration remains outside ontology in this pass. Use `roles`, `responsibleRoleId`, and `ownerRoleId` for accountability and access semantics until a dedicated role ontology design is published.
|
|
307
307
|
|
|
308
308
|
## Export Pattern
|
|
309
309
|
|