@elevasis/sdk 1.28.0 → 1.29.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.
Files changed (53) hide show
  1. package/dist/cli.cjs +8 -2
  2. package/dist/index.d.ts +18 -0
  3. package/dist/index.js +4 -0
  4. package/dist/test-utils/index.d.ts +18 -0
  5. package/dist/test-utils/index.js +2 -0
  6. package/package.json +4 -4
  7. package/reference/_navigation.md +4 -4
  8. package/reference/_reference-manifest.json +8 -8
  9. package/reference/claude-config/hooks/scaffold-registry-reminder.mjs +3 -3
  10. package/reference/claude-config/skills/tutorial/technical.md +5 -5
  11. package/reference/claude-config/sync-notes/2026-05-24-platform-invite-router-core-baseline.md +28 -0
  12. package/reference/core/exports.mdx +16 -0
  13. package/reference/core/index.mdx +58 -0
  14. package/reference/index.mdx +36 -67
  15. package/reference/scaffold/operations/propagation-pipeline.md +152 -152
  16. package/reference/{cli-management.mdx → sdk/cli-management.mdx} +159 -13
  17. package/reference/{cli.mdx → sdk/cli.mdx} +68 -12
  18. package/reference/sdk/exports.mdx +14 -0
  19. package/reference/sdk/index.mdx +93 -0
  20. package/reference/sdk/platform-tools/adapters-integration.mdx +25 -0
  21. package/reference/sdk/platform-tools/adapters-platform.mdx +24 -0
  22. package/reference/{platform-tools → sdk/platform-tools}/index.mdx +9 -30
  23. package/reference/{resources → sdk/resources}/patterns.mdx +29 -11
  24. package/reference/ui/exports.mdx +60 -0
  25. package/reference/ui/index.mdx +75 -0
  26. package/reference/platform-tools/adapters-integration.mdx +0 -300
  27. package/reference/platform-tools/adapters-platform.mdx +0 -552
  28. /package/reference/{concepts.mdx → sdk/concepts.mdx} +0 -0
  29. /package/reference/{deployment → sdk/deployment}/command-center.mdx +0 -0
  30. /package/reference/{deployment → sdk/deployment}/execution-reference.mdx +0 -0
  31. /package/reference/{deployment → sdk/deployment}/index.mdx +0 -0
  32. /package/reference/{framework → sdk/framework}/agent.mdx +0 -0
  33. /package/reference/{framework → sdk/framework}/index.mdx +0 -0
  34. /package/reference/{framework → sdk/framework}/interaction-guidance.mdx +0 -0
  35. /package/reference/{framework → sdk/framework}/memory.mdx +0 -0
  36. /package/reference/{framework → sdk/framework}/project-structure.mdx +0 -0
  37. /package/reference/{framework → sdk/framework}/resource-documentation.mdx +0 -0
  38. /package/reference/{framework → sdk/framework}/tutorial-system.mdx +0 -0
  39. /package/reference/{getting-started.mdx → sdk/getting-started.mdx} +0 -0
  40. /package/reference/{platform-tools → sdk/platform-tools}/type-safety.mdx +0 -0
  41. /package/reference/{resources → sdk/resources}/index.mdx +0 -0
  42. /package/reference/{resources → sdk/resources}/types.mdx +0 -0
  43. /package/reference/{roadmap.mdx → sdk/roadmap.mdx} +0 -0
  44. /package/reference/{runtime.mdx → sdk/runtime.mdx} +0 -0
  45. /package/reference/{templates → sdk/templates}/data-enrichment.mdx +0 -0
  46. /package/reference/{templates → sdk/templates}/email-sender.mdx +0 -0
  47. /package/reference/{templates → sdk/templates}/index.mdx +0 -0
  48. /package/reference/{templates → sdk/templates}/lead-scorer.mdx +0 -0
  49. /package/reference/{templates → sdk/templates}/pdf-generator.mdx +0 -0
  50. /package/reference/{templates → sdk/templates}/recurring-job.mdx +0 -0
  51. /package/reference/{templates → sdk/templates}/text-classifier.mdx +0 -0
  52. /package/reference/{templates → sdk/templates}/web-scraper.mdx +0 -0
  53. /package/reference/{troubleshooting.mdx → sdk/troubleshooting.mdx} +0 -0
