@elevasis/sdk 1.48.0 → 1.50.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/chunk-MGZZ4HL4.js +4399 -0
- package/dist/chunk-VYWGWJRW.js +130 -0
- package/dist/chunk-YJDXRHNP.js +7901 -0
- package/dist/cli.cjs +949 -281
- package/dist/index.d.ts +1031 -48
- package/dist/index.js +2 -7597
- package/dist/node/index.d.ts +3 -3675
- package/dist/node/index.js +2 -124
- package/dist/test-utils/index.d.ts +2 -12051
- package/dist/test-utils/index.js +113 -27891
- package/dist/worker/index.d.ts +548 -12264
- package/dist/worker/index.js +3 -7400
- package/package.json +12 -4
- package/reference/_navigation.md +4 -4
- package/reference/_reference-manifest.json +1 -1
- 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 +16 -12
- package/reference/rules/agent-start-here.md +1 -1
- package/reference/rules/frontend.md +3 -1
- package/reference/rules/package-taxonomy.md +7 -5
- package/reference/rules/ui.md +31 -5
- package/reference/rules/vibe-intents.md +2 -2
- package/reference/rules/vibe.md +30 -10
- package/reference/scaffold/recipes/extend-content.md +82 -3
- package/reference/scaffold/recipes/gate-by-feature-or-admin.md +8 -6
- package/reference/scaffold/ui/feature-flags-and-gating.md +11 -1
- package/reference/sdk/cli-management.mdx +284 -139
- package/reference/sdk/cli.mdx +136 -88
- package/reference/sdk/define-builders.mdx +1 -1
- package/reference/sdk/deployment/command-center.mdx +2 -2
- package/reference/sdk/deployment/index.mdx +24 -7
- 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 +1 -1
- 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/sdk/troubleshooting.mdx +72 -1
- package/reference/ui/exports.mdx +1 -1
- package/reference/ui/index.mdx +2 -2
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@elevasis/sdk",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.50.0",
|
|
4
4
|
"description": "SDK for building Elevasis organization resources",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
@@ -32,6 +32,7 @@
|
|
|
32
32
|
"dist/test-utils/index.js",
|
|
33
33
|
"dist/test-utils/index.d.ts",
|
|
34
34
|
"dist/node/",
|
|
35
|
+
"dist/chunk-*.js",
|
|
35
36
|
"dist/cli.cjs",
|
|
36
37
|
"reference/"
|
|
37
38
|
],
|
|
@@ -41,8 +42,14 @@
|
|
|
41
42
|
"remark-gfm": "^4.0.1"
|
|
42
43
|
},
|
|
43
44
|
"peerDependencies": {
|
|
45
|
+
"vitest": ">=3",
|
|
44
46
|
"zod": "^4.1.0"
|
|
45
47
|
},
|
|
48
|
+
"peerDependenciesMeta": {
|
|
49
|
+
"vitest": {
|
|
50
|
+
"optional": true
|
|
51
|
+
}
|
|
52
|
+
},
|
|
46
53
|
"devDependencies": {
|
|
47
54
|
"@types/node": "^22.0.0",
|
|
48
55
|
"chalk": "^5.3.0",
|
|
@@ -54,10 +61,11 @@
|
|
|
54
61
|
"rollup-plugin-dts": "^6.3.0",
|
|
55
62
|
"tsup": "^8.0.0",
|
|
56
63
|
"typescript": "5.9.2",
|
|
64
|
+
"vitest": "^3.2.4",
|
|
57
65
|
"zod": "^4.1.0",
|
|
58
|
-
"@repo/core": "0.
|
|
59
|
-
"@repo/
|
|
60
|
-
"@repo/
|
|
66
|
+
"@repo/core": "0.65.0",
|
|
67
|
+
"@repo/eslint-config": "0.0.0",
|
|
68
|
+
"@repo/typescript-config": "0.0.0"
|
|
61
69
|
},
|
|
62
70
|
"scripts": {
|
|
63
71
|
"lint": "eslint src --max-warnings 0",
|
package/reference/_navigation.md
CHANGED
|
@@ -162,7 +162,7 @@ Package entries indexed: 64.
|
|
|
162
162
|
| --- | --- | --- | --- |
|
|
163
163
|
| Theme | `packages/ui/src/theme/README.md` | Published theme entry for downstream applications. | (not specified) |
|
|
164
164
|
| Graph | `packages/ui/src/graph/README.md` | Published graph helper and visualization entry. | (not specified) |
|
|
165
|
-
| Theme Presets | `packages/ui/src/theme/presets/README.md` |
|
|
165
|
+
| Theme Presets | `packages/ui/src/theme/presets/README.md` | Published THEME_PRESETS tuple, ThemePresetName union, and ThemePresetEnum Zod enum, defined locally and kept manually aligned with the canonical list in packages/core/src/auth/multi-tenancy/theme-presets.ts. | (not specified) |
|
|
166
166
|
| Knowledge | `packages/ui/src/knowledge/README.md` | Published knowledge browser primitives: Browser, Tree, NodeList, NodeView, SearchBar, MDX provider, and the generated KNOWLEDGE_BODIES map. | (not specified) |
|
|
167
167
|
|
|
168
168
|
---
|
|
@@ -281,7 +281,7 @@ Docs-site pages indexed: 38.
|
|
|
281
281
|
|
|
282
282
|
| Page | Location | Description |
|
|
283
283
|
| --- | --- | --- |
|
|
284
|
-
| CLI Management Commands | `sdk/cli-management.mdx` | elevasis-sdk management commands -- project, note, acquisition, client, agent, session, queue, schedule, om, ui, skill, and
|
|
284
|
+
| CLI Management Commands | `sdk/cli-management.mdx` | elevasis-sdk management commands -- project, note, acquisition, client, agent, session, queue, schedule, om, ui, skill, content, and grant subcommand families |
|
|
285
285
|
| CLI Reference | `sdk/cli.mdx` | Core elevasis-sdk CLI commands -- validate, deploy, execute, inspect resources, manage credentials, rename, and enumerate the command catalog |
|
|
286
286
|
| Concepts Reference | `sdk/concepts.mdx` | Plain-English explanations of Elevasis SDK concepts -- glossary, workflow analogies, Zod schemas, execution model, platform tools, and design decisions |
|
|
287
287
|
| When to Reach for the define* Builders | `sdk/define-builders.mdx` | defineWorkflow, defineStep, defineContract, defineResource, and defineTopology exist for two different reasons -- this page teaches which reason applies before you pick a builder over a plain object literal. |
|
|
@@ -295,7 +295,7 @@ Docs-site pages indexed: 38.
|
|
|
295
295
|
| Tutorial System | `sdk/framework/tutorial-system.mdx` | The /tutorial skill in the external project scaffold -- two-track onboarding (vibe-coder and technical), gate question, track persistence, and escape hatch |
|
|
296
296
|
| Getting Started | `sdk/getting-started.mdx` | Set up your Elevasis SDK project and run your first deployment |
|
|
297
297
|
| Human-in-the-Loop (HITL) Workflows | `sdk/human-in-the-loop.mdx` | How a workflow step opens an approval task, how it reaches the command queue, and how selecting an action resumes work -- the story that connects the approval adapter, checkpoint metadata, and the queue CLI. |
|
|
298
|
-
|
|
|
298
|
+
| @elevasis/sdk | `sdk/index.mdx` | Build and deploy workflows, agents, and resources with the Elevasis SDK |
|
|
299
299
|
| Integration Adapters | `sdk/platform-tools/adapters-integration.mdx` | Auto-generated table of all 13 integration (credential-bound) adapters exported from @elevasis/sdk/worker, derived from static analysis of the adapter source files. |
|
|
300
300
|
| Platform Adapters | `sdk/platform-tools/adapters-platform.mdx` | Auto-generated table of all 14 platform (singleton, no credential) adapters exported from @elevasis/sdk/worker, derived from static analysis of the adapter source files. |
|
|
301
301
|
| Platform Tools | `sdk/platform-tools/index.mdx` | Access 25 adapters (13 integration + 12 platform) from your SDK workflows -- typed adapters, credential security model, and working code examples |
|
|
@@ -309,7 +309,7 @@ Docs-site pages indexed: 38.
|
|
|
309
309
|
| Template: Email Sender | `sdk/templates/email-sender.mdx` | Transactional email via Resend with template support -- send styled emails to one or multiple recipients |
|
|
310
310
|
| Templates | `sdk/templates/index.mdx` | Ready-to-use workflow templates for common automation patterns -- web scraping, data enrichment, email sending, lead scoring, PDF generation, text classification, and recurring jobs |
|
|
311
311
|
| Template: Lead Scorer | `sdk/templates/lead-scorer.mdx` | LLM-based lead scoring with Supabase storage -- receive a lead, score it with an LLM, store the result |
|
|
312
|
-
| Template: PDF Generator | `sdk/templates/pdf-generator.mdx` | PDF generation from structured data with platform storage upload -- render a PDF from
|
|
312
|
+
| Template: PDF Generator | `sdk/templates/pdf-generator.mdx` | PDF generation from structured data with platform storage upload -- render a PDF from typed content blocks and upload to platform storage |
|
|
313
313
|
| Template: Recurring Job | `sdk/templates/recurring-job.mdx` | Scheduler-triggered periodic workflow -- run a task on a schedule (daily, weekly, hourly, or custom cron) |
|
|
314
314
|
| Template: Text Classifier | `sdk/templates/text-classifier.mdx` | Multi-label text classification with structured output -- classify text into predefined categories using an LLM with JSON output |
|
|
315
315
|
| Template: Web Scraper | `sdk/templates/web-scraper.mdx` | Apify-based web scraper that stores results in Supabase -- fetch structured data from any website via Apify actors |
|
|
@@ -875,7 +875,7 @@
|
|
|
875
875
|
"subpath": "./theme/presets",
|
|
876
876
|
"kind": "subpath",
|
|
877
877
|
"title": "Theme Presets",
|
|
878
|
-
"description": "
|
|
878
|
+
"description": "Published THEME_PRESETS tuple, ThemePresetName union, and ThemePresetEnum Zod enum, defined locally and kept manually aligned with the canonical list in packages/core/src/auth/multi-tenancy/theme-presets.ts.",
|
|
879
879
|
"group": "Visual",
|
|
880
880
|
"order": 2,
|
|
881
881
|
"sourcePath": "packages/ui/src/theme/presets/index.ts",
|
package/reference/core/index.mdx
CHANGED
|
@@ -15,11 +15,13 @@ The default export and most subpaths are browser-safe. No Node.js-specific runti
|
|
|
15
15
|
|
|
16
16
|
## Published Subpaths
|
|
17
17
|
|
|
18
|
-
`@elevasis/core` ships
|
|
18
|
+
`@elevasis/core` ships eight published subpaths:
|
|
19
19
|
|
|
20
20
|
- **`.`** (default) -- base schemas, shared utilities, and the root contract surface. Browser-safe.
|
|
21
21
|
- **`./auth`** -- auth contract types: session shapes, membership, role definitions, and WorkOS integration contracts.
|
|
22
22
|
- **`./organization-model`** -- the organization model (OM) schema: system definitions, resource metadata, and the org-model graph types used by the platform's AI routing layer.
|
|
23
|
+
- **`./organization-model/readiness`** -- readiness profiles and the system-interface readiness contract used to gate a System's API surface.
|
|
24
|
+
- **`./content`** -- content pipeline schemas: items, distributions, pipeline step contracts, and review-gate types.
|
|
23
25
|
- **`./entities`** -- entity schemas: typed definitions for leads, clients, deals, contacts, and other CRM-adjacent records.
|
|
24
26
|
- **`./knowledge`** -- knowledge graph schemas: document types, embedding metadata, and retrieval contract types.
|
|
25
27
|
- **`./test-utils`** -- Zod-based test fixtures and factory helpers. Not for production use.
|
|
@@ -36,7 +38,7 @@ import { parsePath, bySystem } from "@elevasis/core/knowledge";
|
|
|
36
38
|
|
|
37
39
|
The default export and all named subpaths above are browser-safe -- they contain only Zod schemas, TypeScript types, and pure utility functions. There are no Node.js-specific APIs, filesystem access, or server-side dependencies in the published surface.
|
|
38
40
|
|
|
39
|
-
The broader workspace `exports` (~40 paths in `packages/core`) are internal to the monorepo and not part of the published surface. Only the
|
|
41
|
+
The broader workspace `exports` (~40 paths in `packages/core`) are internal to the monorepo and not part of the published surface. Only the eight subpaths listed above are available to tenant projects.
|
|
40
42
|
|
|
41
43
|
## When To Use @elevasis/core Directly
|
|
42
44
|
|
|
@@ -53,6 +55,6 @@ Most tenant projects install `@elevasis/sdk`, which includes `@elevasis/core` as
|
|
|
53
55
|
|
|
54
56
|
For advanced use cases -- writing custom validators, extending the org model, or building a server that enforces the same contracts the platform uses -- import from `@elevasis/core` subpaths directly rather than going through the SDK layer.
|
|
55
57
|
|
|
56
|
-
##
|
|
58
|
+
## Documentation
|
|
57
59
|
|
|
58
|
-
|
|
60
|
+
- [Export Catalog](exports.mdx) - Generated table of all published subpath exports derived from the reference manifest
|
package/reference/index.mdx
CHANGED
|
@@ -31,9 +31,9 @@ You do not need all three packages. A pure automation project needs only `@eleva
|
|
|
31
31
|
|
|
32
32
|
## Packages
|
|
33
33
|
|
|
34
|
-
### @elevasis/sdk (v1.
|
|
34
|
+
### @elevasis/sdk (v1.48.0)
|
|
35
35
|
|
|
36
|
-
The primary developer package. Provides the TypeScript API for defining workflows and agents, the `elevasis-sdk` CLI for validation and deployment, and typed worker adapters for
|
|
36
|
+
The primary developer package. Provides the TypeScript API for defining workflows and agents, the `elevasis-sdk` CLI for validation and deployment, and typed worker adapters for 27 platform and integration tools.
|
|
37
37
|
|
|
38
38
|
**Install:** `pnpm add @elevasis/sdk`
|
|
39
39
|
|
|
@@ -41,17 +41,17 @@ The primary developer package. Provides the TypeScript API for defining workflow
|
|
|
41
41
|
|
|
42
42
|
See [@elevasis/sdk](sdk/index.mdx) for the full group overview, getting started guide, CLI reference, adapter catalog, and more.
|
|
43
43
|
|
|
44
|
-
### @elevasis/core (v0.
|
|
44
|
+
### @elevasis/core (v0.63.0)
|
|
45
45
|
|
|
46
46
|
The shared contract layer. Exports Zod schemas and TypeScript types that are shared between the SDK, the UI, and the platform API. Useful when you need the typed contracts (organization model, entities, knowledge, auth) in a package that does not pull in the full SDK runtime.
|
|
47
47
|
|
|
48
48
|
**Install:** `pnpm add @elevasis/core`
|
|
49
49
|
|
|
50
|
-
**Published subpaths:** `.` (default), `./auth`, `./test-utils`, `./organization-model`, `./entities`, `./knowledge`
|
|
50
|
+
**Published subpaths:** `.` (default), `./auth`, `./test-utils`, `./organization-model`, `./organization-model/readiness`, `./content`, `./entities`, `./knowledge`
|
|
51
51
|
|
|
52
52
|
See [@elevasis/core](core/index.mdx) for subpath details, browser/server split, and when to use it.
|
|
53
53
|
|
|
54
|
-
### @elevasis/ui (v2.
|
|
54
|
+
### @elevasis/ui (v2.72.0)
|
|
55
55
|
|
|
56
56
|
The shared React feature-shell. Provides `ElevasisCoreProvider` / `ElevasisSystemsProvider` and manifest-backed feature modules that a host UI embeds. Many peer dependencies are optional -- pull only what the features you use require.
|
|
57
57
|
|
|
@@ -61,6 +61,12 @@ The shared React feature-shell. Provides `ElevasisCoreProvider` / `ElevasisSyste
|
|
|
61
61
|
|
|
62
62
|
See [@elevasis/ui](ui/index.mdx) for the provider model, feature modules, peer dependency details, and when to use it.
|
|
63
63
|
|
|
64
|
+
## Documentation
|
|
65
|
+
|
|
66
|
+
- [@elevasis/sdk](sdk/index.mdx) - Runtime, resource definitions, CLI, worker adapters, deployment, and framework
|
|
67
|
+
- [@elevasis/core](core/index.mdx) - Shared Zod schemas, organization model, knowledge graph, and auth contracts
|
|
68
|
+
- [@elevasis/ui](ui/index.mdx) - React feature-shell, provider model, and manifest-backed feature modules
|
|
69
|
+
|
|
64
70
|
## Authoring Note
|
|
65
71
|
|
|
66
72
|
These pages have a dual surface. At SDK build time, `packages/sdk/scripts/copy-reference-docs.mjs` copies every `apps/docs/content/docs/sdk/**.mdx` into `packages/sdk/reference/`, which ships inside the npm package (`files: ["reference/"]`). The `external/_template/CLAUDE.md` points tenant-project agents at `operations/node_modules/@elevasis/sdk/reference/` as their primary reference bundle. Drift in these docs does not just affect the public site -- it actively misleads every agent building a tenant project.
|
|
@@ -1,44 +1,46 @@
|
|
|
1
|
-
# @elevasis/core
|
|
2
|
-
|
|
3
|
-
Published browser-safe shared contracts for the Elevasis platform.
|
|
4
|
-
|
|
5
|
-
This package is the source of truth for shared types, schemas, and contract helpers that are safe to consume from apps and other packages. In this repo the source package is named `@repo/core`, but these docs describe the published `@elevasis/core` surface.
|
|
6
|
-
|
|
7
|
-
## Import Rules
|
|
8
|
-
|
|
9
|
-
- Use `@elevasis/core` (root export) for browser-safe shared types and schemas.
|
|
10
|
-
- Use `@elevasis/core/organization-model` for the semantic contract layer.
|
|
11
|
-
- Use `@elevasis/core/entities` for the published base entity contracts.
|
|
12
|
-
- Use `@elevasis/core/
|
|
13
|
-
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
-
|
|
21
|
-
- `./
|
|
22
|
-
- `./
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
- `@
|
|
27
|
-
- `@
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
- `@repo/core/
|
|
32
|
-
- `@repo/core/
|
|
33
|
-
- `@repo/core/
|
|
34
|
-
- `@repo/core/
|
|
35
|
-
- `@repo/core/
|
|
36
|
-
- `@repo/core/
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
- For
|
|
1
|
+
# @elevasis/core
|
|
2
|
+
|
|
3
|
+
Published browser-safe shared contracts for the Elevasis platform.
|
|
4
|
+
|
|
5
|
+
This package is the source of truth for shared types, schemas, and contract helpers that are safe to consume from apps and other packages. In this repo the source package is named `@repo/core`, but these docs describe the published `@elevasis/core` surface.
|
|
6
|
+
|
|
7
|
+
## Import Rules
|
|
8
|
+
|
|
9
|
+
- Use `@elevasis/core` (root export) for browser-safe shared types and schemas.
|
|
10
|
+
- Use `@elevasis/core/organization-model` for the semantic contract layer, and `@elevasis/core/organization-model/readiness` for readiness profile and contract types.
|
|
11
|
+
- Use `@elevasis/core/auth` for multi-tenancy types, `@elevasis/core/content` for content metadata types, and `@elevasis/core/entities` for the published base entity contracts.
|
|
12
|
+
- Use `@elevasis/core/knowledge` for the published knowledge contracts.
|
|
13
|
+
- Use `@elevasis/core/test-utils` for shared test fixtures, mocks, and test helpers.
|
|
14
|
+
- Paths like `@elevasis/core/server`, `@elevasis/core/platform`, and `@elevasis/core/supabase` are internal monorepo paths (`@repo/core/...`) and are NOT available to external consumers.
|
|
15
|
+
|
|
16
|
+
## Published Surface Groups
|
|
17
|
+
|
|
18
|
+
The published `@elevasis/core` npm package exposes these subpaths (the authoritative list is `publishConfig.exports` in `packages/core/package.json`):
|
|
19
|
+
|
|
20
|
+
- `.` (`@elevasis/core`) - browser-safe shared types, schemas, and constants.
|
|
21
|
+
- `./auth` (`@elevasis/core/auth`) - multi-tenancy types for organizations, users, memberships, invitations, and credentials.
|
|
22
|
+
- `./content` (`@elevasis/core/content`) - published content metadata types.
|
|
23
|
+
- `./entities` (`@elevasis/core/entities`) - published base entity contracts generic over project metadata extensions.
|
|
24
|
+
- `./knowledge` (`@elevasis/core/knowledge`) - published knowledge graph contracts.
|
|
25
|
+
- `./organization-model` (`@elevasis/core/organization-model`) - the semantic contract layer for CRM, lead gen, delivery, features, branding, and navigation.
|
|
26
|
+
- `./organization-model/readiness` (`@elevasis/core/organization-model/readiness`) - readiness profile and contract types for the organization model.
|
|
27
|
+
- `./test-utils` (`@elevasis/core/test-utils`) - test fixtures, mocks, and helpers for downstream automated tests.
|
|
28
|
+
|
|
29
|
+
Within the monorepo, the internal `@repo/core` package exposes additional subpaths that are NOT published, for use by `apps/` and other packages:
|
|
30
|
+
|
|
31
|
+
- `@repo/core/server` - Node.js-only helpers and services.
|
|
32
|
+
- `@repo/core/platform` - shared constants, utilities, registry, SSE, and API types.
|
|
33
|
+
- `@repo/core/execution` - workflow, agent, scheduler, and execution-interface contracts.
|
|
34
|
+
- `@repo/core/commands` - command queue types and schemas.
|
|
35
|
+
- `@repo/core/operations` - sessions, notifications, observability, activities, triggers, and debug logs.
|
|
36
|
+
- `@repo/core/supabase` - generated database types and helpers.
|
|
37
|
+
- `@repo/core/integrations/...` - OAuth and credential contracts.
|
|
38
|
+
- `@repo/core/projects/api-schemas` - project management request and response schemas.
|
|
39
|
+
|
|
40
|
+
Other `@repo/core/*` subpaths remain monorepo-only unless they are explicitly listed above in the published `@elevasis/core` surface.
|
|
41
|
+
|
|
42
|
+
## When To Read Deeper
|
|
43
|
+
|
|
44
|
+
- For the organization model contract, start with [organization-model/README.md](./organization-model/README.md).
|
|
45
|
+
- For test utilities, read [test-utils/README.md](./test-utils/README.md).
|
|
46
|
+
- For credentials, read [auth/multi-tenancy/credentials/README.md](./auth/multi-tenancy/credentials/README.md) if you are working in source. The runtime helpers are server-only.
|
|
@@ -6,18 +6,22 @@ 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`, `OpenContentReviewGate` | The one predicate deciding whether a `processing_state` entry is an open, unreviewed gate on a **queue-reviewed** step — `step.reviewVenue === 'queue'`, entry not `running`, and `executionId` still non-null. It answers "can the queue screen clear this", so a Workspace-reviewed step has no gate here. Consumed by the `/queue` handler, `reviewItem`'s `stepKey` validation, and the review page. |
|
|
20
|
+
| `resolveCurrentContentStep` | The step an item is sitting at: steps ascending by `order` (ties by `key`), first one not yet `'success'`, falling back to the last step once all have succeeded. Returns `undefined` for no declared steps and for an unplaced item whose `processingState` names no key the current catalog declares. Duplicates `deriveItemPlacement`'s ordering rule by hand — keep the two in sync. |
|
|
21
|
+
| `isAwaitingReview` | Cheap boolean for counting and filtering: is a person owed an action on this item. True when the step's `reviewMode` is not `'none'` and `item.reviewedAt` is still null. Takes whatever step the caller already resolved, typically via `resolveCurrentContentStep`. |
|
|
22
|
+
| `resolveReviewTarget`, `ContentReviewTarget` | The exhaustive answer surfaces render from — **where** the review happens, not just whether one is owed. An open queue gate wins first, then a current step with `reviewVenue === 'workspace'` that `isAwaitingReview` plus a resolved route, else `{ kind: 'none' }`. Deliberately separate from `isAwaitingReview` so callers stop recombining "is one owed" and "where" with `&&` at the point of use. |
|
|
23
|
+
| `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`. |
|
|
24
|
+
| `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
25
|
|
|
22
26
|
## Step catalog reconciliation
|
|
23
27
|
|
|
@@ -109,7 +109,7 @@ Then inspect:
|
|
|
109
109
|
|
|
110
110
|
- `core/config/organization-model.ts` -- Organization Model overrides plus Systems and Resources descriptors. Start here for feature labels, surface mapping, and resource identity/governance changes.
|
|
111
111
|
- `ui/src/routes/__root.tsx` and the relevant nav config files
|
|
112
|
-
- Access-gating call sites: `useAccess(accessKey)` from `@elevasis/ui/hooks` and `<AccessGuard accessKey={...}>` from `@elevasis/ui/auth`. The template ships no local `useFeatureAccess.ts` and there is no hook factory -- these two published entry points are the whole gating surface.
|
|
112
|
+
- Access-gating call sites: `useAccess(accessKey)` from `@elevasis/ui/hooks` and `<AccessGuard accessKey={...}>` from `@elevasis/ui/auth`. The template ships no local `useFeatureAccess.ts` and there is no hook factory -- these two published entry points are the whole gating surface. A System's top-level route file wraps that pairing in `<ProtectedSystemRoute accessKey={...}>` from `@elevasis/ui/features/auth`, which is what every template System route ships; see `ui.md` "System route guarding".
|
|
113
113
|
|
|
114
114
|
Verify with: published docs for `@elevasis/core/organization-model`, plus current scaffold routes and manifests.
|
|
115
115
|
|
|
@@ -14,7 +14,9 @@ paths:
|
|
|
14
14
|
- `ElevasisUIProvider` in `ui/src/main.tsx` auto-composes shared UI, auth, and API surface -- route files do not wire providers manually
|
|
15
15
|
- `useApiClient()` from `@elevasis/ui/api` for authenticated API calls, passing `API_URL` from `@/lib/constants/api` -- never raw `fetch` with auth headers. There is no `ui/src/lib/hooks/` directory; see `ui.md` "API and Streaming"
|
|
16
16
|
- `routeTree.gen.ts` is auto-generated on `pnpm dev` -- never edit manually
|
|
17
|
-
- Auth protection: wrap page content with `ProtectedRoute` from `@elevasis/ui/auth`. Gate further with `AccessGuard accessKey={...}` nested inside `ProtectedRoute` -- a System path for system gating, or an `AccessKeys` constant (e.g. `AccessKeys.platformAdmin`) for permission-backed gating. `FeatureGuard`, `SystemGuard`, `SurfaceGuard`, and `AdminGuard` are retired -- do not reintroduce them
|
|
17
|
+
- Auth protection: wrap page content with `ProtectedRoute` from `@elevasis/ui/features/auth`. Gate further with `AccessGuard accessKey={...}` nested inside `ProtectedRoute` -- a System path for system gating, or an `AccessKeys` constant (e.g. `AccessKeys.platformAdmin`) for permission-backed gating. `FeatureGuard`, `SystemGuard`, `SurfaceGuard`, and `AdminGuard` are retired -- do not reintroduce them
|
|
18
|
+
- **For a System's top-level route, use `ProtectedSystemRoute accessKey={...}` from `@elevasis/ui/features/auth` instead of writing that pairing by hand.** It expands to exactly the `ProtectedRoute` + `AccessGuard` nesting above and adds `SystemUnavailableState` as the guard's `fallback`, so a denied user sees the reason rather than `AccessGuard`'s blank `fallback = null` default. Every System route in the template ships this shape; see `ui.md` "System route guarding". Keep `createFileRoute` in the route file and keep bare `AccessGuard` for gating below the route level
|
|
19
|
+
- **Two `ProtectedRoute` components exist and the subpath you import from decides what the user sees while the app initializes.** `@elevasis/ui/features/auth` is the one route files want: it wraps the base guard with an animated full-screen loader and a default `AppShellError` error fallback. `@elevasis/ui/auth` exports the headless base guard, whose `fallback` defaults to `null` -- importing it without passing a `fallback` renders a blank screen for the whole initialization window and swallows initialization errors. Reach for the headless one only when the surface renders its own loading state. `AccessKeys` is a plain constant table and stays on `@elevasis/ui/auth` (or `@elevasis/ui/hooks`) either way
|
|
18
20
|
- Never fork `@elevasis/ui` components -- if a published component needs a tweak, that missing capability is a bug in `@elevasis/ui`
|
|
19
21
|
|
|
20
22
|
## Silent-Break Gotchas
|
|
@@ -11,11 +11,13 @@ External projects consume the **published `@elevasis/*` surface only**. The Elev
|
|
|
11
11
|
|
|
12
12
|
## What You Can Import
|
|
13
13
|
|
|
14
|
-
| Package | Subpaths
|
|
15
|
-
| ---------------- |
|
|
16
|
-
| `@elevasis/sdk` | default, `/worker`, `/node`, `/test-utils`
|
|
17
|
-
| `@elevasis/ui` | default, `/auth`, `/initialization`, etc.
|
|
18
|
-
| `@elevasis/core` | `/organization-model`, `/entities`, `/
|
|
14
|
+
| Package | Subpaths | Where it lives in `node_modules` |
|
|
15
|
+
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- |
|
|
16
|
+
| `@elevasis/sdk` | default, `/worker`, `/node`, `/test-utils` | `node_modules/@elevasis/sdk/` |
|
|
17
|
+
| `@elevasis/ui` | default, `/auth`, `/initialization`, etc. | `node_modules/@elevasis/ui/` |
|
|
18
|
+
| `@elevasis/core` | default, `/auth`, `/test-utils`, `/organization-model`, `/organization-model/readiness`, `/content`, `/entities`, `/knowledge` | `node_modules/@elevasis/core/` |
|
|
19
|
+
|
|
20
|
+
`@elevasis/core`'s eight subpaths are its `publishConfig.exports`, and that is the whole published surface -- there is no `/utils`. `/content` is where `deriveContentBoard`, `resolveReviewTarget`, `isAwaitingReview`, and the content item and source-asset schemas live, so an import from it is legitimate.
|
|
19
21
|
|
|
20
22
|
## What You Will See in Monorepo Docs (and should NOT import)
|
|
21
23
|
|
package/reference/rules/ui.md
CHANGED
|
@@ -60,10 +60,12 @@ The app uses WorkOS AuthKit through `ElevasisUIProvider`. Authentication is enfo
|
|
|
60
60
|
|
|
61
61
|
**Route protection:**
|
|
62
62
|
|
|
63
|
-
Wrap protected route components with `ProtectedRoute` from `@elevasis/ui/auth`. For
|
|
63
|
+
Wrap protected route components with `ProtectedRoute` from `@elevasis/ui/features/auth`. For a **System's top-level route**, use `ProtectedSystemRoute` instead -- it is the canonical shape and is what `ui/src/routes/crm.tsx`, `lead-gen.tsx`, `monitoring.tsx`, `operations.tsx`, `projects.tsx`, `content.tsx`, and `knowledge.tsx` all ship as. See "System route guarding" below. `ProtectedRoute` on its own is for a protected route that gates on authentication alone:
|
|
64
|
+
|
|
65
|
+
`@elevasis/ui` publishes two components under this name and they behave differently. The one route files want is `@elevasis/ui/features/auth`: it wraps the base guard with an animated full-screen loader that fades out when initialization completes, and supplies a default `AppShellError` fallback so an initialization failure renders a retry surface instead of nothing. `@elevasis/ui/auth` exports the headless base guard, whose `fallback` prop defaults to `null` -- a route that imports it and passes no `fallback` shows a blank screen for the entire initialization window and silently swallows blocking errors. Import the headless one only when the surface deliberately renders its own loading state.
|
|
64
66
|
|
|
65
67
|
```tsx
|
|
66
|
-
import { ProtectedRoute } from '@elevasis/ui/auth'
|
|
68
|
+
import { ProtectedRoute } from '@elevasis/ui/features/auth'
|
|
67
69
|
|
|
68
70
|
function HomePageGuarded() {
|
|
69
71
|
return (
|
|
@@ -74,14 +76,38 @@ function HomePageGuarded() {
|
|
|
74
76
|
}
|
|
75
77
|
```
|
|
76
78
|
|
|
79
|
+
**System route guarding:**
|
|
80
|
+
|
|
81
|
+
`ProtectedSystemRoute` from `@elevasis/ui/features/auth` is the shape a System's top-level route file uses. It composes `ProtectedRoute` + `AccessGuard` and supplies `SystemUnavailableState` as the guard's `fallback`, so a denial renders the specific reason `checkAccess` already computed instead of `AccessGuard`'s own blank `fallback = null` default:
|
|
82
|
+
|
|
83
|
+
```tsx
|
|
84
|
+
import { ProtectedSystemRoute } from '@elevasis/ui/features/auth'
|
|
85
|
+
import { createFileRoute, Outlet } from '@tanstack/react-router'
|
|
86
|
+
|
|
87
|
+
export const Route = createFileRoute('/crm')({
|
|
88
|
+
component: CrmLayout
|
|
89
|
+
})
|
|
90
|
+
|
|
91
|
+
function CrmLayout() {
|
|
92
|
+
return (
|
|
93
|
+
<ProtectedSystemRoute accessKey="sales.crm">
|
|
94
|
+
<Outlet />
|
|
95
|
+
</ProtectedSystemRoute>
|
|
96
|
+
)
|
|
97
|
+
}
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
Three things this does not change. `createFileRoute` stays in the route file -- TanStack's file-based routing requires it there, and `ProtectedSystemRoute` only replaces the route's layout body. `AccessGuard` is unchanged and is still what you reach for below the route level, or for a permission-backed `AccessKeys` gate that is not a System path. And a leaf page under an already-guarded layout route needs no guard of its own -- the layout's guard covers it.
|
|
101
|
+
|
|
77
102
|
**Access gating:**
|
|
78
103
|
|
|
79
104
|
Access is resolved by the unified Access Model -- System lifecycle from the organization model, role permissions, diagnostic allowlists, membership scope, and platform-admin bypass -- through two published symbols. There is no `createFeatureAccessHook` and no `SystemGuard`; both are retired and must not be reintroduced.
|
|
80
105
|
|
|
81
|
-
`AccessGuard` from `@elevasis/ui/auth` wraps a subtree:
|
|
106
|
+
`AccessGuard` from `@elevasis/ui/auth` wraps a subtree. Prefer `ProtectedSystemRoute` above when the subtree is a whole System's route; the hand-written pairing below is what it expands to, and is still correct for non-System gating:
|
|
82
107
|
|
|
83
108
|
```tsx
|
|
84
|
-
import {
|
|
109
|
+
import { AccessKeys } from '@elevasis/ui/auth'
|
|
110
|
+
import { AccessGuard, ProtectedRoute } from '@elevasis/ui/features/auth'
|
|
85
111
|
|
|
86
112
|
<ProtectedRoute>
|
|
87
113
|
<AccessGuard accessKey="sales.crm">
|
|
@@ -295,7 +321,7 @@ For CRM deal action buttons, read `operations/node_modules/@elevasis/sdk/referen
|
|
|
295
321
|
|
|
296
322
|
## Topbar Actions
|
|
297
323
|
|
|
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
|
|
324
|
+
`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
325
|
|
|
300
326
|
Author them in `core/config/organization-model/navigation.ts`, keyed by action id:
|
|
301
327
|
|
|
@@ -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
|
|
|
@@ -51,7 +51,7 @@ The user wants to know something about current state -- task priorities, what is
|
|
|
51
51
|
| "What systems are enabled for this project?" | Static-model query about Systems config |
|
|
52
52
|
| "What's waiting on review?" | Runtime-entity query about content review-gate state |
|
|
53
53
|
|
|
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 `elevasis-sdk content:queue --pretty` (open review gates), `content:list --pretty` (item overview), `content:board <pipelineId> --pretty` (pipeline 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.
|
|
55
55
|
|
|
56
56
|
### 3. Describe
|
|
57
57
|
|
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 | Routed to
|
|
17
|
-
| ---------- | ------------------------------------------------------------------------------------------ |
|
|
18
|
-
| Capture | "add", "remember", "track", "log", "note for myself" + a thing | Agent -- draft + confirm + `project:*`, `note:create`, or `
|
|
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`
|
|
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
|
|
|
@@ -34,6 +34,26 @@ Vibe is **ambient and always on**. Every natural-language message is silently cl
|
|
|
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
|