@elevasis/sdk 1.47.0 → 1.48.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 +297 -93
- package/dist/index.d.ts +2 -2
- package/dist/index.js +23 -7
- package/dist/node/index.d.ts +2 -2
- package/dist/test-utils/index.d.ts +2 -2
- package/dist/test-utils/index.js +35 -7
- package/dist/worker/index.d.ts +24 -14
- package/dist/worker/index.js +6 -0
- package/package.json +4 -4
- package/reference/_navigation.md +3 -2
- package/reference/_reference-manifest.json +11 -1
- 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/vibe-intents.md +18 -15
- package/reference/rules/vibe.md +12 -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 +91 -28
- package/reference/scaffold/reference/glossary.md +2 -2
- package/reference/scaffold/reference/system-interface-capabilities.md +26 -6
- package/reference/sdk/cli-management.mdx +85 -23
- package/reference/sdk/platform-tools/adapters-platform.mdx +5 -5
|
@@ -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 `elevasis-sdk content:queue --pretty` (open review gates), `content:list --pretty` (item overview), `content:board <pipelineId> --pretty` (pipeline state), or `content:get <itemId> --pretty` (one item's attempt/distribution history) for the content platform. 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`, or `schedule: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,7 +30,7 @@ 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
|
|
|
@@ -44,4 +44,4 @@ Vibe is **ambient and always on**. Every natural-language message is silently cl
|
|
|
44
44
|
## References
|
|
45
45
|
|
|
46
46
|
- `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
|
|
47
|
+
- `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
|
|
|
@@ -57,17 +57,17 @@ A pipeline's step catalog is named `content:catalog/{pipelineId}-steps` and refe
|
|
|
57
57
|
|
|
58
58
|
## Published Content Surfaces
|
|
59
59
|
|
|
60
|
-
| Surface
|
|
61
|
-
|
|
|
62
|
-
| `contentManifest`, `CONTENT_ITEMS`, `ContentSidebar`, `ContentSidebarMiddle`, `MyReviewQueuePanel`
|
|
63
|
-
| `ContentOverviewPage`, `ContentItemsPage`, `ContentItemReviewPage`, `ContentPipelinesPage`, `
|
|
64
|
-
| `ContentDistributionsPage`, `ContentDistributionDetailPage`
|
|
65
|
-
| `ContentReviewCard`, `ReviewActionBar`, `PayloadBody`, `AlternatesPanel`, `ProcessingStateStrip`
|
|
66
|
-
| `useContentConfig`, `resolveContentStepResource`
|
|
67
|
-
| `useContentItems`, `useContentItem`, `useContentItemAttempts`, `useUpdateContentItem`, `useReviewContentItem`
|
|
68
|
-
| `useContentDistributions`, `useContentDistribution`, `useUpdateContentDistribution`
|
|
69
|
-
| `useContentPipelineSummary`
|
|
70
|
-
| `content`
|
|
60
|
+
| Surface | Import from | Use for |
|
|
61
|
+
| ---------------------------------------------------------------------------------------------------------------------- | ------------------------------- | ------------------------------------------------ |
|
|
62
|
+
| `contentManifest`, `CONTENT_ITEMS`, `ContentSidebar`, `ContentSidebarMiddle`, `MyReviewQueuePanel` | `@elevasis/ui/features/content` | Feature registration and sidebar composition |
|
|
63
|
+
| `ContentOverviewPage`, `ContentItemsPage`, `ContentItemReviewPage`, `ContentPipelinesPage`, `ContentPipelineBoardPage` | `@elevasis/ui/features/content` | Shared pages you can route to or wrap |
|
|
64
|
+
| `ContentDistributionsPage`, `ContentDistributionDetailPage` | `@elevasis/ui/features/content` | Distribution surfaces |
|
|
65
|
+
| `ContentReviewCard`, `ReviewActionBar`, `PayloadBody`, `AlternatesPanel`, `ProcessingStateStrip` | `@elevasis/ui/features/content` | Review UI primitives for a custom review screen |
|
|
66
|
+
| `useContentConfig`, `resolveContentStepResource` | `@elevasis/ui/features/content` | Read the resolved pipeline/step catalogs from OM |
|
|
67
|
+
| `useContentItems`, `useContentItem`, `useContentItemAttempts`, `useUpdateContentItem`, `useReviewContentItem` | `@elevasis/ui/hooks` | Item data access and review mutations |
|
|
68
|
+
| `useContentDistributions`, `useContentDistribution`, `useUpdateContentDistribution` | `@elevasis/ui/hooks` | Distribution data access |
|
|
69
|
+
| `useContentPipelineSummary` | `@elevasis/ui/hooks` | Pipeline roll-ups |
|
|
70
|
+
| `content` | `@elevasis/sdk/worker` | Workflow-side content adapter |
|
|
71
71
|
|
|
72
72
|
Read the generated contracts before changing typed boundaries:
|
|
73
73
|
|
|
@@ -217,16 +217,37 @@ function ReviewRoute() {
|
|
|
217
217
|
|
|
218
218
|
When the layout itself has to change, compose the primitives — `ContentReviewCard`, `ReviewActionBar`, `PayloadBody`, `AlternatesPanel`, `ProcessingStateStrip` — with `useContentItem`, `useContentItemAttempts`, and `useReviewContentItem`. Read the pipeline's steps through `useContentConfig` rather than hardcoding them, or a new step silently fails to render.
|
|
219
219
|
|
|
220
|
-
## 5.
|
|
220
|
+
## 5. Own the Workspace
|
|
221
221
|
|
|
222
|
-
|
|
223
|
-
pipeline section below it is the shared review and tracking nav. Which one you are adding to decides
|
|
224
|
-
which prop you pass.
|
|
222
|
+
This section is a contract, not a nav convention. One line divides the content System's UI:
|
|
225
223
|
|
|
226
|
-
|
|
224
|
+
**You own the surfaces where content is operated on. The platform owns the surfaces where it is
|
|
225
|
+
observed.**
|
|
227
226
|
|
|
228
|
-
|
|
229
|
-
|
|
227
|
+
Operating means creating a piece and clearing its review gates. Both are yours, and they are usually
|
|
228
|
+
one screen. Observing means the board, the items list, the attempt history, the distributions, and
|
|
229
|
+
the cross-pipeline review queue — those are shared, they display state, and they do not write.
|
|
230
|
+
|
|
231
|
+
The sidebar is shaped to match: the **`Workspace`** section on top holds your screens; the
|
|
232
|
+
`Content Pipeline` section below it is the shared observation nav.
|
|
233
|
+
|
|
234
|
+
### Why the split is drawn here
|
|
235
|
+
|
|
236
|
+
There are many ways to make content and many ways to review it, and both vary by source, by
|
|
237
|
+
platform, and by pipeline. A shared screen cannot hold that variation — every attempt produces a
|
|
238
|
+
page that fits nobody. What the System actually shares is the data model, the gate mechanics, and
|
|
239
|
+
the cross-pipeline view.
|
|
240
|
+
|
|
241
|
+
Nothing is given up by moving the review screen to your side. The rule that a producer cannot
|
|
242
|
+
approve its own output is enforced in two places, neither of them the UI: `reviewItem` is
|
|
243
|
+
deliberately absent from the content tool map, so no workflow can call it, and the HTTP route
|
|
244
|
+
carries `requireAccess(AccessKeys.contentManage)`. A React page of yours calling
|
|
245
|
+
`useReviewContentItem` is a person in a browser holding a JWT — exactly the operator the gate exists
|
|
246
|
+
for.
|
|
247
|
+
|
|
248
|
+
### Declare your Workspace pages
|
|
249
|
+
|
|
250
|
+
Pass `workspaceItems`:
|
|
230
251
|
|
|
231
252
|
```tsx
|
|
232
253
|
import { contentManifest, ContentSidebar } from '@elevasis/ui/features/content'
|
|
@@ -234,19 +255,61 @@ import type { SystemModule } from '@elevasis/ui/provider'
|
|
|
234
255
|
import type { NavItem } from '@elevasis/ui/layout'
|
|
235
256
|
import { IconPencil } from '@tabler/icons-react'
|
|
236
257
|
|
|
237
|
-
const
|
|
258
|
+
const workspaceItems: NavItem[] = [{ label: 'Draft a Post', to: '/content/write', icon: IconPencil, exact: false }]
|
|
238
259
|
|
|
239
260
|
export const customContentManifest: SystemModule = {
|
|
240
261
|
...contentManifest,
|
|
241
|
-
sidebar: () => <ContentSidebar
|
|
262
|
+
sidebar: () => <ContentSidebar workspaceItems={workspaceItems} />
|
|
242
263
|
}
|
|
243
264
|
```
|
|
244
265
|
|
|
245
|
-
Add as many as you like — a drafting screen, a brief builder, a batch generator
|
|
246
|
-
one, the section renders a "No
|
|
266
|
+
Add as many as you like — a drafting screen, a brief builder, a batch generator, a review console.
|
|
267
|
+
Until you declare one, the section renders a "No workspace pages declared yet" hint rather than an
|
|
268
|
+
empty gap.
|
|
269
|
+
|
|
270
|
+
Everything you need to build a combined create-and-review screen is already exported:
|
|
271
|
+
`useReviewContentItem`, `ReviewActionBar`, `ContentReviewCard`, `PayloadBody`, `AlternatesPanel`,
|
|
272
|
+
`ProcessingStateStrip`, `useContentItem`, `useContentItemAttempts`, `useContentConfig`, and
|
|
273
|
+
`resolveContentStepResource`.
|
|
274
|
+
|
|
275
|
+
**`Workspace` is a fixed platform label and is not vocabulary-driven.** Rename the page, not the
|
|
276
|
+
section. (The section was called `Create` before 2026-08-15. `createItems` still works as a
|
|
277
|
+
deprecated alias for one minor; move to `workspaceItems`.)
|
|
278
|
+
|
|
279
|
+
### Point the shared pages at your Workspace
|
|
280
|
+
|
|
281
|
+
A display-only surface with nothing to click is a dead end, so declare where a reviewer should go.
|
|
282
|
+
Set `workspaceRoute` on the pipeline's catalog entry:
|
|
283
|
+
|
|
284
|
+
<!-- doc-snippet:skip: illustrative excerpt, not a standalone compilable file -->
|
|
285
|
+
|
|
286
|
+
```ts
|
|
287
|
+
'linkedin-post': {
|
|
288
|
+
label: 'LinkedIn Post',
|
|
289
|
+
stepCatalog: 'content:catalog/linkedin-post-steps',
|
|
290
|
+
workspaceRoute: '/content/write'
|
|
291
|
+
}
|
|
292
|
+
```
|
|
293
|
+
|
|
294
|
+
The board, the items list, and the review queue all resolve it: a card or row sitting at an open
|
|
295
|
+
gate opens your screen instead of the shared item page. A step may override it when a pipeline's
|
|
296
|
+
gates are genuinely different screens — a video chain reviewing text candidates, then rendered
|
|
297
|
+
video, then copy plus a schedule, is three screens, not one:
|
|
298
|
+
|
|
299
|
+
<!-- doc-snippet:skip: illustrative excerpt, not a standalone compilable file -->
|
|
300
|
+
|
|
301
|
+
```ts
|
|
302
|
+
'render-video': { actor: 'workflow', reviewMode: 'queued', workspaceRoute: '/content/review-render' }
|
|
303
|
+
```
|
|
304
|
+
|
|
305
|
+
Resolution is override-then-fallback — the step's route when it declares one, the pipeline's
|
|
306
|
+
otherwise. Use `resolveContentWorkspaceRoute` rather than reading either field directly.
|
|
247
307
|
|
|
248
|
-
|
|
249
|
-
|
|
308
|
+
**Declaring it is expected, and omitting it is supported.** A pipeline with no `workspaceRoute`
|
|
309
|
+
keeps the shared review page's action bar, so you can clear gates before you have built anything.
|
|
310
|
+
Once you declare a route, that page defers to it and links out instead. The route is an
|
|
311
|
+
app-relative path (`/content/write`); an absolute URL is rejected, because a pipeline entry should
|
|
312
|
+
not be able to send a reviewer off-origin.
|
|
250
313
|
|
|
251
314
|
### Adding to the pipeline nav (rare)
|
|
252
315
|
|
|
@@ -263,14 +326,14 @@ const customItems: NavItem[] = [
|
|
|
263
326
|
|
|
264
327
|
sidebar: () => (
|
|
265
328
|
<ContentSidebar>
|
|
266
|
-
<ContentSidebarMiddle
|
|
329
|
+
<ContentSidebarMiddle workspaceItems={workspaceItems} items={customItems} />
|
|
267
330
|
</ContentSidebar>
|
|
268
331
|
)
|
|
269
332
|
```
|
|
270
333
|
|
|
271
|
-
**Prefer `
|
|
272
|
-
|
|
273
|
-
|
|
334
|
+
**Prefer `workspaceItems` whenever the page is one of yours.** `CONTENT_ITEMS` is a static snapshot
|
|
335
|
+
built from the default vocabulary, so spreading it pins the shared labels at their defaults — a
|
|
336
|
+
tenant that later renames its pipelines to "Campaigns" through `system.config.vocabulary` keeps
|
|
274
337
|
rendering "Pipelines" here, and nothing fails to tell you.
|
|
275
338
|
|
|
276
339
|
Replace `contentManifest` with `customContentManifest` in the local `SYSTEM_MANIFESTS` array and add
|
|
@@ -42,9 +42,9 @@ description: Terminology disambiguation for Organization OS concepts used in the
|
|
|
42
42
|
|
|
43
43
|
**MembershipFeatureConfig** -- retired per-member feature override config. The migration is complete: access is resolved through the unified Access Model using Organization Model System lifecycle, role permissions, diagnostic allowlists, membership scope, and platform-admin bypass.
|
|
44
44
|
|
|
45
|
-
**OrganizationModel** -- top-level semantic contract for an organization. Current primary fields include `version`, `snapshotHash`, `domainMetadata`, `branding`, `navigation`, `ontology`, `systems`, `resources`, `topology`, `identity`, `clients`, `customers`, `offerings`, `roles`, `goals`,
|
|
45
|
+
**OrganizationModel** -- top-level semantic contract for an organization. Current primary fields include `version`, `snapshotHash`, `domainMetadata`, `branding`, `navigation`, `ontology`, `systems`, `resources`, `topology`, `identity`, `clients`, `customers`, `offerings`, `roles`, `goals`, and `knowledge`. `sales`, `prospecting`, `projects`, `statuses`, and `policies` were removed from the top-level contract in the Phase 4 schema cut; do not author against them. `actions` and `entities` remain current schema fields but are compatibility-oriented -- new authoring prefers System-owned ontology/config/resource contracts.
|
|
46
46
|
|
|
47
|
-
**OrganizationModelSystemEntry** -- System node in `OrganizationModel.systems`. Primary authoring fields include `id`, `label`, `description`, `parentSystemId`, `systems`, `lifecycle`, `ui`, `requiresAdmin`, `devOnly`, `responsibleRoleId`, `governedByKnowledge`, `drivesGoals`, `actions`, `
|
|
47
|
+
**OrganizationModelSystemEntry** -- System node in `OrganizationModel.systems`. Primary authoring fields include `id`, `label`, `description`, `parentSystemId`, `systems`, `lifecycle`, `ui`, `requiresAdmin`, `devOnly`, `responsibleRoleId`, `governedByKnowledge`, `drivesGoals`, `actions`, `ontology`, `config`, and `order`. `subsystems` is a retained compatibility input for older projects and should not be used for new recursive Systems. `content` is **retired** — the System schema is strict and rejects it. Author schemas and catalogs in `ontology`, and system-local settings in `config`.
|
|
48
48
|
|
|
49
49
|
**Provider / ElevasisSystemsProvider** -- runtime that registers System modules, resolves System lifecycle against the org model, projects sidebar navigation, and exposes shell helpers through `useElevasisSystems()`.
|
|
50
50
|
|
|
@@ -8,18 +8,24 @@
|
|
|
8
8
|
|
|
9
9
|
This catalog is generated from `SYSTEM_INTERFACE_PROFILES` and the derived-readiness checks in `packages/core/src/organization-model/readiness/` (built-in lead-gen/CRM profiles are registered from `packages/core/src/business/acquisition/ontology-validation.ts`).
|
|
10
10
|
|
|
11
|
-
System Interface profiles are a closed platform adoption handshake.
|
|
11
|
+
System Interface profiles are a closed platform adoption handshake. This table is the complete set of profiles a System may declare; a System that adopts none of them omits `apiInterface` entirely and extends behavior through workflows/operations plus ontology, resources, and topology instead.
|
|
12
12
|
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
|
13
|
+
The catalog is closed because a `readinessProfile` names a capability the platform API gates a route on -- only the platform can mint one. `SystemInterfaceReadinessProfileSchema` accepts any non-empty string, but that is a property of the schema layer, not permission: an uncataloged id names no route, so the declaring System computes as **ready** and every call still fails, which is worse than the `missing-interface` a plain omission reports. Needing an uncataloged capability is a platform request (a route plus a catalog entry), not something to route around by inventing an id.
|
|
14
|
+
|
|
15
|
+
Two validation modes appear below. A **built-in** profile has a validator registered in platform code, so the adopting System needs no `readinessContract`. A **contract-validated** profile is platform-served but its structural requirements differ per adopter, so the adopting System MUST declare a `readinessContract`. `registerBuiltInReadinessProfile` is platform-code-only and is not reachable from a project: it mutates an in-process registry, while the readiness assertion that gates the API runs in the API process.
|
|
16
|
+
|
|
17
|
+
| Profile | Required System path | Interface key | Validation | `readinessContract` |
|
|
18
|
+
| --- | --- | --- | --- | --- |
|
|
19
|
+
| `sales.lead-gen.api` | `sales.lead-gen` | `api` | built-in | not required |
|
|
20
|
+
| `sales.crm.api` | `sales.crm` | `api` | built-in | not required |
|
|
21
|
+
| `sales.lead-gen.crm-handoff` | `sales.lead-gen` | `crm-handoff` | built-in | not required |
|
|
22
|
+
| `content.api` | `content` | `api` | contract | **required** |
|
|
18
23
|
|
|
19
24
|
## `sales.lead-gen.api`
|
|
20
25
|
|
|
21
26
|
- Required System path: `sales.lead-gen`
|
|
22
27
|
- Interface key: `api`
|
|
28
|
+
- Validation: **built-in** -- a platform-registered validator covers this profile; no `readinessContract` is required.
|
|
23
29
|
- Derived-readiness requirements:
|
|
24
30
|
- System Interface marker must be active and scope at least one active `sales.lead-gen` Resource.
|
|
25
31
|
- Object types: `sales.lead-gen:object/list`, `sales.lead-gen:object/company`, `sales.lead-gen:object/contact`.
|
|
@@ -33,6 +39,7 @@ System Interface profiles are a closed platform adoption handshake. Tenant custo
|
|
|
33
39
|
|
|
34
40
|
- Required System path: `sales.crm`
|
|
35
41
|
- Interface key: `api`
|
|
42
|
+
- Validation: **built-in** -- a platform-registered validator covers this profile; no `readinessContract` is required.
|
|
36
43
|
- Derived-readiness requirements:
|
|
37
44
|
- System Interface marker must be active and scope at least one active `sales.crm` Resource.
|
|
38
45
|
- Catalog types with entries: `sales.crm:catalog/crm.pipeline`.
|
|
@@ -42,6 +49,7 @@ System Interface profiles are a closed platform adoption handshake. Tenant custo
|
|
|
42
49
|
|
|
43
50
|
- Required System path: `sales.lead-gen`
|
|
44
51
|
- Interface key: `crm-handoff`
|
|
52
|
+
- Validation: **built-in** -- a platform-registered validator covers this profile; no `readinessContract` is required.
|
|
45
53
|
- Derived-readiness requirements:
|
|
46
54
|
- Derived handoff readiness is evaluated for `sales.lead-gen/crm-handoff`; it is not authored as a separate custom tenant API surface.
|
|
47
55
|
- Lead-gen API readiness requirements must pass for `sales.lead-gen/api`.
|
|
@@ -49,3 +57,15 @@ System Interface profiles are a closed platform adoption handshake. Tenant custo
|
|
|
49
57
|
- Derived scoped resources are active `sales.lead-gen` Resources whose `ontology.usesCatalogs` includes `sales.crm:catalog/crm.pipeline`.
|
|
50
58
|
- Provider readiness must pass for `sales.crm/api`.
|
|
51
59
|
- Topology must include a scoped `systemInterfaceGrant` relationship from consumer `sales.lead-gen/crm-handoff` to provider `sales.crm/api`.
|
|
60
|
+
|
|
61
|
+
## `content.api`
|
|
62
|
+
|
|
63
|
+
- Required System path: `content`
|
|
64
|
+
- Interface key: `api`
|
|
65
|
+
- Validation: **contract-validated** -- the adopting System MUST declare a `readinessContract`.
|
|
66
|
+
- Derived-readiness requirements:
|
|
67
|
+
- Gates every `/api/content/*` and `/api/external/content/*` route, via `CONTENT_API_INTERFACE` in `apps/api/src/business/content/organization-model.ts`.
|
|
68
|
+
- A `readinessContract` is REQUIRED. Unlike the `sales.*` profiles, no built-in validator is registered for this id, so readiness is checked structurally against the contract you declare; omitting it produces `missing-readiness-contract` at deploy preflight.
|
|
69
|
+
- `readinessContract.requiredObjects` must name the content item object owned by `content`, with a scoped `ontology.reads` binding on at least one scoped resource.
|
|
70
|
+
- `readinessContract.requiredCatalogs` must name your pipeline and status catalogs plus the step catalog your pipeline declares, each owned by `content`, non-empty, and carrying a scoped `ontology.usesCatalogs` binding. The step catalog id is project-specific by design.
|
|
71
|
+
- `resourceIds` must scope at least one active Resource; an empty array fails at runtime with `missing-scoped-resources` regardless of what deploy reported.
|
|
@@ -678,7 +678,7 @@ At least one field must be provided. `--description` and `--clear-description` a
|
|
|
678
678
|
|
|
679
679
|
Knowledge graph inspection, plus an Organization Model write surface (`om:scaffold:*`, `om:rename`, `om:deprecate`). The `om:*` (Organization Model) commands expose knowledge graph traversal via the CLI. `om:*` and `knowledge:*` are aliases of the same subcommands for the read-only surface described below -- the write commands are registered under `om:*` only, with no `knowledge:*` alias.
|
|
680
680
|
|
|
681
|
-
**Path axes for `knowledge:ls` / `om:ls`:** `/by-system/<id>`, `/by-ontology/<ontologyId>`, `/by-kind/<kind>`, `/by-owner/<ownerId>`, `/by-domain/<domain>` (enumerate all items in a domain: `clients`, `roles`, `
|
|
681
|
+
**Path axes for `knowledge:ls` / `om:ls`:** `/by-system/<id>`, `/by-ontology/<ontologyId>`, `/by-kind/<kind>`, `/by-owner/<ownerId>`, `/by-domain/<domain>` (enumerate all items in a domain: `clients`, `roles`, `customers`, `offerings`, `goals`), `/by-item/<domain>/<itemId>` (single domain-item profile), `/graph/<nodeId>/governs`, `/graph/<nodeId>/governed-by`, `/<nodeId>` (single node), `/all-systems`, `/all-resources`, `/all-roles`.
|
|
682
682
|
|
|
683
683
|
- `knowledge:ls <path>` -- list nodes/edges for the mount; default output is an id + summary table, `--json` returns `{ path, mount, args, results }`.
|
|
684
684
|
- `knowledge:cat <id>` -- render a node's `body` MDX to stdout; `--json` returns the full node object (body, links, owners, timestamps).
|
|
@@ -704,7 +704,7 @@ These are registered as `knowledge:*` subcommands on `elevasis-sdk`. Both the SD
|
|
|
704
704
|
|
|
705
705
|
### knowledge:search
|
|
706
706
|
|
|
707
|
-
Universal keyword search across the entire Organization Model (systems, resources, knowledge, ontology, roles
|
|
707
|
+
Universal keyword search across the entire Organization Model (systems, resources, knowledge, ontology, roles). Alias: `om:search`.
|
|
708
708
|
|
|
709
709
|
```bash
|
|
710
710
|
elevasis-sdk knowledge:search <query> [--limit <n>] [--kinds <list>] [--json] [--ids-only]
|
|
@@ -914,6 +914,8 @@ elevasis-sdk content:queue
|
|
|
914
914
|
elevasis-sdk content:pipeline
|
|
915
915
|
elevasis-sdk content:pipeline <pipelineId>
|
|
916
916
|
elevasis-sdk content:distributions --pipeline-id short-form-repurpose
|
|
917
|
+
elevasis-sdk content:source-assets --kind transcript
|
|
918
|
+
elevasis-sdk content:source-asset <sourceAssetId>
|
|
917
919
|
```
|
|
918
920
|
|
|
919
921
|
- `content:list` -- list content items. Filters: `--status`, `--pillar`, `--pipeline-id`, `--client-id`, `--reviewed-by`, `--search` (matches title), `--limit`, `--offset`.
|
|
@@ -922,12 +924,14 @@ elevasis-sdk content:distributions --pipeline-id short-form-repurpose
|
|
|
922
924
|
- `content:queue` -- items sitting on an open `queued`-gate review. Each row prints the item, the `stepKey` of the gate it is waiting on, and the attempt that opened it. This is the list `content:review` reads from -- see "Why `--step` is required" below.
|
|
923
925
|
- `content:pipeline [id]` -- with no id, lists pipeline templates; with an id, returns that pipeline's step contract (step keys and review modes). Read from the **deployed** Organization Model snapshot, not a local project model -- a model edit that has not been redeployed produces a stale-snapshot 503 that looks like a code bug.
|
|
924
926
|
- `content:distributions` -- list distribution rows (one per platform/format target per item). Filters: `--content-item-id`, `--pipeline-id`, `--platform`, `--status`, `--limit`, `--offset`.
|
|
927
|
+
- `content:source-assets` -- list source assets, the raw material items are derived from. Filters: `--kind`, `--limit`, `--offset`. `--pretty` omits payloads, which can run to hundreds of kilobytes.
|
|
928
|
+
- `content:source-asset <sourceAssetId>` -- one source asset in full, payload included. This is how you read back text you just created.
|
|
925
929
|
|
|
926
|
-
**API routes:** `GET /api/external/content/items`, `/api/external/content/items/:itemId`, `/api/external/content/queue`, `/api/external/content/pipelines`, `/api/external/content/pipelines/:id`, `/api/external/content/distributions`.
|
|
930
|
+
**API routes:** `GET /api/external/content/items`, `/api/external/content/items/:itemId`, `/api/external/content/queue`, `/api/external/content/pipelines`, `/api/external/content/pipelines/:id`, `/api/external/content/distributions`, `/api/external/content/source-assets`, `/api/external/content/source-assets/:sourceAssetId`.
|
|
927
931
|
|
|
928
932
|
### content:review
|
|
929
933
|
|
|
930
|
-
|
|
934
|
+
One of two write commands in this namespace. Everything else that writes to an item -- creating it, recording an attempt, opening a distribution -- is producer work through the `content` worker adapter, not a CLI command.
|
|
931
935
|
|
|
932
936
|
**Synopsis:**
|
|
933
937
|
|
|
@@ -970,6 +974,64 @@ elevasis-sdk content:review 3f9c1e20-... --step clip-selection --approve --user
|
|
|
970
974
|
elevasis-sdk content:review 3f9c1e20-... --step copy-generation --reject --user ops@acme.com --reason "Off-brand tone" --pretty
|
|
971
975
|
```
|
|
972
976
|
|
|
977
|
+
### content:source-asset:create
|
|
978
|
+
|
|
979
|
+
The namespace's second write command. It exists for a caller no other channel serves: an agent
|
|
980
|
+
working from a terminal with an API key. A deployed workflow already creates source assets through
|
|
981
|
+
`content.createSourceAsset` in the worker tool map, and a person uses the Command Center; a terminal
|
|
982
|
+
agent can reach neither, and before this command `content_source_assets` was unreachable for it with
|
|
983
|
+
no workaround.
|
|
984
|
+
|
|
985
|
+
**Synopsis:**
|
|
986
|
+
|
|
987
|
+
```
|
|
988
|
+
elevasis-sdk content:source-asset:create --kind <kind> --title <title> (--text <value> | --url <url>)
|
|
989
|
+
[--field <key>] [--duration <seconds>] [--item <itemId>]
|
|
990
|
+
```
|
|
991
|
+
|
|
992
|
+
A source asset holds its content in one of two places, and the flags mirror that exactly: `--text` is
|
|
993
|
+
inline content and lands in `payload`, `--url` is a reference and lands in `externalUrl`. They are
|
|
994
|
+
mutually exclusive because an asset is one shape or the other.
|
|
995
|
+
|
|
996
|
+
**There is no file upload, deliberately.** `storage_path` on the table is written by nothing, and
|
|
997
|
+
`/api/storage` has no external mirror. A file lives wherever it already lives and the asset points at
|
|
998
|
+
it with `--url`.
|
|
999
|
+
|
|
1000
|
+
**`--text` accepts `@path` to read a local file**, the same convention as `exec --input`. Anything not
|
|
1001
|
+
starting with `@` is the literal value. The CLI refuses content over 500KB locally rather than sending
|
|
1002
|
+
it for the server to reject -- that is `CONTENT_PAYLOAD_MAX_BYTES`, enforced by
|
|
1003
|
+
`ContentPayloadEnvelopeSchema`.
|
|
1004
|
+
|
|
1005
|
+
**The payload key defaults to the `--kind` value.** `--kind transcript` writes `payload.transcript`,
|
|
1006
|
+
matching what the Organization Model's `content:catalog/source-asset-kind` declares for that kind.
|
|
1007
|
+
Pass `--field` when a kind's declared field is named differently. A wrong key writes successfully and
|
|
1008
|
+
produces an asset no producer can read, so check the kind's declaration if unsure.
|
|
1009
|
+
|
|
1010
|
+
**An unlisted kind is legal and writes unvalidated.** URL-referencing kinds typically have no catalog
|
|
1011
|
+
entry at all -- the catalog declares payload fields, and a reference kind has none, so its URL is
|
|
1012
|
+
validated by `UrlSchema` on the request body instead. The consequence worth knowing: nothing can
|
|
1013
|
+
express "kind `youtube-video` requires `externalUrl`."
|
|
1014
|
+
|
|
1015
|
+
**Examples:**
|
|
1016
|
+
|
|
1017
|
+
```bash
|
|
1018
|
+
# Inline text from a local file
|
|
1019
|
+
elevasis-sdk content:source-asset:create --kind transcript --title "Episode 12" --text @transcript.txt --pretty
|
|
1020
|
+
|
|
1021
|
+
# A reference, linked to an item in the same invocation
|
|
1022
|
+
elevasis-sdk content:source-asset:create --kind youtube-video --title "The talk" \
|
|
1023
|
+
--url https://youtu.be/abc --duration 3600 --item 3f9c1e20-... --pretty
|
|
1024
|
+
```
|
|
1025
|
+
|
|
1026
|
+
Posts to `POST /api/external/content/source-assets`, then `PATCH /api/external/content/items/:itemId`
|
|
1027
|
+
when `--item` is given. The link is a second call on purpose: the asset exists either way, so a failed
|
|
1028
|
+
link leaves a usable row to retry against rather than losing the content just written.
|
|
1029
|
+
|
|
1030
|
+
**That `PATCH` is a link, not a general item update** -- `sourceAssetId` is the only field it accepts,
|
|
1031
|
+
and any other field is a 400. Editing an item's title, body, status, or pillar is producer work
|
|
1032
|
+
through `content.updateItem`, or a person's work in the Command Center. There is also no update or
|
|
1033
|
+
delete for a source asset: correct a bad one by creating a replacement and re-linking.
|
|
1034
|
+
|
|
973
1035
|
**Implementation:** `packages/sdk/src/cli/commands/content/`
|
|
974
1036
|
|
|
975
1037
|
---
|
|
@@ -978,25 +1040,25 @@ elevasis-sdk content:review 3f9c1e20-... --step copy-generation --reject --user
|
|
|
978
1040
|
|
|
979
1041
|
Current status of all SDK CLI domains. Domains marked `deferred` have no CLI commands yet.
|
|
980
1042
|
|
|
981
|
-
| Domain | CLI surface
|
|
982
|
-
| ----------- |
|
|
983
|
-
| platform | top-level SDK commands
|
|
984
|
-
| project | `project:*`
|
|
985
|
-
| knowledge | `knowledge:*`
|
|
986
|
-
| creds | `creds *` nested Commander group
|
|
987
|
-
| ui | `ui:*`
|
|
988
|
-
| request | `request:submit`, `request:list`, `request:get`
|
|
989
|
-
| error | `error resolve`, `error resolve-execution`
|
|
990
|
-
| acquisition | `acquisition:list:*`, `acquisition:deal:*`
|
|
991
|
-
| client | `client:*`
|
|
992
|
-
| agent | `agent:list`, `agent:get`
|
|
993
|
-
| session | `session:create`, `session:turn`, `session:messages`, `session:list`, `session:get`, `session:end`
|
|
994
|
-
| queue | `queue:list`, `queue:get`, `queue:select`, `queue:expire`, `queue:status`
|
|
995
|
-
| schedule | `schedule:list`, `schedule:get`, `schedule:create`, `schedule:update`
|
|
996
|
-
| skill | `skill:scaffold`, `skill:check-coverage`
|
|
997
|
-
| content | `content:list`, `content:get`, `content:board`, `content:queue`, `content:pipeline`, `content:distributions`, `content:review` | `/api/external/content*` | implemented read + review-write scope |
|
|
998
|
-
| seo | none
|
|
999
|
-
| monitoring | none
|
|
1043
|
+
| Domain | CLI surface | API surface | Status |
|
|
1044
|
+
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------- |
|
|
1045
|
+
| platform | top-level SDK commands | mixed platform APIs | implemented |
|
|
1046
|
+
| project | `project:*` | `apps/api/src/projects/` | implemented |
|
|
1047
|
+
| knowledge | `knowledge:*` | file/generated knowledge data | implemented |
|
|
1048
|
+
| creds | `creds *` nested Commander group | credentials API | implemented |
|
|
1049
|
+
| ui | `ui:*` | local project file edits | implemented |
|
|
1050
|
+
| request | `request:submit`, `request:list`, `request:get`, `request:update`, `request:delete` | requests API | implemented read/write scope |
|
|
1051
|
+
| error | `error resolve`, `error resolve-execution` | execution error APIs | partial |
|
|
1052
|
+
| acquisition | `acquisition:list:*`, `acquisition:deal:*` | `/api/external/acquisition/lists*`, `/api/external/deals*` | implemented read-only scope |
|
|
1053
|
+
| client | `client:*` | `/api/external/clients` | implemented read/write scope |
|
|
1054
|
+
| agent | `agent:list`, `agent:get` | `/api/external/agents*` | implemented read-only scope |
|
|
1055
|
+
| session | `session:create`, `session:turn`, `session:messages`, `session:list`, `session:get`, `session:end` | `/api/external/sessions*` | implemented multi-turn scope |
|
|
1056
|
+
| queue | `queue:list`, `queue:get`, `queue:select`, `queue:expire`, `queue:status` | `/api/external/command-queue*` | implemented |
|
|
1057
|
+
| schedule | `schedule:list`, `schedule:get`, `schedule:create`, `schedule:update` | `/api/external/task-scheduler/schedules*` | implemented |
|
|
1058
|
+
| skill | `skill:scaffold`, `skill:check-coverage` | local CLI catalog and `.claude/registries/skill-coverage.json` | implemented developer tooling |
|
|
1059
|
+
| content | `content:list`, `content:get`, `content:board`, `content:queue`, `content:pipeline`, `content:distributions`, `content:review`, `content:source-assets`, `content:source-asset`, `content:source-asset:create` | `/api/external/content*` | implemented read + review-write + source-asset-create scope |
|
|
1060
|
+
| seo | none | not scoped here | deferred |
|
|
1061
|
+
| monitoring | none | not scoped here | deferred |
|
|
1000
1062
|
|
|
1001
1063
|
### Promotion Criteria
|
|
1002
1064
|
|