package/reference/scaffold/operations/propagation-pipeline.md CHANGED
@@ -1,156 +1,156 @@
1
- ---
2
- title: Propagation Pipeline
3
- description: Three-layer pipeline that keeps Organization OS artifacts current across the monorepo and all template-derived external projects -- source generation, registry-driven sync planning/apply, and verification.
4
- ---
1
+ ---
2
+ title: Propagation Pipeline
3
+ description: Three-layer pipeline that keeps Organization OS artifacts current across the monorepo and all template-derived external projects -- source generation, registry-driven sync planning/apply, and verification.
4
+ ---
5
5
  <!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
6
6
  <!-- Regenerate: pnpm scaffold:sync -->
7
7
 
8
-
9
- # Propagation Pipeline
10
-
11
- `🟢 Stable` -- These pipelines run automatically. Understand them when debugging sync issues or extending the scaffold.
12
-
13
- ---
14
-
15
- ## Architecture
16
-
17
- The Organization OS propagation pipeline has three layers. Each has its own scripts, triggers, and failure modes.
18
-
19
- ```
20
- Layer 1: Source Generation (pnpm scaffold:sync)
21
- Regenerates derived docs from TypeScript types and manifests
22
- ↓
23
- Layer 2: Registry-Driven Sync Planning + Apply (/external sync)
24
- Plans registry-backed writes/deletes, then applies the approved scope
25
- ↓
26
- Layer 3: Sync Verification (pnpm sync:verify)
27
- Asserts correctness across all template-derived projects after apply
28
- ```
29
-
30
- ---
31
-
32
- ## Layer 1: Source Generation
33
-
34
- `pnpm scaffold:sync` is the meta-script that regenerates all derived documentation and validates the output. It chains three sub-scripts:
35
-
36
- | Script | Input | Output |
37
- | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
38
- | `generate-scaffold-contracts.js` | `packages/core/src/organization-model/types.ts`, `packages/ui/src/features/registry/types.ts`, `packages/core/src/platform/registry/types.ts` | `packages/core/src/reference/_generated/contracts.md` |
39
- | `generate-scaffold-feature-registry.js` | `packages/ui/src/features/registry/manifests.ts`, `packages/ui/src/features/*/manifest.ts` | `packages/ui/src/scaffold/_generated/feature-registry.md` |
40
- | `generate-reference-artifacts.js` | SDK manifest, navigation sources | `packages/sdk/reference/_reference-manifest.json`, `_navigation.md` |
41
-
42
- After generation, `validate-reference-artifacts.js` checks that the outputs are consistent. Exit 1 if drifted.
43
-
44
- ### Trigger Points
45
-
46
- - **`/external sync` Phase 0 (Scaffold Sync Preflight):** Runs before any writes. Generated file changes fold into the sync scope so they propagate naturally to `_template` and downstream projects.
47
- - **`/sdk release` Step 1 (Shared Reference Preflight):** Runs before publish. Generated changes must be committed; validator failure is a hard blocker.
48
- - **Manual:** `pnpm scaffold:sync` is idempotent and safe to run anytime.
49
- - **Opt-out:** `--skip-scaffold-sync` on `/external sync` (rare).
50
-
51
- ### Design: Regenerate-on-Propagation
52
-
53
- Drift is healed at the moment it would otherwise leak downstream. This is cheaper and more reliable than CI-only checks. The single meta-script gives one command to reason about, while the chained sub-scripts remain individually callable for debugging.
54
-
55
- ---
56
-
57
- ## Layer 2: Registry-Driven Sync Planning + Apply
58
-
59
- `/external sync` now treats the scaffold registry as the execution contract rather than relying on tier prose alone.
60
- The canonical ownership vocabulary is:
61
-
62
- | Category | Strategy examples | Meaning |
63
- | --------------- | ----------------------------------------------- | ----------------------------------------------------------------------- |
64
- | `replace` | `replace-all` | Template-managed surface; copy from template baseline |
65
- | `merge` | `merge-baseline`, `merge-regions` | Merge-aware surface; preserve project customizations where required |
66
- | `never-touch` | `verify-only` | Project-owned surface; planner may report drift but never writes |
67
- | `generated` | `generated-freshness` | Generated surface; verify/regen instead of copying |
68
-
69
- Current command helpers:
70
-
71
- ```bash
72
- pnpm sync:plan -- --all # registry-backed dry-run plan
73
- pnpm sync:apply -- --all # registry-backed apply pass
74
- pnpm sync:verify # post-apply verification
75
- ```
76
-
77
- Per-project or scoped runs pass the project name and optional `--path` / `--source` filters through to the planner/apply script.
78
-
79
- Delete behavior is explicit:
80
-
81
- - managed deletes apply only to `replace` surfaces
82
- - deletion is allowed only when the path appears in the manifest-backed tombstone list
83
- - absence from the template alone is not enough to delete a downstream file
84
-
85
- Generated surfaces are also explicit:
86
-
87
- - they are planned as `generated`
88
- - apply does not copy them as normal source files
89
- - the relevant regen command must run, then `pnpm sync:verify` checks freshness
90
-
91
- The external skill doc (`.claude/skills/external/SKILL.md`) remains the workflow authority, but it should be read as planner/apply/verify orchestration over the registry model above.
92
-
93
- ---
94
-
95
- ## Layer 3: Sync Verification
96
-
97
- `pnpm sync:verify` runs 86+ automated checks to assert propagation correctness. The script lives at `scripts/external/verify-sync.js`.
98
-
99
- ### Per-Project Checks (auto-discovered)
100
-
101
- | Category | What It Checks |
102
- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
103
- | `deps` | `@elevasis/ui`, `@elevasis/sdk`, `@elevasis/core` versions match template |
104
- | `tier1` | registry-backed replace surfaces match template where verification still models them as exact baselines |
8
+
9
+ # Propagation Pipeline
10
+
11
+ `🟢 Stable` -- These pipelines run automatically. Understand them when debugging sync issues or extending the scaffold.
12
+
13
+ ---
14
+
15
+ ## Architecture
16
+
17
+ The Organization OS propagation pipeline has three layers. Each has its own scripts, triggers, and failure modes.
18
+
19
+ ```
20
+ Layer 1: Source Generation (pnpm scaffold:sync)
21
+ Regenerates derived docs from TypeScript types and manifests
22
+ ↓
23
+ Layer 2: Registry-Driven Sync Planning + Apply (/external sync)
24
+ Plans registry-backed writes/deletes, then applies the approved scope
25
+ ↓
26
+ Layer 3: Sync Verification (pnpm sync:verify)
27
+ Asserts correctness across all template-derived projects after apply
28
+ ```
29
+
30
+ ---
31
+
32
+ ## Layer 1: Source Generation
33
+
34
+ `pnpm scaffold:sync` is the meta-script that regenerates all derived documentation and validates the output. It chains three sub-scripts:
35
+
36
+ | Script | Input | Output |
37
+ | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
38
+ | `generate-scaffold-contracts.js` | `packages/core/src/organization-model/types.ts`, `packages/ui/src/features/registry/types.ts`, `packages/core/src/platform/registry/types.ts` | `packages/core/src/reference/_generated/contracts.md` |
39
+ | `generate-scaffold-feature-registry.js` | `packages/ui/src/features/registry/manifests.ts`, `packages/ui/src/features/*/manifest.ts` | `packages/ui/src/scaffold/_generated/feature-registry.md` |
40
+ | `generate-reference-artifacts.js` | SDK manifest, navigation sources | `packages/sdk/reference/_reference-manifest.json`, `_navigation.md` |
41
+
42
+ After generation, `validate-reference-artifacts.js` checks that the outputs are consistent. Exit 1 if drifted.
43
+
44
+ ### Trigger Points
45
+
46
+ - **`/external sync` Phase 0 (Scaffold Sync Preflight):** Runs before any writes. Generated file changes fold into the sync scope so they propagate naturally to `_template` and downstream projects.
47
+ - **`/sdk release` Step 1 (Shared Reference Preflight):** Runs before publish. Generated changes must be committed; validator failure is a hard blocker.
48
+ - **Manual:** `pnpm scaffold:sync` is idempotent and safe to run anytime.
49
+ - **Opt-out:** `--skip-scaffold-sync` on `/external sync` (rare).
50
+
51
+ ### Design: Regenerate-on-Propagation
52
+
53
+ Drift is healed at the moment it would otherwise leak downstream. This is cheaper and more reliable than CI-only checks. The single meta-script gives one command to reason about, while the chained sub-scripts remain individually callable for debugging.
54
+
55
+ ---
56
+
57
+ ## Layer 2: Registry-Driven Sync Planning + Apply
58
+
59
+ `/external sync` now treats the scaffold registry as the execution contract rather than relying on tier prose alone.
60
+ The canonical ownership vocabulary is:
61
+
62
+ | Category | Strategy examples | Meaning |
63
+ | ------------- | --------------------------------- | ------------------------------------------------------------------- |
64
+ | `replace` | `replace-all` | Template-managed surface; copy from template baseline |
65
+ | `merge` | `merge-baseline`, `merge-regions` | Merge-aware surface; preserve project customizations where required |
66
+ | `never-touch` | `verify-only` | Project-owned surface; planner may report drift but never writes |
67
+ | `generated` | `generated-freshness` | Generated surface; verify/regen instead of copying |
68
+
69
+ Current command helpers:
70
+
71
+ ```bash
72
+ pnpm sync:plan -- --all # registry-backed dry-run plan
73
+ pnpm sync:apply -- --all # registry-backed apply pass
74
+ pnpm sync:verify # post-apply verification
75
+ ```
76
+
77
+ Per-project or scoped runs pass the project name and optional `--path` / `--source` filters through to the planner/apply script.
78
+
79
+ Delete behavior is explicit:
80
+
81
+ - managed deletes apply only to `replace` surfaces
82
+ - deletion is allowed only when the path appears in the manifest-backed tombstone list
83
+ - absence from the template alone is not enough to delete a downstream file
84
+
85
+ Generated surfaces are also explicit:
86
+
87
+ - they are planned as `generated`
88
+ - apply does not copy them as normal source files
89
+ - the relevant regen command must run, then `pnpm sync:verify` checks freshness
90
+
91
+ The external skill doc (`.claude/skills/external/SKILL.md`) remains the workflow authority, but it should be read as planner/apply/verify orchestration over the registry model above.
92
+
93
+ ---
94
+
95
+ ## Layer 3: Sync Verification
96
+
97
+ `pnpm sync:verify` runs 86+ automated checks to assert propagation correctness. The script lives at `scripts/external/verify-sync.js`.
98
+
99
+ ### Per-Project Checks (auto-discovered)
100
+
101
+ | Category | What It Checks |
102
+ | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
103
+ | `deps` | `@elevasis/ui`, `@elevasis/sdk`, `@elevasis/core` versions match template |
104
+ | `tier1` | registry-backed replace surfaces match template where verification still models them as exact baselines |
105
105
  | `org-os` | Organization model exists, exports canonical symbols, imports from `@elevasis/core/organization-model`, either calls `createFoundationOrganizationModel` or uses explicit `resolveOrganizationModel(..., { mergeDefaults: false })` canonical assembly, app-config references org model, `__root.tsx` uses `ElevasisAuthenticatedShell` / `ElevasisSystemsProvider` + `canonicalOrganizationModel`, `main.tsx` uses `createElevasisApp`, all 3 CSS subpath imports present |
