@elevasis/sdk 1.33.1 → 1.34.1

package/reference/claude-config/sync-notes/2026-06-05-ontology-endpoint-rename-and-knowledge-browser-ui.md

@@ -0,0 +1,86 @@
+# Ontology `surface` → `endpoint` rename + Knowledge Browser UI upgrades
+
+## Why this note exists
+
+This release bumps **both** `@elevasis/core` and `@elevasis/ui`. Two distinct changes ride it:
+
+1. **Breaking OM contract rename (`@elevasis/core`).** The ontology kind `surface` was renamed to
+   `endpoint` to stop colliding with **navigation surfaces** (shell sidebar routes). The published
+   contract changed: the `OntologyKind` enum member `'surface'` is now `'endpoint'`, the ontology ID
+   namespace `…:surface/…` is now `…:endpoint/…`, `ontology.surfaces` is now `ontology.endpoints`,
+   and the exported `OntologySurfaceType` / `OntologySurfaceTypeSchema` are now
+   `OntologyEndpointType` / `OntologyEndpointTypeSchema`. **There is no back-compat alias** (hard
+   rename — the kind was near-dormant). Any tenant OM that still declares a `:surface/` **ontology**
+   ID will fail validation once it installs the new `@elevasis/core`.
+
+2. **Knowledge Browser UI upgrades (`@elevasis/ui`).** Three additive, platform-substrate
+   enhancements that tenants get purely on the `@elevasis/ui` bump — no authoring change required:
+   full `ClientProfile` detail rendering in the Clients panel, clickable group child cards
+   (Profile → Identity/Branding navigate like the tree), and explanatory hover tooltips on
+   platform-vocabulary badges/edge labels. The ontology tree row + its tooltip now read
+   **"Endpoints"** instead of "Surfaces", consistent with change #1.
+
+## Applies to
+
+- **Change #1 (ontology rename):** every tenant whose `core/config/organization-model/` declares any
+  ontology ID with a `:surface/` segment (i.e. an entry under a System's `ontology.surfaces`).
+  **Confirmed in this train: ZERO live tenants carry any `:surface/` ontology ID** (verified by a
+  repo-wide grep across all of `external/` — only `_template` carried one, migrated in this train).
+  The 3 live derived projects (ZentaraHQ, nirvana-marketing, contemplative-records) inherit
+  `endpoint/` cleanly. Run the verification below anyway before installing the new `@elevasis/core`.
+- **Change #2 (UI upgrades):** every template-derived project — they render on the `@elevasis/ui`
+  bump with no further action.
+
+## Required actions
+
+`/git-sync` / `/external sync` delivers the new `@elevasis/core` + `@elevasis/ui` dependency
+baselines and this note. The dependency bumps install automatically; the ontology-ID rewrite (only if
+your project authored any) is project-owned OM content and is **not** auto-applied.
+
+1. **Install the baselines together.** Bump `@elevasis/core` and `@elevasis/ui` in the same change
+   (the baseline write from sync covers `core/package.json`, `operations/package.json`, and
+   `ui/package.json`). Do not install the new `@elevasis/core` while your OM still has any `:surface/`
+   **ontology** ID.
+2. **Rename any ontology `surface/` IDs (only if present).** In `core/config/organization-model/`,
+   change every ontology ID `…:surface/<name>` to `…:endpoint/<name>`, and the containing
+   `ontology: { surfaces: { … } }` key to `ontology: { endpoints: { … } }`. Update every
+   cross-reference (`ownerSystemId`, `route`, links, etc.). Most tenants have nothing to change here.
+3. **Do NOT touch navigation surfaces.** This is the critical disambiguation. The rename is
+   ontology-only. Leave `system.surfaces`, `ui.surfaces`, sidebar `SidebarSurfaceNode`s, the
+   `surfaceType` route field, the graph node kind `surface`, and `SurfaceDescribeView` **unchanged** —
+   those legitimately own the word "surface" for shell routing and are orthogonal to the ontology kind.
+4. **Update tests.** If your `core/config/organization-model.test.ts` or contract tests assert
+   `compiled.ontology.surfaces` or a `:surface/` ontology ID, rename them to `.endpoints` /
+   `:endpoint/`. Leave any `ui.surfaces` / navigation-surface assertions alone.
+5. **Verify, then boot.** Run the verification block, then `pnpm -C core test` and
+   `pnpm -C ui check-types` before booting the app.
+
+## Verification
+
+```bash
+# 1. Find any remaining ontology surface/ IDs (navigation surfaces are fine — see discriminator)
+grep -rn ":surface/\|ontology.surfaces\|OntologySurfaceType" core/config/organization-model
+
+# Discriminator while reading hits:
+#   ontology (RENAME)  -> a ":surface/" ID segment, "ontology: { surfaces: ... }", OntologySurface*
+#   navigation (KEEP)  -> bare system.surfaces / ui.surfaces, SidebarSurface*, surfaceType
+
+# 2. Template-family coherence
+pnpm -C core test
+pnpm -C ui check-types
+pnpm -C ui test:contracts
+
+# 3. Boot must not throw OM validation (no unknown OntologyKind)
+```
+
+`OntologyKindSchema` must accept `endpoint` and reject `surface`; no `:surface/` ontology ID may
+remain. Navigation surfaces must still resolve and render in the sidebar.
+
+## Not handled by /git-sync
+
+- `/git-sync` and `/external sync` deliver the `@elevasis/core` + `@elevasis/ui` dependency baselines
+  and this note, but they do **not** edit your `core/config/organization-model/` — tenant OM content
+  is project-owned (`sync-preservation`). The `surface/` → `endpoint/` ontology-ID rewrite in steps
+  2–4 is manual per tenant (a no-op for every current live tenant, which carries none).
+- The Knowledge Browser UI upgrades (change #2) require **no** action — they are entirely inside
+  `@elevasis/ui` and appear on the bump.

package/reference/claude-config/sync-notes/2026-06-06-om-build-systems-scaffold.md

@@ -0,0 +1,47 @@
+# /om build system scaffold added to tenant template
+
+## Why this note exists
+
+The monorepo added a guided `/om build` operation (Steps 2-3 of the Building-Systems Scaffold
+task) that sequences the full platform runbook for authoring an Organization Model System end
+to end. This train mirrors a thinner, Codify-ceremony-framed variant of that operation into the
+tenant template. Tenant projects author OM via the Codify ceremony (not the platform PR-review
+runbook), so the tenant variant is scoped accordingly.
+
+Changes in this train:
+
+- New operation file `.claude/skills/om/operations/build.md` (Codify-framed, 8 phases).
+- `metadata.promptSignals` in `.claude/skills/om/SKILL.md` extended with four build-intent
+  phrases: `build a system`, `design a system`, `create a system that`, `system architecture`.
+- `## Operations` table added to `.claude/skills/om/SKILL.md` with the `build` EXECUTE row.
+- Build-intent routing branch added to the Decision Tree section of `SKILL.md` so free-text
+  build intent routes to `/om build` before the 5-bucket read/write buckets.
+
+## Applies to
+
+- All template-derived projects that ship the `om` skill (`.claude/skills/om/SKILL.md`).
+- Any project where an agent might express intent to build or design a new System.
+
+## Required actions
+
+1. Pull template changes so the new `build.md` operation file and the updated `SKILL.md` are
+   present in `.claude/skills/om/`.
+2. No package baseline bumps required -- this is a pure agent-scaffold change (no published
+   package version involved).
+3. No `pnpm install` needed unless the `/git-sync` pull also brings unrelated baseline changes.
+
+## Verification
+
+- `.claude/skills/om/operations/build.md` is present.
+- `.claude/skills/om/SKILL.md` contains the `build` row in the `## Operations` table.
+- `.claude/skills/om/SKILL.md` `metadata.promptSignals.phrases` includes `build a system`,
+  `design a system`, `create a system that`, and `system architecture`.
+- Saying "build a system for lead gen" in chat triggers `/om` and routes to `/om build` without
+  requiring the explicit `/om build` subcommand.
+
+## Not handled by /git-sync
+
+- No dependency bumps or `pnpm install` required for this change alone.
+- Any project-local documentation that references how to add a new System should be updated by
+  the maintainer to point at `/om build` as the guided entry point rather than manual Codify
+  Level-A alone.

package/reference/claude-config/sync-notes/2026-06-06-om-item-copy-references.md

@@ -0,0 +1,50 @@
+# Knowledge Browser item copy-references now resolve via `om:describe item:<domain>:<id>`
+
+## Why this note exists
+
+The Knowledge Browser used to copy an unresolvable `graph:<kind>:<uuid>` shorthand for
+domain items (clients, roles, policies, customers, offerings, goals). Pasting that to an
+agent led to dead ends — the OM resolver had no mount for it and `om:describe` rejected the
+id. This train (published `@elevasis/core`, `@elevasis/sdk`, `@elevasis/ui` + the bundled
+`om` skill) standardizes domain-item copy references on `item:<domain>:<id>`, which resolves
+to the rich profile plus its location and governing knowledge. The `om` skill's read-folder
+table and CLI invocation guidance changed, so derived projects must pick up the new skill
+text and package baselines.
+
+## Applies to
+
+- All template-derived projects that ship the `om` skill (`.claude/skills/om/SKILL.md`).
+- Any project whose Knowledge Browser surfaces domain items (clients, roles, policies,
+  customers, offerings, goals).
+- Agents that consume copied Knowledge Browser references.
+
+## Required actions
+
+1. Pull template changes and bump the published package baselines to the versions shipped by
+   this train: `@elevasis/core`, `@elevasis/sdk`, `@elevasis/ui` (run `pnpm install` after the
+   baseline bump so the new SDK CLI and UI copy behavior are present).
+2. Adopt the refreshed `.claude/skills/om/SKILL.md` read-folder table. It now documents
+   `item:<domain>:<id>` (resolves via `om:describe item:<domain>:<id>`), the `/by-domain/<domain>`
+   and `/by-item/<domain>/<id>` `om:ls` mounts, `group:` / `domain:` / `folder:` as
+   browser-overview references, and a legacy `graph:client:<uuid>` bridge note pointing to
+   `om:describe item:clients:<uuid>`.
+3. Use the corrected SDK CLI invocation at a project root: `pnpm elevasis-sdk om:describe …`
+   (root script alias) or `pnpm -C operations exec elevasis-sdk om:describe …`. The old
+   `pnpm exec elevasis-sdk …` at the project root fails in a multi-package tenant — replace it.
+
+## Verification
+
+- `pnpm elevasis-sdk om:describe item:clients:<id>` returns the client profile, its location
+  (domain + graph id + `contains` parentage), and any governing knowledge — no dead ends.
+- A bare/legacy `om:describe client:<uuid>` still resolves (back-compat for already-copied
+  references).
+- `pnpm sync:verify -- <project>` shows the `.claude/skills/om/SKILL.md` write applied and no
+  remaining `om`-skill drift.
+
+## Not handled by /git-sync
+
+- The published-package baseline bumps (`@elevasis/core` / `@elevasis/sdk` / `@elevasis/ui`)
+  and the subsequent `pnpm install` are manual — `/git-sync` does not bump dependencies.
+- Any project-local documentation that hand-copied the old `pnpm exec elevasis-sdk` root
+  invocation or the old `graph:<kind>:<uuid>` copy vocabulary must be corrected by the
+  maintainer; `/git-sync` stops before touching project-owned surfaces.

package/reference/claude-config/sync-notes/2026-06-08-knowledge-base-page-not-found-fix.md

@@ -0,0 +1,76 @@
+# Knowledge Base "Page Not Found" hardening (KB `$nodeId` route)
+
+## Why this note exists
+
+The Knowledge Base detail route (`ui/src/routes/knowledge/$nodeId.tsx`) could render a
+terminal full-pane **"Page Not Found"** screen for node ids it could not resolve. Two
+distinct gaps caused it:
+
+1. **No `folder:` branch.** Selecting a KB **folder** node (e.g. the `KNOWLEDGE > All`
+   folder) navigates to `/knowledge/folder:knowledge:all`. The route matched none of the
+   `domain:` / `group:` / `item:` prefixes, resolved to no graph node, and fell through to
+   a bare `<PageNotFound />`. The folder routing (`folder:` → `FolderDetailView`) was
+   missing from the template route entirely.
+2. **Two hard-404 landmines.** The `!group` and `!node` fall-through branches returned
+   `<PageNotFound />`, so any stale bookmark, renamed ontology id, or snapshot drift
+   dead-ended the whole content pane.
+
+This train delivers the hardened route that **always renders browsable content** for any
+node id. There is **no package bump** — the fix consumes only `@elevasis/ui` exports your
+project already has at `@2.49.0+` (`KnowledgeBrowser`, `buildKnowledgeOmTreeData`,
+`findKnowledgeTreeNodeByValue`, `KnowledgeTreeNodeData`).
+
+## Applies to
+
+- Every template-derived project whose `ui/src/routes/knowledge/$nodeId.tsx` is still the
+  pre-fix version (no `folder:` branch, bare `PageNotFound` returns). If your KB renders
+  "Page Not Found" when the `All` (or any) folder node is selected, you are affected.
+- No action is required for projects that have already customized this route to handle
+  folders and avoid hard 404s — the sync is a `merge-baseline` that **preserves your local
+  route edits** (`external-sync-feature-route-baseline`, `sync_lane_severity:
+optional-feature-selection`).
+
+## Required actions
+
+`/git-sync` / `/external sync` delivers the hardened route as a baseline merge and surfaces
+this note. The route is project-owned baseline content under the route-preservation lane,
+so it is **merged, not force-overwritten** — review the merge if you carry local
+customizations.
+
+1. **Pull and review.** Run `/git-sync` (or `/external sync`) and review the merge into
+   `ui/src/routes/knowledge/$nodeId.tsx`. Accept the two changes: the new `folder:` →
+   `FolderDetailView` branch, and the replacement of both `<PageNotFound />` returns with a
+   `KnowledgeNodeFallback` (a subtle "not available" `Alert` plus the full
+   `KnowledgeBrowser`).
+2. **No dependency change.** `@elevasis/ui` does **not** need bumping for this fix; the
+   required exports are already published. Do not add a package bump to this sync.
+3. **Type-check, then boot.** Run `pnpm -C ui lint` (`tsc --noEmit`), then start the UI.
+
+## Verification
+
+```bash
+# 1. The route must no longer return a bare PageNotFound
+grep -n "PageNotFound" ui/src/routes/knowledge/$nodeId.tsx
+#   Expect: no terminal `return <PageNotFound />` in the content branches
+#   (a folder: branch + KnowledgeNodeFallback should be present instead)
+
+# 2. Required @elevasis/ui exports are present at your installed version
+grep -n "KnowledgeBrowser\|buildKnowledgeOmTreeData\|findKnowledgeTreeNodeByValue" \
+  ui/src/routes/knowledge/$nodeId.tsx
+
+# 3. Template-family coherence
+pnpm -C ui lint
+```
+
+In the running app, select the `KNOWLEDGE > All` folder node (and any other folder/group
+node): the content pane must render browsable Knowledge content, never a full-pane
+"Page Not Found".
+
+## Not handled by /git-sync
+
+- `/git-sync` / `/external sync` deliver and merge the route baseline plus this note, but
+  they do **not** redeploy your UI. Reaching your live app requires your own UI **redeploy**
+  after the sync merge is accepted.
+- Local customizations to `ui/src/routes/knowledge/$nodeId.tsx` are preserved by the
+  `merge-baseline` lane — if you maintain a forked KB route, reconcile the `folder:` branch
+  and the `KnowledgeNodeFallback` into your version by hand rather than discarding your edits.

package/reference/claude-config/sync-notes/2026-06-09-agent-sessions-public-agent-chat-route.md

@@ -0,0 +1,75 @@
+# Agent Sessions and public agent chat route
+
+## Why this note exists
+
+This train makes `Agent Sessions` the canonical internal full-page chat surface and
+introduces the browser-safe public agent chat substrate. Public browser clients use
+platform-issued access grants and short-lived capability tokens; they must not call
+server-to-server session APIs with platform API keys.
+
+The shared public chat UI is published from `@elevasis/ui/features/public-agent-chat`.
+The tenant route is authored after the UI package publish, then propagated through the
+strict manifest sync.
+
+The template Organization Model now also declares the `operations-sessions` navigation
+surface (`/operations/sessions`). That lets template-derived tenants inherit the
+standard Agent Sessions page or opt into the same surface from their own OM navigation
+without hand-authoring a route.
+
+## Applies to
+
+- Template-derived projects that want public or code-gated agent chat links.
+- Projects syncing the template route baseline after the `@elevasis/ui` package baseline
+  is bumped.
+- Projects that want the internal Agent Sessions page exposed through OM-authored
+  navigation.
+
+## Required actions
+
+1. Accept the package baseline updates for `@elevasis/core` and `@elevasis/ui`.
+2. Accept the new public chat route baseline once it appears in
+   `ui/src/routes/chat.$slug.tsx` and any root-shell adjustment needed to keep that route
+   outside the authenticated app shell.
+3. If your project customizes `core/config/organization-model/navigation.ts`, merge the
+   `operations-sessions` surface into the Operations group:
+
+```ts
+'operations-sessions': {
+  type: 'surface',
+  label: 'Agent Sessions',
+  path: '/operations/sessions',
+  surfaceType: 'list',
+  order: 30
+}
+```
+
+4. Run the project UI install and typecheck/build after sync:
+
+```bash
+pnpm -C ui install
+pnpm -C ui check-types
+pnpm -C ui build
+```
+
+5. Configure platform-side public agent access grants before sharing a public chat URL.
+
+## Verification
+
+After sync, verify the OM exposes the Agent Sessions navigation surface:
+
+```bash
+grep -n "operations-sessions\\|Agent Sessions\\|/operations/sessions" core/config/organization-model/navigation.ts
+pnpm -C core test
+```
+
+## Security notes
+
+- Browser code must use the public grant/capability-token flow.
+- Do not expose `ELEVASIS_PLATFORM_KEY` or operations API keys in browser code.
+- Public turns use the public WebSocket route backed by a capability token.
+
+## Not handled by /git-sync
+
+`/git-sync` does not create production access grants, choose which agents are public,
+merge project-owned OM customizations automatically, or redeploy tenant UIs. Those are
+project/operator decisions after the code and package baselines are accepted.

package/reference/claude-config/sync-notes/2026-06-09-sdk-cli-load-org-model-resolution.md

@@ -0,0 +1,42 @@
+# SDK CLI `om:*` tenant Organization Model loader fix
+
+## Why this note exists
+
+The `@elevasis/sdk` CLI `om:*` read commands could return an empty model in standard
+template-derived pnpm-workspace projects even when `core/config/organization-model.ts`
+contained real systems and resources. The loader resolved `esbuild` and external
+package imports from the project root, but template projects install SDK runtime
+dependencies under `operations/`.
+
+This train publishes an SDK loader fix. Tenant source does not need to change, but
+`operations/package.json` must pick up the new `@elevasis/sdk` baseline.
+
+## Applies to
+
+- Template-derived projects that run `elevasis-sdk om:ls`, `om:search`, `om:describe`,
+  `om:cat`, `om:graph`, or `om:skills` from `operations/`.
+- Projects whose `om:*` output is unexpectedly empty despite a valid
+  `core/config/organization-model.ts`.
+
+## Required actions
+
+1. Accept the `operations/package.json` `@elevasis/sdk` baseline bump delivered by
+   `/external sync`.
+2. Run the operations install after the sync so the published CLI binary is updated.
+
+## Verification
+
+Verify the tenant model loads from the published CLI:
+
+```bash
+pnpm -C operations exec elevasis-sdk om:ls /all-systems
+```
+
+The command should list the tenant's authored systems instead of returning an empty
+result.
+
+## Not handled by /git-sync
+
+`/git-sync` pulls template guidance into a derived project. It does not publish the SDK,
+install dependencies inside every standalone project, or redeploy any project. Run the
+project-local install and deployment steps after accepting the sync.

package/reference/sdk/cli-management.mdx

@@ -1,12 +1,48 @@
 ---
 title: CLI Management Commands
-description: elevasis-sdk management commands -- project, note, acquisition, client, agent, session, queue, schedule, om, and ui subcommand families
+description: elevasis-sdk management commands -- project, note, acquisition, client, agent, session, queue, schedule, om, ui, and skill 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).
 
 ---
 
+## JSON-valued options
+
+Any option that expects JSON can take inline JSON or a file reference:
+
+```bash
+elevasis-sdk queue:select <id> --action-id approve --payload @json:tmp/queue-payload.json
+elevasis-sdk schedule:create --name "Weekly report" --target-resource-type workflow --target-resource-id weekly-report --schedule-config @json:tmp/schedule-config.json
+elevasis-sdk project:task:save <id> --current-state "Updated" --files-modified @json:tmp/files-modified.json
+```
+
+`@json:<path>` is expanded before command parsing, so existing command handlers receive the same JSON string they would receive from an inline argument. Relative paths resolve against the Elevasis project root when the current directory is inside a project; otherwise they resolve against the current working directory. The referenced file must contain valid JSON.
+
+Use `@json:<path>` for generated payloads, nested objects, arrays, or Windows shells. Inline JSON remains supported for small values.
+
+### Passing JSON arguments across shells
+
+Agents launch `elevasis-sdk` from either bash or PowerShell, so JSON quoting guidance must hold for both. A JSON argument crosses two parsers before the CLI sees it:
+
+1. **The outer shell** (bash or PowerShell) -- decides whether embedded `"` survive.
+2. **The pnpm run-script layer** -- `pnpm elevasis-sdk ...` is an npm run-script. On Windows, pnpm runs scripts through `cmd.exe /c`, which re-parses arguments. `pnpm exec elevasis-sdk` and direct bin calls do not add this layer.
+
+Each shell fails at a different layer, so a single inline-quoting fix does not cover both.
+
+- **bash** preserves embedded double quotes, so inline JSON survives the shell itself. The failure is the `pnpm <run-script>` wrapper's `cmd.exe` re-parse: `cmd` treats `( ) & < > | ^ %` as metacharacters, and a value containing them aborts with `<X> was unexpected at this time.` before the CLI runs. Keep inline JSON ASCII and metacharacter-free, or bypass the run-script layer with the direct exec form (`pnpm -C operations exec elevasis-sdk ...`).
+- **Windows PowerShell 5.1** strips embedded double quotes when calling a native exe (`node`, `pnpm`), with or without pnpm. The stop-parsing token `--%` and backslash-escaped quotes both fail. There is no reliable inline-JSON route. PowerShell 7+ fixes this class via `$PSNativeCommandArgumentPassing = 'Standard'`.
+
+**Cross-shell rule:** file-based input is shell-agnostic -- only a path crosses the shell boundary. Prefer `@json:<path>` (or `-f` / `--input-file` for `exec` and `request:submit`) for any non-trivial JSON, and write the file with an editor rather than a shell heredoc.
+
+| Shell          | Inline JSON                             | Why                                           | Use instead                          |
+| -------------- | --------------------------------------- | --------------------------------------------- | ------------------------------------ |
+| bash           | OK if values avoid `( ) & < > | ^ %` | run-script `cmd.exe` re-parses metacharacters | direct exec form, or `@json:<path>`  |
+| PowerShell 5.1 | Never reliable                          | strips embedded `"`; `--%` and `\"` both fail | `@json:<path>`                       |
+| either         | n/a                                     | path arguments avoid all JSON shell escaping  | `@json:<path>` + editor-written file |
+
+---
+
 ## elevasis-sdk project:\*
 
 `elevasis-sdk project:*` is the canonical project-management surface. Use it for project, milestone, task, and note operations whether the caller is a human, a scripted workflow, or a slash-command router like `/project`.
@@ -42,18 +78,23 @@ elevasis-sdk project:milestone:list --project <id>
 elevasis-sdk project:milestone:create --project <id> --name "Phase 1"
 elevasis-sdk project:milestone:update <id> --status completed
 elevasis-sdk project:milestone:update <id> --description "Updated scope description"
+elevasis-sdk project:milestone:update <id> --checklist @json:tmp/milestone-checklist.json
 elevasis-sdk project:milestone:delete <id>
 ```
 
 `project:milestone:update` accepts `--description` to set or clear the milestone description. Passing an empty string clears the field, matching `project:task:update --description` semantics.
 
+Checklist updates are full replacements. Use `--checklist <json>` for small inline arrays, or `--checklist @json:<path>` for generated JSON. `--checklist-file <path>` is also supported for checklist-specific file input.
+
 ### Tasks
 
 ```bash
 elevasis-sdk project:task:list --project <id>
 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> --checklist @json:tmp/task-checklist.json
 elevasis-sdk project:task:delete <id>
 ```
 
@@ -68,6 +109,8 @@ elevasis-sdk project:task:save <id> --current-state <text> [--files-modified <js
 - `project:task:save <id>` -- merges fields into `resume_context`; `--current-state` is required; all other flags are optional JSON arrays or plain text
 - these commands are the CLI counterpart to `/work resume` and `/work save` style flows
 
+Task checklist flags are also full replacements. `project:task:create`, `project:task:update`, and `project:milestone:update` support `--checklist <json>`, `--checklist @json:<path>`, and `--checklist-file <path>`. Prefer `@json:<path>` for non-trivial JSON and Windows shells because it works across JSON-valued options, not only checklist commands.
+
 **`project:task:save` flags:**
 
 | Flag                        | Description                               |
@@ -373,7 +416,7 @@ JWT-gated routes at the original unprefixed paths remain for the Command Center.
 
 Full CRUD management for client records. The `client:*` family covers create, read, update, and delete operations at `/api/external/clients`.
 
-For complete field definitions, filter options, and relationship semantics, see the [Clients feature documentation](/technical/features/clients).
+For complete field definitions, filter options, and relationship semantics, see the [Clients feature documentation](/technical/features/operations/clients).
 
 **Quick reference:**
 
@@ -423,21 +466,65 @@ elevasis-sdk agent:get <id>
 
 ## elevasis-sdk session:\*
 
-Inspect and manage agent sessions.
+Create, operate, inspect, and export multi-turn agent sessions. Use `elevasis-sdk exec`
+for one-off workflow or agent execution; use `elevasis-sdk session:*` when the deployed
+agent is `sessionCapable` and needs transcript persistence across turns.
 
 ```bash
+elevasis-sdk session:create <resourceId>
+elevasis-sdk session:turn <id> -f tmp/turn-1.json
+elevasis-sdk session:messages <id>
 elevasis-sdk session:list
 elevasis-sdk session:get <id>
 elevasis-sdk session:end <id>
 ```
 
+- `session:create <resourceId>` -- create a session for a session-capable deployed agent
+- `session:turn <id>` -- execute a turn in an active session; pass input with `--input`
+  or `--input-file`
+- `session:messages <id>` -- export the full transcript by default; use `--page` for a
+  single paginated API read
 - `session:list` -- list sessions for the organization; supports filtering by resource ID, user ID, and limit
-- `session:get <id>` -- get full session detail including messages and events
+- `session:get <id>` -- get session state and metadata
 - `session:end <id>` -- gracefully end an active session
 
-**API routes:** `GET /api/external/sessions`, `/api/external/sessions/:id`, `DELETE /api/external/sessions/:id`
+**API routes:** `POST /api/external/sessions`, `GET /api/external/sessions`,
+`GET /api/external/sessions/:id`, `POST /api/external/sessions/:id/turns`,
+`GET /api/external/sessions/:id/messages`, `POST /api/external/sessions/:id/end`
 
-**`session:list` filter flags:**
+Hard deletion is intentionally not part of `session:end`; any destructive delete surface
+must be exposed as a separate explicit command.
+
+**`session:create` flags:**
+
+| Flag                  | Description                    |
+| --------------------- | ------------------------------ |
+| `--user-id <id>`    | Optional user ID for session   |
+| `--metadata <json>` | Optional session metadata JSON |
+| `--json`              | Output as JSON                 |
+| `--api-url <url>`   | Override the API base URL      |
+
+**`session:turn` flags:**
+
+| Flag                        | Description                                  |
+| --------------------------- | -------------------------------------------- |
+| `-i, --input <json>`      | Turn input as JSON                           |
+| `-f, --input-file <path>` | Read turn input from a JSON file             |
+| `--json`                    | Output as JSON                               |
+| `--api-url <url>`         | Override the API base URL                    |
+
+**`session:messages` flags:**
+
+| Flag                  | Description                                                 |
+| --------------------- | ----------------------------------------------------------- |
+| `--limit <limit>`   | Messages per API page; default comes from the API           |
+| `--cursor <cursor>` | Message index cursor to start after                         |
+| `--page`              | Fetch one API page for debugging instead of all pages       |
+| `--all`               | Fetch all pages; this is the default transcript export mode |
+| `--json`              | Output as JSON                                              |
+| `--api-url <url>`   | Override the API base URL                                   |
+
+**`session:list` flags:**
 
 | Flag                   | Description                          |
 | ---------------------- | ------------------------------------ |
@@ -650,28 +737,47 @@ Both commands install after rewriting `package.json`. The `external/_template` r
 
 ---
 
+## elevasis-sdk skill:\*
+
+Developer-facing skill tooling keeps the template `.claude/skills/` surface aligned with the live CLI catalog.
+
+```bash
+elevasis-sdk skill:scaffold <domain>
+elevasis-sdk skill:check-coverage
+```
+
+- `skill:scaffold <domain>` prints a `SKILL.md` stub built from `elevasis-sdk cli --format json` for that domain. Author the curated skill at `external/_template/.claude/skills/<domain>/SKILL.md`; do not edit generated SDK reference copies directly.
+- `skill:check-coverage` compares live CLI domains against `.claude/registries/skill-coverage.json`. Domains must be owned by a skill or explicitly waived.
+
+The same coverage gate runs inside `elevasis-sdk check` when the coverage registry exists in the project root.
+
+**Implementation:** `packages/sdk/src/cli/commands/skill/`
+
+---
+
 ## 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:list`, `session:get`, `session:end`                              | `/api/external/sessions*`                                  | implemented management 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                  |
-| 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     | none                                                                      | not scoped here                                                | deferred                      |
+| seo         | none                                                                      | not scoped here                                                | deferred                      |
+| monitoring  | none                                                                      | not scoped here                                                | deferred                      |
 
 ### Promotion Criteria
 

package/reference/sdk/cli.mdx

@@ -13,7 +13,7 @@ pnpm add @elevasis/sdk
 
 After installation, the `elevasis-sdk` binary is available in your project's `node_modules/.bin/`. Most commands require `ELEVASIS_PLATFORM_KEY` to be set in your environment or a `.env` file.
 
-For management commands (project:\*, note:\*, acquisition:\*, client:\*, agent:\*, session:\*, queue:\*, schedule:\*, om:\*, ui:\*), see [CLI Management](cli-management.mdx).
+For management commands (project:\*, note:\*, acquisition:\*, client:\*, agent:\*, session:\*, queue:\*, schedule:\*, om:\*, ui:\*, skill:\*), see [CLI Management](cli-management.mdx).
 
 ---
 
@@ -30,6 +30,7 @@ elevasis-sdk check
 **Behavior:**
 
 - Imports your `src/index.ts` and runs it through `ResourceRegistry` validation
+- Runs the skill coverage gate when `.claude/registries/skill-coverage.json` is present, ensuring every live CLI domain is covered by a template skill or explicitly waived
 - Catches the same errors that the platform catches at deploy time:
   - Duplicate `resourceId` within the organization
   - Invalid model configuration (temperature and token bounds)

package/reference/ui/exports.mdx

@@ -25,6 +25,7 @@ description: "Auto-generated catalog of all published @elevasis/ui subpath expor
 | `@elevasis/ui/features/delivery` | Features Delivery | Features | Published delivery feature surface for downstream shells. |
 | `@elevasis/ui/features/lead-gen` | Features Lead Gen | Features | Published lead generation feature surface for downstream shells. |
 | `@elevasis/ui/features/operations` | Features Operations | Features | Published operations feature surface for downstream shells. |
+| `@elevasis/ui/features/public-agent-chat` | Features Public Agent Chat | Features | Published public agent chat surface for downstream shells. |
 | `@elevasis/ui/features/monitoring` | Features Monitoring | Features | Published monitoring feature surface for downstream shells. |
 | `@elevasis/ui/features/monitoring/requests` | Features Monitoring Requests | Features | Published submitted-requests list, detail, and triage surface for downstream shells. |
 | `@elevasis/ui/features/seo` | Features SEO | Features | Published SEO feature surface for downstream shells. |