@elevasis/sdk 1.45.0 → 1.47.0

package/reference/sdk/cli-management.mdx

@@ -1,10 +1,12 @@
 ---
 title: CLI Management Commands
-description: elevasis-sdk management commands -- project, note, acquisition, client, agent, session, queue, schedule, om, ui, and skill subcommand families
+description: elevasis-sdk management commands -- project, note, acquisition, client, agent, session, queue, schedule, om, ui, skill, and content subcommand families
 ---
 
 This page covers the domain management commands for `elevasis-sdk`. For core SDK commands (check, deploy, exec, resources, executions, describe, creds, rename), see [CLI Reference](cli.mdx).
 
+Every command family on this page -- `project`, `note`, `acquisition`, `client`, `agent`, `session`, `queue`, `schedule`, `om:doctor`, `request`, and `content` -- also accepts `--prod` to target production, overriding `NODE_ENV=development` (live as of `@elevasis/sdk` 1.45.0). See [CLI Reference's Global Flags](cli.mdx#global-flags) for the full description; per-command flag tables below list `--api-url` and other command-specific flags only, not `--prod` or `--json`.
+
 ---
 
 ## JSON-valued options
@@ -94,10 +96,16 @@ elevasis-sdk project:task:get <id>
 elevasis-sdk project:task:create --project <id> --title "Implement API"
 elevasis-sdk project:task:create --project <id> --title "Implement API" --checklist @json:tmp/task-checklist.json
 elevasis-sdk project:task:update <id> --status in_progress
+elevasis-sdk project:task:update <id> --parent <parent-task-id>
+elevasis-sdk project:task:update <id> --clear-milestone
 elevasis-sdk project:task:update <id> --checklist @json:tmp/task-checklist.json
 elevasis-sdk project:task:delete <id>
 ```
 
+`milestone_id` and `parent_task_id` are nullable, and `--clear-milestone` / `--clear-parent` are how they are set to null. Each is mutually exclusive with its set-flag and exits `CONFLICTING_FLAGS` if both are passed, matching `project:update --client` / `--clear-client`. An empty string does **not** clear either one -- `--milestone ""` fails UUID validation rather than detaching.
+
+`--sequence <n>` on `project:milestone:create` and `project:milestone:update` writes the display order that `project:milestone:list` sorts by. It takes a non-negative integer and rejects anything else with `INVALID_SEQUENCE` before the request is sent.
+
 Task commands also expose agent-oriented resume state:
 
 ```bash
@@ -186,9 +194,9 @@ elevasis-sdk request:get <id>
 
 Most `project:*` commands support:
 
-| Flag              | Description                                        |
-| ----------------- | -------------------------------------------------- |
-| `--pretty`        | Human-readable terminal output instead of raw JSON |
+| Flag                | Description                                        |
+| ------------------- | -------------------------------------------------- |
+| `--pretty`          | Human-readable terminal output instead of raw JSON |
 | `--api-url <url>` | Override the API base URL                          |
 
 For exact required flags and accepted enum values, see the command source under `packages/sdk/src/cli/commands/project/`.
@@ -229,7 +237,7 @@ elevasis-sdk note:create --content <text>
 | Flag                      | Description                                                                               |
 | ------------------------- | ----------------------------------------------------------------------------------------- |
 | `--content <text>`      | Required. The note body text                                                              |
-| `--user <email>`        | Target user email. Defaults to the API key owner when omitted                             |
+| `--user <email>`        | **Required.** Target user email                                                           |
 | `--title <text>`        | Optional note title                                                                       |
 | `--priority <priority>` | Priority level: `low`, `normal` (default), `high`, or `urgent`                            |
 | `--pinned`                | Pin the note to the top of the panel                                                      |
@@ -240,8 +248,9 @@ elevasis-sdk note:create --content <text>
 **Behavior:**
 
 - Posts to `POST /api/external/user-notes`
-- When `--user` is omitted the note is created for the identity bound to the API key (the caller)
-- When `--user` is provided the platform resolves the email to a Supabase user UUID and verifies the resolved user is an active member of the calling organization before writing
+- `--user` is **not optional in practice**: the CLI omits `user_email` from the body when the flag is absent, and `ExternalCreateUserNoteBodySchema` requires it, so the call returns 400
+- There is no "API key owner" to default to. An API key is org-wide and its actor is the key itself, not a person -- defaulting would write a note into some human's private space they never asked for. See `.claude/rules/actor-attribution.md`
+- The platform resolves the email to a Supabase user UUID and verifies the resolved user is an active member of the calling organization before writing
 - External agent-created notes are always private; org-shared visibility is a signed-in UI capability, not a broadcast CLI mode
 - The `--source` flag is recorded as the `source` column in `user_notes`; agent runtimes should pass their resource ID here so users can see which workflow created the note
 - Priority `normal` produces no badge in the UI; `high` renders orange, `urgent` renders red, `low` renders dimmed gray
@@ -249,8 +258,8 @@ elevasis-sdk note:create --content <text>
 **Examples:**
 
 ```bash
-# Create a note for the API key owner
-elevasis-sdk note:create --content "Deal X has stalled -- follow up needed"
+# Create a note for a named user
+elevasis-sdk note:create --content "Deal X has stalled -- follow up needed" --user ops@acme.com
 
 # Create a high-priority pinned note for a specific user
 elevasis-sdk note:create \
@@ -667,13 +676,14 @@ At least one field must be provided. `--description` and `--clear-description` a
 
 ## elevasis-sdk om:\*
 
-Knowledge map inspection. The `om:*` (Organization Model) commands expose knowledge graph traversal via the CLI. `om:*` and `knowledge:*` are aliases of the same subcommands.
+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.
 
 **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`, `policies`, `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`.
 
 - `knowledge:ls <path>` -- list nodes/edges for the mount; default output is an id + summary table, `--json` returns `{ path, mount, args, results }`.
 - `knowledge:cat <id>` -- render a node's `body` MDX to stdout; `--json` returns the full node object (body, links, owners, timestamps).
 - `knowledge:graph <id>` -- show outgoing + incoming edges grouped by edge kind.
+- `om:doctor` -- validate Organization Model integrity against published `@elevasis/core/organization-model` primitives. This is a deliberately reduced 3-check command: two of the monorepo platform CLI's five checks assert monorepo-only paths that do not exist in a tenant project, so they are not ported. `--json` output includes `checksRun: 3` so a caller can tell it apart from the platform CLI's 5-check version.
 
 In tenant projects, SDK read commands load `core/config/organization-model.ts` through the SDK's layout-aware TypeScript loader. The temporary bundle and dependency resolution are anchored at the package root that owns SDK dependencies, so hoisted pnpm workspaces resolve `esbuild` and `@elevasis/core` correctly. Missing org-model files still return the default model; malformed files or files with no usable export emit diagnostics. `knowledge:generate` / `om:generate` is the exception because it reads MDX and codegen inputs directly.
 
@@ -687,6 +697,7 @@ elevasis-sdk knowledge:search <query>
 elevasis-sdk knowledge:describe <nodeId>
 elevasis-sdk knowledge:skills <nodeId>
 elevasis-sdk knowledge:generate
+elevasis-sdk om:doctor --org <OrgName>
 ```
 
 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`.
@@ -763,6 +774,81 @@ elevasis-sdk knowledge:generate [--source <path>] [--output <path>] [--flags-out
 elevasis-sdk om:generate
 ```
 
+### om:scaffold:\*
+
+Six scaffolders that splice new Organization Model entries into project source files: `om:scaffold:system`, `om:scaffold:resource`, `om:scaffold:role`, `om:scaffold:knowledge`, `om:scaffold:ontology`, `om:scaffold:fill`. There is no `knowledge:scaffold:*` alias.
+
+```bash
+elevasis-sdk om:scaffold:system --id sales.pipeline --title "Sales Pipeline" --kind operational
+elevasis-sdk om:scaffold:resource --id lead-discovery-workflow --system-path sales.pipeline --title "Lead Discovery"
+elevasis-sdk om:scaffold:role --id ops-lead --title "Ops Lead" --responsibility "Own weekly pipeline review"
+elevasis-sdk om:scaffold:knowledge --id outreach-playbook --kind playbook --system-path sales.pipeline
+elevasis-sdk om:scaffold:ontology --id deal --system-path sales.pipeline --kind object
+elevasis-sdk om:scaffold:fill --gaps tmp/conformance-gaps.json
+```
+
+**Default is dry-run.** Every `om:scaffold:*` command previews its change and writes nothing unless `--write` is passed (the one exception, `om:scaffold:ontology`, never writes at all -- see below). This inverted from earlier behavior, where these commands applied by default. An existing invocation that does not pass `--write` now only previews and silently stops applying -- this is the single most important thing to know about this command family.
+
+**`--dry-run` is not a flag on any `om:scaffold:*` command.** It exists only as a deprecated programmatic/TypeScript option consumed internally by the handler functions; passing `--dry-run` on the command line is an unrecognized-option error. `om:rename` and `om:deprecate`, documented in the next section, are different commands with their own real `--dry-run` flag -- do not carry that convention over here.
+
+**Splice targets:**
+
+| Subcommand              | Writes                                                                                                                                    |
+| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| `om:scaffold:system`    | Splices `core/config/organization-model/systems.ts`                                                                                       |
+| `om:scaffold:resource`  | Splices `core/config/organization-model/systems.ts` -- **known-broken, see below**                                                        |
+| `om:scaffold:role`      | Splices `core/config/organization-model/profile.ts`                                                                                       |
+| `om:scaffold:knowledge` | Writes a new `core/config/knowledge/nodes/<id>.mdx` file (no splice)                                                                    |
+| `om:scaffold:ontology`  | Print-only by design -- writes nothing, and carries no `--write` flag                                                                     |
+| `om:scaffold:fill`      | Writes new `core/config/organization-model/api-interfaces/<systemPath>.ts` const files and splices the import + field into `systems.ts` |
+
+**`om:scaffold:resource` is currently non-functional against all three real project layouts.** Its splice anchor never received the anchor-scoping fix that landed for `om:scaffold:role` on 2026-08-11, so it still searches for the resource-descriptors closing brace unscoped -- in a real file that closing-brace shape recurs, and it splices into the wrong one, producing invalid TypeScript. The command's own post-write validation catches this and rolls the file back, so it fails safely, but it does not currently produce a usable result. Do not rely on it until the anchor fix ships.
+
+**Common flag:**
+
+| Flag      | Description                                                                  |
+| --------- | ---------------------------------------------------------------------------- |
+| `--write` | Apply the change. Default (omitted) is a dry-run preview -- no files written |
+
+`om:scaffold:ontology` has no `--write` flag; it is always print-only. Each subcommand also has its own identifying flags (`--id`, `--title`, `--system-path`, and so on) -- omit any of them to be prompted interactively. `om:scaffold:fill` is the exception: it is non-interactive and requires `--gaps <path>` pointing at a conformance-gap JSON file.
+
+### om:rename / om:deprecate
+
+Plan or apply an Organization Model system rename cascade, or a lifecycle transition (deprecate/archive). Neither has a `knowledge:*` alias.
+
+```bash
+elevasis-sdk om:rename sales.crm sales.pipeline
+elevasis-sdk om:rename sales.crm sales.pipeline --write
+
+elevasis-sdk om:deprecate sales.crm --to deprecated
+elevasis-sdk om:deprecate sales.crm --to archived --force --confirm archive:sales.crm --write
+```
+
+**Unlike `om:scaffold:*`, both commands default to preview via a real `--dry-run` flag, not the absence of `--write`.** `--write` applies the edit, regenerates knowledge nodes when needed, and runs `om:doctor`. The two conventions on this page name their default state differently -- `om:scaffold:*` has no flag describing its default at all, while `om:rename` / `om:deprecate` spell it out with `--dry-run` -- so do not assume one family's flag shape from the other.
+
+`om:rename` cannot re-parent a system: root-to-nested or nested-to-root moves must be done by hand.
+
+**`om:rename <oldPath> <newPath>` flags:**
+
+| Flag        | Description                                                              |
+| ----------- | ------------------------------------------------------------------------ |
+| `--dry-run` | Preview only (default)                                                   |
+| `--write`   | Apply edits, regenerate knowledge nodes when needed, and run `om:doctor` |
+| `--json`    | Output JSON                                                              |
+
+**`om:deprecate <systemPath>` flags:**
+
+| Flag                  | Description                                                                |
+| --------------------- | -------------------------------------------------------------------------- |
+| `--to <lifecycle>`  | Target lifecycle: `deprecated` or `archived`. Default: `deprecated`        |
+| `--dry-run`           | Preview only (default)                                                     |
+| `--write`             | Apply the lifecycle edit and run `om:doctor`                               |
+| `--force`             | Allow archiving despite live dependents when paired with exact `--confirm` |
+| `--confirm <token>` | Exact archive confirmation token: `archive:<systemPath>`                   |
+| `--json`              | Output JSON                                                                |
+
+**Implementation:** `packages/sdk/src/cli/commands/om/rename.ts`, `packages/sdk/src/cli/commands/om/deprecate.ts` -- registered in `packages/sdk/src/cli/index.ts`
+
 ---
 
 ## elevasis-sdk ui:use-local / ui:use-published
@@ -805,29 +891,112 @@ The same coverage gate runs inside `elevasis-sdk check` when the coverage regist
 
 ---
 
+## elevasis-sdk content:\*
+
+Read and review access to the content platform: content items, their attempts and distributions, the pipeline step contracts they move through, and the one write this namespace owns -- clearing an open `queued` review gate. Producing content -- creating items, recording attempts, opening distributions -- is workflow-side work through the `content` adapter from `@elevasis/sdk/worker`; see `packages/sdk/docs/scaffold/recipes/extend-content.md`. This namespace is the operator surface for the pipeline that adapter feeds, not a second way to write to it.
+
+Matches the DB-backed namespaces documented above (`project:`, `client:`, `note:`, `queue:`, `schedule:`): pretty-printed JSON by default, `--pretty` for human-readable output.
+
+### Command Boundary
+
+- `content:*` is the operator surface for the **content platform System** -- pipelines, items, attempts, and distributions, as documented in `packages/sdk/docs/scaffold/recipes/extend-content.md`. It reads the state a producer workflow is moving an item through, and it clears the review gates a human has to sign off on.
+- `content:*` is **not** the Organization Model's own `System.content` field. That is a generic, retired bridge input every System carries for compatibility and has nothing to do with the content platform System documented here, despite sharing a name.
+- `content:*` is **not** the acquisition domain's own material -- deals, companies, and CRM records reached through `acquisition:*` and `client:*`. A content item can be _about_ an acquisition client (`clientId` on the item), but the content platform does not read or write acquisition records, and `acquisition:*` does not read or write content items.
+- `content:board` renders the same columns, gates, and waiting counts the Command Center board shows, and it is the **same** placement rule rather than a second copy of it. It was deferred until 2026-08-15 because `packages/sdk` has no `@elevasis/ui` dependency and so could not reach `deriveContentBoard`; the fix was to move that helper and `getContentItemIdentity` into `@repo/core/content`, which `@repo/ui` now re-exports. Duplicating the rule inside the CLI was rejected outright -- two copies of a placement rule diverge, which is exactly what happened to the open-review-gate predicate before it was consolidated into `review-gates.ts`.
+
+### Reads
+
+```bash
+elevasis-sdk content:list --status queued --pipeline-id short-form-repurpose
+elevasis-sdk content:get <itemId>
+elevasis-sdk content:board <pipelineId> --pretty
+elevasis-sdk content:queue
+elevasis-sdk content:pipeline
+elevasis-sdk content:pipeline <pipelineId>
+elevasis-sdk content:distributions --pipeline-id short-form-repurpose
+```
+
+- `content:list` -- list content items. Filters: `--status`, `--pillar`, `--pipeline-id`, `--client-id`, `--reviewed-by`, `--search` (matches title), `--limit`, `--offset`.
+- `content:get <itemId>` -- one item plus its full attempt history and its distributions, in a single response. Each attempt carries a `sourceExecutionId`, so this call is the item's execution lineage in one hop -- feed any id straight into `elevasis-sdk execution` / `pnpm exec elevasis execution`.
+- `content:board <pipelineId>` -- one pipeline rendered as columns: each declared step in `order`, each card at the first step its `processingState` has not recorded as `success`, and a gate with a waiting count on every `live` or `queued` step. Two buckets sit outside the columns: `done` (every declared step succeeded) and `unplaced` (the item's `processingState` names only steps the pipeline no longer declares). Unplaced items are never folded into column 1, so a non-empty bucket is a real signal that the step catalog moved underneath live items. `--limit` defaults to 100, the API's page ceiling for this route, and the command reports a **partial** board rather than truncating silently when a pipeline holds more items than one page.
+- `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.
+- `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.
+- `content:distributions` -- list distribution rows (one per platform/format target per item). Filters: `--content-item-id`, `--pipeline-id`, `--platform`, `--status`, `--limit`, `--offset`.
+
+**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`.
+
+### content:review
+
+The one write command 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.
+
+**Synopsis:**
+
+```
+elevasis-sdk content:review <itemId> --step <key> (--approve | --reject) --user <email>
+                            [--feedback <text>] [--reason <text>]
+                            [--prod] [--api-url <url>] [--pretty]
+```
+
+**Flags:**
+
+| Flag                  | Description                                           |
+| --------------------- | ----------------------------------------------------- |
+| `--step <key>`      | Required. The `stepKey` of the `queued` gate to clear |
+| `--approve`           | Approve the item at that step                         |
+| `--reject`            | Reject the item at that step. Requires `--reason`     |
+| `--user <email>`    | Required. The acting reviewer's email                 |
+| `--feedback <text>` | Optional reviewer feedback, recorded on the review    |
+| `--reason <text>`   | Rejection reason. Required when `--reject` is used    |
+| `--api-url <url>`   | Override the API base URL                             |
+| `--pretty`            | Human-readable output instead of raw JSON             |
+
+`--approve` and `--reject` are mutually exclusive; exactly one is required.
+
+**Behavior:**
+
+Posts to `POST /api/external/content/items/:itemId/review`.
+
+**Why `--step` is required.** Nothing makes a `queued` gate pause the pipeline -- a producer workflow can keep moving an item forward while an earlier step's review is still open, so a single item can have several `queued` gates open at the same time. A live run found exactly that: one item ended up with three open gates at once, and resolving the target server-side (by "most recent step-keyed attempt") cleared a step that was not a gate at all. There is no safe way to infer which gate a caller means, so the caller names it. The operator flow is `content:queue` to see which gates are open and each one's `stepKey`, then `content:review <itemId> --step <that key>` to clear the one intended.
+
+**Why `--user` is required.** API keys have no owner -- there is no signed-in user on the API-key path -- and both `content_items.reviewed_by` and `content_item_attempts.created_by` are real foreign keys to `users`. The reviewer's identity has to come from somewhere, so the caller supplies it: `--user` names an email, which must resolve to an active member of the API key's organization.
+
+**Examples:**
+
+```bash
+# Approve a clip-selection gate
+elevasis-sdk content:review 3f9c1e20-... --step clip-selection --approve --user ops@acme.com --pretty
+
+# Reject with a reason
+elevasis-sdk content:review 3f9c1e20-... --step copy-generation --reject --user ops@acme.com --reason "Off-brand tone" --pretty
+```
+
+**Implementation:** `packages/sdk/src/cli/commands/content/`
+
+---
+
 ## Appendix: Domain Status
 
 Current status of all SDK CLI domains. Domains marked `deferred` have no CLI commands yet.
 
-| Domain      | CLI surface                                                                                        | API surface                                                    | Status                        |
-| ----------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | ----------------------------- |
-| platform    | top-level SDK commands                                                                             | mixed platform APIs                                            | implemented                   |
-| project     | `project:*`                                                                                        | `apps/api/src/projects/`                                       | implemented                   |
-| knowledge   | `knowledge:*`                                                                                      | file/generated knowledge data                                  | implemented                   |
-| creds       | `creds *` nested Commander group                                                                   | credentials API                                                | implemented                   |
-| ui          | `ui:*`                                                                                             | local project file edits                                       | implemented                   |
-| request     | `request:submit`, `request:list`, `request:get`                                                    | requests API                                                   | implemented read/write scope  |
-| error       | `error resolve`, `error resolve-execution`                                                         | execution error APIs                                           | partial                       |
-| acquisition | `acquisition:list:*`, `acquisition:deal:*`                                                         | `/api/external/acquisition/lists*`, `/api/external/deals*`     | implemented read-only scope   |
-| client      | `client:*`                                                                                         | `/api/external/clients`                                        | implemented read/write scope  |
-| agent       | `agent:list`, `agent:get`                                                                          | `/api/external/agents*`                                        | implemented read-only scope   |
-| session     | `session:create`, `session:turn`, `session:messages`, `session:list`, `session:get`, `session:end` | `/api/external/sessions*`                                      | implemented multi-turn scope  |
-| queue       | `queue:list`, `queue:get`, `queue:select`, `queue:expire`, `queue:status`                          | `/api/external/command-queue*`                                 | implemented                   |
-| schedule    | `schedule:list`, `schedule:get`, `schedule:create`, `schedule:update`                              | `/api/external/task-scheduler/schedules*`                      | implemented                   |
-| skill       | `skill:scaffold`, `skill:check-coverage`                                                           | local CLI catalog and `.claude/registries/skill-coverage.json` | implemented developer tooling |
-| content     | none                                                                                               | not scoped here                                                | deferred                      |
-| seo         | none                                                                                               | not scoped here                                                | deferred                      |
-| monitoring  | none                                                                                               | not scoped here                                                | deferred                      |
+| Domain      | CLI surface                                                                                                                    | API surface                                                    | Status                                |
+| ----------- | ------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------- | ------------------------------------- |
+| platform    | top-level SDK commands                                                                                                         | mixed platform APIs                                            | implemented                           |
+| project     | `project:*`                                                                                                                    | `apps/api/src/projects/`                                       | implemented                           |
+| knowledge   | `knowledge:*`                                                                                                                  | file/generated knowledge data                                  | implemented                           |
+| creds       | `creds *` nested Commander group                                                                                               | credentials API                                                | implemented                           |
+| ui          | `ui:*`                                                                                                                         | local project file edits                                       | implemented                           |
+| request     | `request:submit`, `request:list`, `request:get`                                                                                | requests API                                                   | implemented read/write scope          |
+| error       | `error resolve`, `error resolve-execution`                                                                                     | execution error APIs                                           | partial                               |
+| acquisition | `acquisition:list:*`, `acquisition:deal:*`                                                                                     | `/api/external/acquisition/lists*`, `/api/external/deals*`     | implemented read-only scope           |
+| client      | `client:*`                                                                                                                     | `/api/external/clients`                                        | implemented read/write scope          |
+| agent       | `agent:list`, `agent:get`                                                                                                      | `/api/external/agents*`                                        | implemented read-only scope           |
+| session     | `session:create`, `session:turn`, `session:messages`, `session:list`, `session:get`, `session:end`                             | `/api/external/sessions*`                                      | implemented multi-turn scope          |
+| queue       | `queue:list`, `queue:get`, `queue:select`, `queue:expire`, `queue:status`                                                      | `/api/external/command-queue*`                                 | implemented                           |
+| schedule    | `schedule:list`, `schedule:get`, `schedule:create`, `schedule:update`                                                          | `/api/external/task-scheduler/schedules*`                      | implemented                           |
+| skill       | `skill:scaffold`, `skill:check-coverage`                                                                                       | local CLI catalog and `.claude/registries/skill-coverage.json` | implemented developer tooling         |
+| content     | `content:list`, `content:get`, `content:board`, `content:queue`, `content:pipeline`, `content:distributions`, `content:review` | `/api/external/content*`                                       | implemented read + review-write scope |
+| seo         | none                                                                                                                           | not scoped here                                                | deferred                              |
+| monitoring  | none                                                                                                                           | not scoped here                                                | deferred                              |
 
 ### Promotion Criteria
 
@@ -840,4 +1009,4 @@ A domain should meet all four criteria before gaining a `*:list` / `*:get` surfa
 
 ---
 
-**Last Updated:** 2026-05-19
+**Last Updated:** 2026-08-14

package/reference/sdk/cli.mdx

@@ -39,11 +39,7 @@ elevasis-sdk check
   - Relationship declarations referencing non-existent resources
 - Exits with code 0 on success, code 1 on validation failure
 
-**Flags:**
-
-| Flag                | Description               |
-| ------------------- | ------------------------- |
-| `--api-url <url>` | Override the API base URL |
+`check` declares no `--api-url` flag -- it validates project source locally and never calls the API, so there is no base URL to override.
 
 **Example output (success):**
 
@@ -88,10 +84,10 @@ elevasis-sdk deploy
 
 **Flags:**
 
-| Flag                | Description                                                               |
-| ------------------- | ------------------------------------------------------------------------- |
-| `--api-url <url>` | Override the API base URL (default: production)                           |
-| `--prod`            | Force production target, overriding `NODE_ENV=development` (internal use) |
+| Flag                | Description                                                |
+| ------------------- | ---------------------------------------------------------- |
+| `--api-url <url>` | Override the API base URL (default: production)            |
+| `--prod`            | Force production target, overriding `NODE_ENV=development` |
 
 **Environment variables:**
 
@@ -320,6 +316,84 @@ elevasis-sdk execution onboard-client exec_abc001
 
 ---
 
+## elevasis-sdk execution:cancel
+
+Cancel a running execution.
+
+**Synopsis:**
+
+```
+elevasis-sdk execution:cancel <resourceId> <executionId>
+```
+
+**Behavior:**
+
+- Calls `POST /api/external/executions/:resourceId/:executionId/cancel`
+- The result reports which method was used: an in-memory signal if the execution's worker process is still reachable, or a database fallback if not
+- A 409 response means the execution is not in a running state -- it already finished. That is a normal race, not a command failure
+
+**Flags:**
+
+| Flag                | Description                                          |
+| ------------------- | ---------------------------------------------------- |
+| `--prod`            | Target production (overrides `NODE_ENV=development`) |
+| `--api-url <url>` | Override the API base URL                            |
+| `--json`            | Output raw JSON response                             |
+
+**Example:**
+
+```bash
+elevasis-sdk execution:cancel my-workflow 9c47c944-67eb-4c84-98cb-bb951d05ede3
+```
+
+```
+  Execution cancelled
+    Resource:     my-workflow
+    Execution ID: 9c47c944-67eb-4c84-98cb-bb951d05ede3
+    Method:       in-memory signal
+```
+
+**Implementation:** `packages/sdk/src/cli/commands/execution-cancel.ts`, registered in `packages/sdk/src/cli/index.ts`
+
+---
+
+## elevasis-sdk executions:delete
+
+Delete a resource's execution history (destructive).
+
+**Synopsis:**
+
+```
+elevasis-sdk executions:delete <resourceId> [--force]
+```
+
+**Behavior:**
+
+- Calls `DELETE /api/external/executions/:resourceId`
+- Requires a typed `DELETE` confirmation at an interactive prompt unless `--force` is passed
+- `--resource-status <status>` (`dev` or `prod`) scopes the delete to runs from one deployment lane only
+- `--json` without `--force` is a hard error -- it throws `executions:delete requires --force when --json is set`, because a JSON caller is assumed non-interactive and there is nothing to answer the confirmation prompt
+
+**Flags:**
+
+| Flag                           | Description                                                  |
+| ------------------------------ | ------------------------------------------------------------ |
+| `--prod`                       | Target production (overrides `NODE_ENV=development`)         |
+| `--api-url <url>`            | Override the API base URL                                    |
+| `--resource-status <status>` | Only delete runs from this deployment lane (`dev` | `prod`) |
+| `--force`                      | Skip the typed confirmation prompt                           |
+| `--json`                       | Output raw JSON response                                     |
+
+**Example:**
+
+```bash
+elevasis-sdk executions:delete my-workflow --force
+```
+
+**Implementation:** `packages/sdk/src/cli/commands/executions-delete.ts`, registered in `packages/sdk/src/cli/index.ts`
+
+---
+
 ## elevasis-sdk deployments
 
 List all deployments for your organization.
@@ -541,7 +615,8 @@ elevasis-sdk cli [domain] [--format markdown|json]
 | --------------------- | ----------------------------------------------------------- |
 | `--domain <domain>` | Filter output to one domain (alternative to positional arg) |
 | `--format <format>` | Output format: `markdown` (default) or `json`               |
-| `--api-url <url>`   | Override the API base URL                                   |
+
+`cli` declares no `--api-url` flag -- it walks the locally registered Commander command graph and never calls the API.
 
 **Examples:**
 
@@ -579,7 +654,7 @@ Check that your Elevasis project is correctly configured.
 **Synopsis:**
 
 ```
-elevasis-sdk doctor [--verbose]
+elevasis-sdk doctor [--verbose] [--prod]
 ```
 
 **Behavior:**
@@ -596,6 +671,7 @@ Runs four sequential checks and reports `[OK]` / `[FAIL]` / `[WARN]` for each. E
 | Flag        | Description                                                         |
 | ----------- | ------------------------------------------------------------------- |
 | `--verbose` | Print full paths, response bodies, and error details for each check |
+| `--prod`    | Report against production (overrides `NODE_ENV=development`)        |
 
 **Example output (all passing):**
 
@@ -623,14 +699,15 @@ These flags are accepted by all commands:
 | ------------------- | --------------------------------------------------------------------------------------------------- |
 | `--api-url <url>` | Override the API base URL. Priority: flag > `ELEVASIS_API_URL` env var > `NODE_ENV`-based default |
 | `--json`            | Output raw JSON (available on most commands)                                                        |
+| `--prod`            | Target production, overriding `NODE_ENV=development`                                                |
 
 **API base URL resolution:**
 
 - Production (default): `https://api.elevasis.io`
 - Development (`NODE_ENV=development`): `http://localhost:<port>`
 - Override: set `ELEVASIS_API_URL` or pass `--api-url`
-- Force production: pass `--prod` on `deploy` (overrides `NODE_ENV=development`)
+- Force production: pass `--prod` after the command name on any authenticated command (overrides `NODE_ENV=development`). Live as of `@elevasis/sdk` 1.45.0; `--api-url https://api.elevasis.io` is the equivalent form on older installs.
 
 ---
 
-**Last Updated:** 2026-05-19
+**Last Updated:** 2026-08-12

package/reference/sdk/framework/agent.mdx

@@ -67,6 +67,12 @@ There is no `/meta`, `/docs`, or `/work` skill. The template's own boundary guid
 
 **`/git-sync`** -- Pulls the latest template changes, checks the installed `@elevasis/sdk` version against the declared range, reinstalls if the dependency baseline changed, and runs baseline verification (`ui check-types`, `ui build`, `operations check`, `operations check-types`). It stops after verifying -- it never auto-reconciles template drift or overwrites project-owned files. Release guidance is not delivered here; it ships inside the `@elevasis/sdk` reference bundle, which is always current for your installed version.
 
+On a green verification it also **bumps your app version**. The literal lives in `ui/src/config/app-version.ts` (exported as `APP_VERSION`, consumed by `ui/src/config/app-config.ts` and rendered in the topbar), and the agent picks the segment by judging the whole run: **minor** for new capability or a changed `@elevasis/*` dependency baseline, **patch** for everything else. **Major is never automatic** -- if a run genuinely looks major the report says so and leaves the version alone.
+
+The gate is **outgoing commits**, checked with `git rev-list --count @{u}..HEAD` before the bump commit is written. Nothing deploys off a run with nothing to push, so a pull-only run reports `Version: unchanged (nothing to push)` while a run with local commits and an empty pull does bump. The bump lands as its own `chore(ui): bump app version to x.y.z` commit and is not pushed. It is skipped when there is no upstream, when the pull or verification failed, when the project has no `ui/src/config/app-version.ts`, and inside the template itself.
+
+`app-version.ts` is a separate file from `app-config.ts` deliberately. It is registered `never-touch` / `verify-only`, so the sync engine protects your value; folding it back into `app-config.ts` -- a critical manual-merge surface -- would flag every project as behind the template on every sync for a difference that is working as intended.
+
 **`/tutorial`** -- Persona-aware onboarding; see [Tutorial System](tutorial-system.mdx) for the full lesson breakdown.
 
 ## The Ambient Vibe Layer

package/reference/sdk/platform-tools/adapters-platform.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Platform Adapters"
-description: "Auto-generated table of all 12 platform (singleton, no credential) adapters exported from @elevasis/sdk/worker, derived from static analysis of the adapter source files."
+description: "Auto-generated table of all 14 platform (singleton, no credential) adapters exported from @elevasis/sdk/worker, derived from static analysis of the adapter source files."
 ---
 
 {/* @generated by .claude/_gen/sync-sdk-adapters.ts — DO NOT EDIT */}
@@ -22,3 +22,5 @@ Platform adapters are singletons — import them directly, no credential require
 | Approval | `approval` | `create`, `deleteByMetadata` | Approval — create and manage HITL (human-in-the-loop) tasks. |
 | Execution | `execution` | `trigger`, `triggerAsync` | Execution — trigger other workflows or agents within the same organization. |
 | Email | `email` | `send` | Email — send platform emails (from notifications@elevasis.io) to organization members. |
+| Artifacts | `artifacts` | `listArtifacts`, `createArtifact`, `getActive` | Artifacts — org-scoped governing-document store for rules documents, idea banks, and ICP docs. |
+| Content | `content` | `createItem`, `getItem`, `listItems`, `updateItem`, `createAttempt`, `listAttempts`, `updateAttempt`, `createSourceAsset`, `getSourceAsset`, `listSourceAssets`, `updateSourceAsset`, `createDistribution`, `updateDistribution` | Content — create and query content_items/content_item_attempts/content_distributions rows for the content pipeline. |

package/reference/sdk/platform-tools/index.mdx

@@ -191,8 +191,6 @@ const qualified = await platform.call({
 
 **Credential setup:** Create a credential with provider `supabase` -- config fields are `url` and `serviceRoleKey`. Workflows always use the service role key (server-side, no RLS).
 
-**`/database init`:** Guided setup that stores your Supabase credential, generates `data/schema.ts`, and creates `docs/database.mdx`.
-
 ---
 
 ## Documentation

package/reference/sdk/resources/patterns.mdx

@@ -449,7 +449,7 @@ The platform's HITL mechanism works in two parts: your workflow code creates an
 
 ### Creating approval tasks
 
-Call `approval.create()` from any workflow step to pause execution and emit a task to the Command Queue:
+Call `approval.create()` from any workflow step to emit a task to the Command Queue. It does **not** pause or suspend the step -- it inserts a row into `command_queue` and returns `{ id }`, and the workflow keeps running to completion:
 
 {/* doc-snippet:skip: illustrative excerpt -- dealId/proposalUrl are shorthand for values from the enclosing step handler's input, not a standalone compilable file */}
 
@@ -458,19 +458,27 @@ import { approval } from '@elevasis/sdk/worker'
 
 const task = await approval.create({
   actions: [
-    { id: 'approve', label: 'Approve', type: 'primary' },
+    {
+      id: 'approve',
+      label: 'Approve',
+      type: 'primary',
+      target: { resourceType: 'workflow', resourceId: 'send-proposal' },
+    },
     { id: 'reject', label: 'Reject', type: 'danger' },
   ],
   context: { dealId, proposalUrl },
   description: 'Review proposal before sending',
 })
 
-if (task.actionId === 'approve') {
-  // continue with approved path
-}
+// task is only `{ id: string }` -- the new command_queue row's id.
+// There is no `task.actionId` to branch on here.
 ```
 
-The workflow step suspends at `approval.create()` and resumes only after a reviewer submits an action. See [Platform Adapters](../platform-tools/adapters-platform.mdx) for the full `approval.create()` reference.
+**There is no resumption.** This workflow step -- and the whole workflow -- runs to completion and terminates normally right after `approval.create()` returns. When a reviewer later submits an action from the Command Queue, the API starts a **brand-new execution** of the workflow named in that action's `target`, with input `{ ...task.context, actionId, actionPayload }`. The original execution is not revived and cannot be branched on.
+
+The consequence for anything you write: state your workflow needs once the reviewer's decision comes back cannot live in a local variable -- the process holding it already exited. Put everything the follow-up execution needs into `context` (it comes back verbatim as part of that execution's input), or persist it somewhere the new execution can look up by id.
+
+See [Platform Adapters](../platform-tools/adapters-platform.mdx) for the full `approval.create()` reference.
 
 ### Built-in Command Center handling
 

package/reference/ui/exports.mdx

@@ -20,6 +20,7 @@ description: "Auto-generated catalog of all published @elevasis/ui subpath expor
 | `@elevasis/ui/organization` | Organization | Foundation | Published organization shell, store, and helper surface. |
 | `@elevasis/ui/features/auth` | Features Auth | Features | Published auth feature surface for downstream shells. |
 | `@elevasis/ui/features/clients` | Features Clients | Features | Published clients feature surface for downstream shells. |
+| `@elevasis/ui/features/content` | Features Content | Features | Published, data-free content review card surface (ContentReviewCard and its sub-components) for downstream shells. |
 | `@elevasis/ui/features/crm` | Features CRM | Features | Published CRM feature surface for downstream shells. |
 | `@elevasis/ui/features/dashboard` | Features Dashboard | Features | Published dashboard feature surface for downstream shells. |
 | `@elevasis/ui/features/delivery` | Features Delivery | Features | Published delivery feature surface for downstream shells. |