106
- | `placeholders` | No unresolved `__PROJECT_SLUG__`, `__PROJECT_NAME__`, `__PROJECT_DESCRIPTION__` in key config files |
107
- | `scripts` | `ui` and `operations` `package.json` have required npm scripts |
108
- | `lib` | `ui/src/lib/`, `lib/`, `test-utils/` exist with minimum file counts |
109
- | `tier3` | project-owned preservation boundaries such as `nav-items.ts` remain intact |
110
- | `conflicts` | No merge conflict markers in source files |
111
- | `git` | Working tree is clean |
112
- | `lockfile` | `pnpm-lock.yaml` and `node_modules` exist |
113
-
114
- ### Monorepo-Level Checks
115
-
116
- | Category | What It Checks |
117
- | ----------- | ----------------------------------------------- |
118
- | `scaffold` | `pnpm scaffold:sync` passes (artifacts current) |
119
- | `artifacts` | 5 generated artifacts exist and have content |
120
-
121
- ### Usage
122
-
123
- ```bash
124
- pnpm sync:verify # Post-sync assertion (exit 1 on failures)
125
- pnpm sync:verify --pre # Pre-sync drift report (always exit 0)
126
- pnpm sync:verify -- ZentaraHQ # Single project
127
- ```
128
-
129
- ### Integration Points
130
-
131
- - **`/external sync` preflight:** Runs `pnpm sync:verify --pre` before planning so current drift is visible before any writes
132
- - **`/external sync` planner/apply:** `pnpm sync:plan` previews registry-backed writes/deletes, then `pnpm sync:apply` executes the approved plan
133
- - **`/external sync` post-apply:** Runs `pnpm sync:verify` to assert correctness after the planner/apply pass
134
- - **Automated coverage:** tests live under `scripts/external/__tests__/` including planner/apply coverage
135
-
136
- ### Planner Interpretation Note
137
-
138
- `pnpm sync:verify` still carries some historical `tier1` / `tier3` labels in its output, but the ownership semantics now come from the registry-backed categories used by the planner:
139
-
140
- - `.claude/commands/**`, `hooks/**`, `rules/**`, `scripts/**`, `skills/**`, and `.claude/settings.json` are managed `replace` surfaces
141
- - `nav-items.ts`, `operations/src/**`, `shared/src/**`, `CLAUDE.md`, and extension files are `never-touch`
142
- - generated surfaces are verified for freshness, not copied
143
-
144
- Treat the old tier labels as display shorthand inside the verifier, not as the canonical execution contract.
145
-
146
- ---
147
-
148
- ## Remaining Gaps (Future Work)
149
-
150
- | Gap | Priority |
151
- | ------------------------------------------------------------------------- | -------- |
152
- | System manifest validation (all manifests imported in `__root.tsx`) | Medium |
153
- | TypeScript verification (`check-types` per project) | Medium |
154
- | Template docs surface validation (`docs/index.md`, `agent-start-here.md`) | Medium |
155
- | Environment variable template validation (`.env.example` completeness) | Low |
156
- | CI drift check (fail if worktree dirty after `scaffold:sync`) | Low |
106
+ | `placeholders` | No unresolved `__PROJECT_SLUG__`, `__PROJECT_NAME__`, `__PROJECT_DESCRIPTION__` in key config files |
107
+ | `scripts` | `ui` and `operations` `package.json` have required npm scripts |
108
+ | `lib` | `ui/src/lib/`, `lib/`, `test-utils/` exist with minimum file counts |
109
+ | `tier3` | project-owned preservation boundaries such as `nav-items.ts` remain intact |
110
+ | `conflicts` | No merge conflict markers in source files |
111
+ | `git` | Working tree is clean |
112
+ | `lockfile` | `pnpm-lock.yaml` and `node_modules` exist |
113
+
114
+ ### Monorepo-Level Checks
115
+
116
+ | Category | What It Checks |
117
+ | ----------- | ----------------------------------------------- |
118
+ | `scaffold` | `pnpm scaffold:sync` passes (artifacts current) |
119
+ | `artifacts` | 5 generated artifacts exist and have content |
120
+
121
+ ### Usage
122
+
123
+ ```bash
124
+ pnpm sync:verify # Post-sync assertion (exit 1 on failures)
125
+ pnpm sync:verify --pre # Pre-sync drift report (always exit 0)
126
+ pnpm sync:verify -- ZentaraHQ # Single project
127
+ ```
128
+
129
+ ### Integration Points
130
+
131
+ - **`/external sync` preflight:** Runs `pnpm sync:verify --pre` before planning so current drift is visible before any writes
132
+ - **`/external sync` planner/apply:** `pnpm sync:plan` previews registry-backed writes/deletes, then `pnpm sync:apply` executes the approved plan
133
+ - **`/external sync` post-apply:** Runs `pnpm sync:verify` to assert correctness after the planner/apply pass
134
+ - **Automated coverage:** tests live under `scripts/external/__tests__/` including planner/apply coverage
135
+
136
+ ### Planner Interpretation Note
137
+
138
+ `pnpm sync:verify` still carries some historical `tier1` / `tier3` labels in its output, but the ownership semantics now come from the registry-backed categories used by the planner:
139
+
140
+ - `.claude/skills/**`, `hooks/**`, `rules/**`, `scripts/**`, and `.claude/settings.json` are managed `replace` surfaces
141
+ - `nav-items.ts`, `operations/src/**`, `shared/src/**`, `CLAUDE.md`, and extension files are `never-touch`
142
+ - generated surfaces are verified for freshness, not copied
143
+
144
+ Treat the old tier labels as display shorthand inside the verifier, not as the canonical execution contract.
145
+
146
+ ---
147
+
148
+ ## Remaining Gaps (Future Work)
149
+
150
+ | Gap | Priority |
151
+ | ------------------------------------------------------------------------- | -------- |
152
+ | System manifest validation (all manifests imported in `__root.tsx`) | Medium |
153
+ | TypeScript verification (`check-types` per project) | Medium |
154
+ | Template docs surface validation (`docs/index.md`, `agent-start-here.md`) | Medium |
155
+ | Environment variable template validation (`.env.example` completeness) | Low |
156
+ | CI drift check (fail if worktree dirty after `scaffold:sync`) | Low |
package/reference/{cli-management.mdx → sdk/cli-management.mdx} RENAMED
@@ -60,14 +60,26 @@ elevasis-sdk project:task:delete <id>
60
60
  Task commands also expose agent-oriented resume state:
