@elevasis/sdk 1.30.0 → 1.30.2
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
CHANGED
|
@@ -42043,9 +42043,11 @@ function detectMissingApiInterfaceDeclarations(orgName, organizationModel) {
|
|
|
42043
42043
|
}
|
|
42044
42044
|
}
|
|
42045
42045
|
if (apiBoundResourcesBySystemPath.size === 0) return [];
|
|
42046
|
+
const catalogedSystemPaths = new Set(SYSTEM_INTERFACE_PROFILES.map((profile) => profile.systemPath));
|
|
42046
42047
|
const gaps = [];
|
|
42047
42048
|
for (const { path: path3, system } of listAllSystems(organizationModel)) {
|
|
42048
42049
|
if (system.apiInterface !== void 0) continue;
|
|
42050
|
+
if (!catalogedSystemPaths.has(path3)) continue;
|
|
42049
42051
|
const resourceIds = apiBoundResourcesBySystemPath.get(path3);
|
|
42050
42052
|
if (!resourceIds || resourceIds.length === 0) continue;
|
|
42051
42053
|
gaps.push({
|
|
@@ -45606,7 +45608,7 @@ function wrapAction(commandName, fn) {
|
|
|
45606
45608
|
// package.json
|
|
45607
45609
|
var package_default = {
|
|
45608
45610
|
name: "@elevasis/sdk",
|
|
45609
|
-
version: "1.30.
|
|
45611
|
+
version: "1.30.2",
|
|
45610
45612
|
description: "SDK for building Elevasis organization resources",
|
|
45611
45613
|
type: "module",
|
|
45612
45614
|
bin: {
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@elevasis/sdk",
|
|
3
|
-
"version": "1.30.
|
|
3
|
+
"version": "1.30.2",
|
|
4
4
|
"description": "SDK for building Elevasis organization resources",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
@@ -58,7 +58,7 @@
|
|
|
58
58
|
"tsup": "^8.0.0",
|
|
59
59
|
"typescript": "5.9.2",
|
|
60
60
|
"zod": "^4.1.0",
|
|
61
|
-
"@repo/core": "0.
|
|
61
|
+
"@repo/core": "0.39.0",
|
|
62
62
|
"@repo/eslint-config": "0.0.0",
|
|
63
63
|
"@repo/typescript-config": "0.0.0"
|
|
64
64
|
},
|
|
@@ -0,0 +1,153 @@
|
|
|
1
|
+
# Scaffold: New OM Entries via `om:scaffold:*` CLI
|
|
2
|
+
|
|
3
|
+
`om:scaffold:*` is the guided-creation surface for adding new entries to the tenant Organization Model. Each command prompts for missing fields, prints the proposed TypeScript / MDX block under `--dry-run`, and (when run without `--dry-run`) writes into the canonical authoring file under `core/config/organization-model/**` or `core/config/knowledge/nodes/`.
|
|
4
|
+
|
|
5
|
+
This operation is invoked by `/om` when intent classifies as **Codify-new-entry** (a net-new System, Resource, Role, Knowledge node, or a fill-pass against a conformance-gap JSON) rather than a Level-A field edit. For existing-field edits, dispatch to `codify-level-a.md` instead.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## When to Use
|
|
10
|
+
|
|
11
|
+
| Intent signal | Dispatch |
|
|
12
|
+
| ----------------------------------------------- | -------------------------------- |
|
|
13
|
+
| "Add a new system for …", "we have an X system" | `om:scaffold:system` |
|
|
14
|
+
| "Add a workflow / resource called …" | `om:scaffold:resource` |
|
|
15
|
+
| "Add a role …", "we need a … role" | `om:scaffold:role` |
|
|
16
|
+
| "Add a knowledge node / playbook / strategy …" | `om:scaffold:knowledge` |
|
|
17
|
+
| Conformance gate produced a gap JSON to apply | `om:scaffold:fill --gaps <path>` |
|
|
18
|
+
|
|
19
|
+
For existing-field edits (changing a description, toggling a system, renaming a label), use the Codify Level-A ceremony — do not scaffold.
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## CLI Surface
|
|
24
|
+
|
|
25
|
+
All commands run from inside `external/<project>/` (or any descendant — `elevasis-sdk` walks up to the `.elevasis` marker). Add `--dry-run` to any command to preview the generated TypeScript / MDX without writing.
|
|
26
|
+
|
|
27
|
+
| Command | Purpose | Writes to |
|
|
28
|
+
| ----------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------- |
|
|
29
|
+
| `om:scaffold:system` | Guide creation of a new System entry. Optional `--api-backed` emits an `apiInterface` block. | `core/config/organization-model/systems.ts` |
|
|
30
|
+
| `om:scaffold:resource` | Add a new workflow Resource descriptor with `systemPath` attachment and an ontology `primaryAction`. | `core/config/organization-model/systems.ts` |
|
|
31
|
+
| `om:scaffold:role` | Add a new Role to the profile domain. | `core/config/organization-model/profile.ts` |
|
|
32
|
+
| `om:scaffold:knowledge` | Create a new MDX knowledge node file under the requested kind / system mount. | `core/config/knowledge/nodes/` |
|
|
33
|
+
| `om:scaffold:fill` | Non-interactive apply of a conformance-gap JSON produced by the conformance gate (Agent 2a). | Per-file as recorded in the JSON. |
|
|
34
|
+
|
|
35
|
+
---
|
|
36
|
+
|
|
37
|
+
## Common Options
|
|
38
|
+
|
|
39
|
+
| Flag | Behavior |
|
|
40
|
+
| --------------------------- | ------------------------------------------------------------------------------------ | -------- | --------- | -------- |
|
|
41
|
+
| `--dry-run` | Print proposed block; write nothing. Always run this first when in doubt. |
|
|
42
|
+
| `-h`, `--help` | Print command-specific help. |
|
|
43
|
+
| `--id <id>` | Pre-fill the canonical id (prompted if absent). |
|
|
44
|
+
| `--title <title>` | Pre-fill display title (prompted if absent — `system`, `resource`, `role`). |
|
|
45
|
+
| `--system-path <path>` | Attach Resource or Knowledge to an existing System (prompted if absent). |
|
|
46
|
+
| `--api-backed` | (`system` only) Emit an `apiInterface` block; reminds you to populate `resourceIds`. |
|
|
47
|
+
| `--primary-action <action>` | (`resource` only) Pre-fill ontology primary action id. |
|
|
48
|
+
| `--kind <kind>` | (`knowledge` only) `playbook | strategy | reference | policy`. |
|
|
49
|
+
| `--gaps <path>` | (`fill` only) Required path to the conformance-gap JSON. |
|
|
50
|
+
| `--skipped <path>` | (`fill` only) Output path for gaps that still need manual input. |
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## Step-by-Step
|
|
55
|
+
|
|
56
|
+
### Step 1: Pre-flight read
|
|
57
|
+
|
|
58
|
+
Before scaffolding, run a single `om:describe` against the parent System (for Resource / Knowledge scaffolds) or the profile domain (for Role scaffolds). This grounds the proposed id, system path, and ontology references in current model state. Skipping this step routinely produces ids that collide with existing entries.
|
|
59
|
+
|
|
60
|
+
```bash
|
|
61
|
+
pnpm exec elevasis-sdk om:describe sales.crm
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
### Step 2: Dry-run
|
|
65
|
+
|
|
66
|
+
Always preview first. Each command prints the exact TypeScript / MDX block it would write.
|
|
67
|
+
|
|
68
|
+
```bash
|
|
69
|
+
pnpm exec elevasis-sdk om:scaffold:system --dry-run
|
|
70
|
+
pnpm exec elevasis-sdk om:scaffold:resource --dry-run
|
|
71
|
+
pnpm exec elevasis-sdk om:scaffold:role --dry-run
|
|
72
|
+
pnpm exec elevasis-sdk om:scaffold:knowledge --dry-run
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
The dry-run output is the diff you would present to the user during a Codify proposal. Show it verbatim before asking for confirmation.
|
|
76
|
+
|
|
77
|
+
### Step 3: Confirm
|
|
78
|
+
|
|
79
|
+
Pause for explicit user confirmation, exactly like Codify Level-A Step 3. Permission prompts also gate the underlying write.
|
|
80
|
+
|
|
81
|
+
### Step 4: Write
|
|
82
|
+
|
|
83
|
+
Re-run the command without `--dry-run`. The CLI:
|
|
84
|
+
|
|
85
|
+
1. Asserts the project is in split layout (`core/config/organization-model/{profile,systems,navigation}.ts`); on monolithic projects it errors with a guidance message rather than guessing where to write.
|
|
86
|
+
2. Inserts the new block alongside existing entries of the same kind.
|
|
87
|
+
3. Reports the touched file path.
|
|
88
|
+
|
|
89
|
+
### Step 5: Validate
|
|
90
|
+
|
|
91
|
+
Always run both gates after a scaffold write:
|
|
92
|
+
|
|
93
|
+
```bash
|
|
94
|
+
pnpm -C operations check-types # tsc --noEmit
|
|
95
|
+
pnpm -C operations check # elevasis-sdk resource validator (incl. conformance gate)
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
The new conformance gate (shipped in `@elevasis/sdk@1.30+`) will catch a System that declares API-backed Resources but no `apiInterface`. If it fires after a `system` scaffold, either:
|
|
99
|
+
|
|
100
|
+
- Re-run `om:scaffold:system --api-backed` to add the `apiInterface` block, or
|
|
101
|
+
- Run `om:scaffold:fill --gaps <gaps.json>` against the gate's emitted gaps file.
|
|
102
|
+
|
|
103
|
+
### Step 6: Rollback on failure
|
|
104
|
+
|
|
105
|
+
If either validation gate fails, restore the touched file from the snapshot captured in Step 1 of the parent `/om` Codify ceremony. The scaffold CLI does not perform its own rollback — the ceremony around it does.
|
|
106
|
+
|
|
107
|
+
---
|
|
108
|
+
|
|
109
|
+
## `om:scaffold:fill` — Conformance Gap Pass
|
|
110
|
+
|
|
111
|
+
`om:scaffold:fill` is the non-interactive counterpart to the four guided scaffolders. It consumes a JSON file shaped like the output of the conformance gate (the new deploy preflight introduced alongside `@elevasis/core@0.38` + `@elevasis/sdk@1.30`) and writes the missing fields it can derive without user input. Gaps that require a choice (e.g. picking a `readinessProfile`) land in the `--skipped` output for manual review.
|
|
112
|
+
|
|
113
|
+
```bash
|
|
114
|
+
# After the conformance gate prints a gaps file:
|
|
115
|
+
pnpm exec elevasis-sdk om:scaffold:fill --gaps .elevasis/conformance-gaps.json --dry-run
|
|
116
|
+
pnpm exec elevasis-sdk om:scaffold:fill --gaps .elevasis/conformance-gaps.json --skipped .elevasis/conformance-skipped.json
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
`fill` is idempotent for already-applied gaps; it skips entries that no longer match the live model.
|
|
120
|
+
|
|
121
|
+
---
|
|
122
|
+
|
|
123
|
+
## Layout Guard
|
|
124
|
+
|
|
125
|
+
Every `om:scaffold:*` command requires the split layout under `core/config/organization-model/`:
|
|
126
|
+
|
|
127
|
+
- `profile.ts` — identity, customers, offerings, roles, goals, techStack, labels
|
|
128
|
+
- `systems.ts` — systems + system-attached resources
|
|
129
|
+
- `navigation.ts` — navigation surfaces and sidebar wiring
|
|
130
|
+
|
|
131
|
+
On a monolithic `core/config/organization-model.ts`, the command errors with a one-line instruction to split first. The split step is owned by an upstream `/om` workflow — do not hand-split during a scaffold.
|
|
132
|
+
|
|
133
|
+
---
|
|
134
|
+
|
|
135
|
+
## Related Operations
|
|
136
|
+
|
|
137
|
+
- `codify-level-a.md` — existing-field edits (the default Codify pipeline)
|
|
138
|
+
- `codify-level-b.md` — net-new Zod extension files under `core/config/extensions/`
|
|
139
|
+
- `verify.md` — model-coherence checks (the in-memory doctor)
|
|
140
|
+
|
|
141
|
+
---
|
|
142
|
+
|
|
143
|
+
## Caller Contract (when dispatched from `/om`)
|
|
144
|
+
|
|
145
|
+
When `/om` classifies a Codify-new-entry intent, it should:
|
|
146
|
+
|
|
147
|
+
1. Pick the correct sub-command from the table above.
|
|
148
|
+
2. Pre-fill any options it can confidently extract from the conversation (`--id`, `--title`, `--system-path`, `--api-backed`, etc.) so the CLI does not re-prompt for them.
|
|
149
|
+
3. Always pass `--dry-run` on the first invocation and show the output to the user.
|
|
150
|
+
4. On user confirmation, re-invoke without `--dry-run`.
|
|
151
|
+
5. Run the Step 5 validators and report the result. Roll back if either fails.
|
|
152
|
+
|
|
153
|
+
Do not skip the dry-run round-trip. The scaffolders write into the authoring source of truth — silent writes erode the trust the `/om` ceremony exists to protect.
|