61
61
 
62
62
  ```bash
63
- elevasis-sdk project:task:resume <id> --pretty
64
- elevasis-sdk project:task:save <id> --current-state "Implemented the route layer"
63
+ elevasis-sdk project:task:resume <id> [--pretty]
64
+ elevasis-sdk project:task:save <id> --current-state <text> [--files-modified <json>] [--next-steps <text>] [--key-docs <json>] [--tools <json>]
65
65
  ```
66
66
 
67
- - `project:task:resume` reads the task's `resume_context`
68
- - `project:task:save` merges fields into `resume_context`
67
+ - `project:task:resume <id>` -- reads the task's `resume_context` JSONB; `--pretty` renders a human-readable briefing with current state, next steps, files modified, key docs, and tools used
68
+ - `project:task:save <id>` -- merges fields into `resume_context`; `--current-state` is required; all other flags are optional JSON arrays or plain text
69
69
  - these commands are the CLI counterpart to `/work resume` and `/work save` style flows
70
70
 
71
+ **`project:task:save` flags:**
72
+
73
+ | Flag | Description |
74
+ | --------------------------- | ----------------------------------------- |
75
+ | `--current-state <text>` | Required. Current state description |
76
+ | `--files-modified <json>` | JSON array of modified file paths |
77
+ | `--next-steps <text>` | Next steps description |
78
+ | `--key-docs <json>` | JSON array of key doc paths |
79
+ | `--tools <json>` | JSON array of tool names used |
80
+ | `--pretty` | Human-readable output instead of raw JSON |
81
+ | `--api-url <url>` | Override the API base URL |
82
+
71
83
  ### Notes
72
84
 
73
85
  ```bash
@@ -336,7 +348,17 @@ JWT-gated routes at the original unprefixed paths remain for the Command Center.
336
348
 
337
349
  **Note:** List-inspection routing lives in `/om` (Acquisition Operations dispatch). The `/acquisition` skill was folded into `/om`; all list reads still route to `elevasis-sdk acquisition:list:get <uuid>`.
338
350
 
339
- **Flags (all acquisition commands):**
351
+ **`acquisition:list:get` flags:**
352
+
353
+ | Flag | Description |
354
+ | ------------------------ | -------------------------------------------------- |
355
+ | `--no-include-deals` | Exclude thin deal lineage refs from the response |
356
+ | `--deal-limit <limit>` | Maximum number of thin deal refs to include |
357
+ | `--include-progress` | Include processing progress aggregates |
358
+ | `--pretty` | Human-readable terminal output instead of raw JSON |
359
+ | `--api-url <url>` | Override the API base URL |
360
+
361
+ **Shared flags (all other acquisition commands):**
340
362
 
341
363
  | Flag | Description |
342
364
  | ------------------- | -------------------------------------------------- |
@@ -409,20 +431,30 @@ elevasis-sdk session:get <id>
409
431
  elevasis-sdk session:end <id>
410
432
  ```
411
433
 
412
- - `session:list` -- list sessions for the organization; supports filtering by resource, status, and time range
434
+ - `session:list` -- list sessions for the organization; supports filtering by resource ID, user ID, and limit
413
435
  - `session:get <id>` -- get full session detail including messages and events
414
436
  - `session:end <id>` -- gracefully end an active session
415
437
 
416
- **API routes:** `GET /api/external/sessions`, `/api/external/sessions/:id`, `POST /api/external/sessions/:id/end`
438
+ **API routes:** `GET /api/external/sessions`, `/api/external/sessions/:id`, `DELETE /api/external/sessions/:id`
417
439
 
418
- **Flags:**
440
+ **`session:list` filter flags:**
419
441
 
420
- | Flag | Description |
421
- | ------------------- | -------------------------------------------------- |
422
- | `--pretty` | Human-readable terminal output instead of raw JSON |
423
- | `--api-url <url>` | Override the API base URL |
442
+ | Flag | Description |
443
+ | ---------------------- | ------------------------------------ |
444
+ | `--resource-id <id>` | Filter by agent resource ID |
445
+ | `--user-id <id>` | Filter by user ID |
446
+ | `--limit <limit>` | Maximum number of sessions to return |
447
+ | `--json` | Output as JSON |
448
+ | `--api-url <url>` | Override the API base URL |
449
+
450
+ **Shared flags (`session:get`, `session:end`):**
451
+
452
+ | Flag | Description |
453
+ | ------------------- | ------------------------- |
454
+ | `--json` | Output as JSON |
455
+ | `--api-url <url>` | Override the API base URL |
424
456
 
425
- **Implementation:** `packages/sdk/src/cli/commands/` (session family)
457
+ **Implementation:** `packages/sdk/src/cli/commands/session/session.ts`
426
458
 
427
459
  ---
428
460
 
@@ -440,6 +472,30 @@ elevasis-sdk queue:expire <id> --pretty
440
472
  elevasis-sdk queue:status --pretty
441
473
  ```
442
474
 
475
+ **`queue:list` filter flags:**
476
+
477
+ | Flag | Description |
478
+ | --------------------------- | --------------------------------------------------------------------------- |
479
+ | `--status <status>` | Filter by status: `pending`, `processing`, `completed`, `failed`, `expired` |
480
+ | `--human-checkpoint <id>` | Filter by checkpoint ID, or `ungrouped` for tasks without a checkpoint |
481
+ | `--time-range <range>` | Filter by created time range: `1h`, `24h`, `7d`, `30d` |
482
+ | `--priority-min <number>` | Minimum priority, 1-10 |
483
+ | `--priority-max <number>` | Maximum priority, 1-10 |
484
+ | `--limit <limit>` | Maximum number of tasks to return |
485
+ | `--offset <offset>` | Number of tasks to skip |
486
+ | `--pretty` | Human-readable output instead of raw JSON |
487
+ | `--api-url <url>` | Override the API base URL |
488
+
489
+ **`queue:select` flags:**
490
+
491
+ | Flag | Description |
492
+ | -------------------- | ----------------------------------------- |
493
+ | `--action-id <id>` | Required. Action ID to select |
494
+ | `--payload <json>` | Optional action payload as JSON |
495
+ | `--notes <notes>` | Optional human decision notes |
496
+ | `--pretty` | Human-readable output instead of raw JSON |
497
+ | `--api-url <url>` | Override the API base URL |
498
+
443
499
  **Auth:** Calls `/api/external/command-queue/*` with API-key auth.
444
500
 
445
501
  ---
@@ -460,6 +516,20 @@ elevasis-sdk schedule:resume <id> --pretty
460
516
  elevasis-sdk schedule:cancel <id> --pretty
461
517
  ```
462
518
 
519
+ **`schedule:update` flags:**
520
+
521
+ | Flag | Description |
522
+ | ---------------------------- | ------------------------------------------------------------------------- |
523
+ | `--name <name>` | New schedule name |
524
+ | `--description <text>` | New schedule description |
525
+ | `--clear-description` | Remove the schedule description (mutually exclusive with `--description`) |
526
+ | `--schedule-config <json>` | Replacement schedule config JSON |
527
+ | `--max-retries <number>` | Maximum retry attempts, 0-10 |
528
+ | `--pretty` | Human-readable output instead of raw JSON |
529
+ | `--api-url <url>` | Override the API base URL |
530
+
531
+ At least one field must be provided. `--description` and `--clear-description` are mutually exclusive.
532
+
463
533
  **Auth:** Calls `/api/external/task-scheduler/schedules*` with API-key auth.
464
534
 
465
535
  ---
@@ -476,10 +546,86 @@ For the full command reference, flag details, and graph architecture, see the [k
476
546
  elevasis-sdk knowledge:ls /by-system/sales.crm
477
547
  elevasis-sdk knowledge:cat <node-id>
478
548
  elevasis-sdk knowledge:graph
549
+ elevasis-sdk knowledge:search <query>
550
+ elevasis-sdk knowledge:describe <nodeId>
551
+ elevasis-sdk knowledge:skills <nodeId>
552
+ elevasis-sdk knowledge:generate
479
553
  ```
480
554
 
481
555
  These are registered as `knowledge:*` subcommands on `elevasis-sdk`. Both the SDK CLI (`elevasis-sdk knowledge:*`) and the platform CLI (`elevasis knowledge:*`) call the same query functions in `@repo/core/knowledge/queries`.
482
556
 
557
+ ### knowledge:search
558
+
559
+ Universal keyword search across the entire Organization Model (systems, resources, knowledge, ontology, roles, policies). Alias: `om:search`.
560
+
561
+ ```bash
562
+ elevasis-sdk knowledge:search <query> [--limit <n>] [--kinds <list>] [--json] [--ids-only]
563
+ ```
564
+
565
+ | Flag | Description |
566
+ | ------------------ | ------------------------------------------------------------------------------ |
567
+ | `--limit <n>` | Max hits to return; `0` = unlimited. Default: 10 |
568
+ | `--kinds <list>` | Comma-separated kinds filter: `system,resource,knowledge,ontology,role,policy` |
569
+ | `--json` | Print wrapped JSON envelope `{ query, limit, kinds, count, results }` |
570
+ | `--ids-only` | Print one ID per line (for piping) |
571
+
572
+ **Examples:**
573
+
574
+ ```bash
575
+ elevasis-sdk om:search "lead gen"
576
+ elevasis-sdk om:search outreach --kinds knowledge
577
+ elevasis-sdk om:search apollo --ids-only
578
+ ```
579
+
580
+ ### knowledge:describe
581
+
582
+ Structured neighborhood view for any OM node ID. Auto-detects kind (system, resource, knowledge, ontology, role, policy) from the ID shape. Alias: `om:describe`.
583
+
584
+ ```bash
585
+ elevasis-sdk knowledge:describe <nodeId> [--json]
586
+ ```
587
+
588
+ **Examples:**
589
+
590
+ ```bash
591
+ elevasis-sdk om:describe sales.lead-gen
592
+ elevasis-sdk om:describe knowledge.outreach-playbook
593
+ ```
594
+
595
+ ### knowledge:skills
596
+
597
+ Show callable invocations on graph neighbors for a knowledge node -- useful for discovering which actions or agent resources are linked to a given knowledge entry. Alias: `om:skills`.
598
+
599
+ ```bash
600
+ elevasis-sdk knowledge:skills <nodeId> [--json]
601
+ ```
602
+
603
+ **Example:**
604
+
605
+ ```bash
606
+ elevasis-sdk om:skills knowledge.new-vertical-launch-playbook
607
+ ```
608
+
609
+ ### knowledge:generate
610
+
611
+ Generate Organization Model knowledge nodes from MDX source files. Alias: `om:generate`.
612
+
613
+ ```bash
614
+ elevasis-sdk knowledge:generate [--source <path>] [--output <path>] [--flags-output <path>]
615
+ ```
616
+
617
+ | Flag | Description |
618
+ | ------------------------- | ----------------------------------------------------------------------------------------------------- |
619
+ | `--source <path>` | MDX source directory relative to project root. Default: `core/config/knowledge/nodes` |
620
+ | `--output <path>` | Generated TS file path relative to project root. Default: `core/config/knowledge/_generated/nodes.ts` |
621
+ | `--flags-output <path>` | Generated knowledge flag registry path. Default: `.claude/registries/knowledge-flags.json` |
622
+
623
+ **Example:**
624
+
625
+ ```bash
626
+ elevasis-sdk om:generate
627
+ ```
628
+
483
629
  ---
484
630
 
485
631
  ## elevasis-sdk ui:use-local / ui:use-published