npm - @elevasis/sdk - Versions diffs - 1.44.2 → 1.45.0 - Mend

@elevasis/sdk 1.44.2 → 1.45.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (245) hide show

package/reference/claude-config/skills/elevasis/SKILL.md DELETED Viewed

@@ -1,251 +0,0 @@
----
-name: elevasis
-description: Elevasis platform operations -- check, deploy, execute, inspect, and debug SDK resources
----
-# Elevasis Platform Operations
-Manage SDK resources in the `operations/` workspace via the `elevasis-sdk` CLI.
-**Usage:**
-- `/elevasis` -- Show available operations
-- `/elevasis check` -- Validate resource definitions
-- `/elevasis deploy [--prod]` -- Deploy resources
-- `/elevasis exec <resourceId> [--input '...']` -- Execute a resource
-- `/elevasis describe <resourceId>` -- Show resource schema
-- `/elevasis logs <resourceId>` -- View recent executions
-- `/elevasis creds` -- Manage credentials
-## Critical Rules
-- **Always describe before exec** -- run `describe` first to see the exact input schema
-- **Use `-f` for complex inputs** -- write JSON to a temp file to avoid shell escaping issues
-- **Always `check` before `deploy`** -- catches schema and config errors early
-## Environment
-The CLI authenticates via `ELEVASIS_PLATFORM_KEY` in the root `.env` file. The CLI walks up directories to find `.env`, so it works from both the project root and `operations/`.
-**API URL resolution priority** (highest wins, first match applies):
-1. `--api-url <url>` CLI flag -- explicit override, always wins
-2. `--prod` flag -- forces `https://api.elevasis.io`
-3. `ELEVASIS_API_URL` env var -- custom URL override
-4. `NODE_ENV` default -- `http://localhost:5170` only when `NODE_ENV=development`; otherwise `https://api.elevasis.io`
-**The default target is production.** Unless `NODE_ENV=development` is set in the environment, every command hits `https://api.elevasis.io` even with no flags at all.
-**`NODE_ENV=development` is what selects the dev API** (`http://localhost:5170`). Setting `NODE_ENV=development` also switches the credential lookup: `ELEVASIS_PLATFORM_KEY_DEV` is used if set, falling back to `ELEVASIS_PLATFORM_KEY` if not.
-**`--prod` forces production, even under `NODE_ENV=development`.** It overrides the dev API URL back to `https://api.elevasis.io` AND forces the credential lookup to use `ELEVASIS_PLATFORM_KEY` (never the `_DEV` variant), regardless of `NODE_ENV`.
-## Operations
-### Check
-Validate all resource definitions (schemas, contracts, config):
-```bash
-pnpm elevasis-sdk check
-```
-Reports: resource count, validation errors, schema serialization warnings. Exit code 0 = pass.
-### Deploy
-Bundle and deploy resources to the Elevasis platform.
-```bash
-pnpm elevasis-sdk deploy [--prod]
-```
-Replace `[--prod]` with `--prod` when targeting production.
-**Version bumping flags** (written back to `src/index.ts`):
-- `--major` -- bump major (1.0.0 to 2.0.0) for breaking contract changes
-- `--minor` -- bump minor (1.0.0 to 1.1.0) for new features
-- `--patch` -- bump patch (1.0.0 to 1.0.1) for fixes
-Deploy replaces the previous active deployment. Resources become executable immediately.
-### Describe
-**Always run before executing.** Shows resource metadata, input/output schemas, and step chain:
-```bash
-pnpm elevasis-sdk describe <resourceId>
-# JSON output for programmatic use
-pnpm elevasis-sdk describe <resourceId> --json
-```
-Output includes: type, name, version, status, domains, input schema (required/optional fields with types), output schema, step definitions with entry point and routing.
-### Execute
-Run a deployed resource. **Always `describe` first to see the input schema.**
-```bash
-# Simple input (inline JSON)
-pnpm elevasis-sdk exec <resourceId> -i '{"key": "value"}'
-# Complex input (temp file -- PREFERRED for non-trivial payloads)
-# Write input to a temp file first, then reference it with -f
-pnpm elevasis-sdk exec <resourceId> -f .tmp-input.json
-# Async execution (for long-running workflows -- polls until complete)
-pnpm elevasis-sdk exec <resourceId> -f .tmp-input.json --async
-```
-**When to use `-f` (file input):**
-- Input contains nested objects, arrays, or special characters
-- Input has quotes that conflict with shell escaping
-- Input is reused across multiple executions
-- Any time inline `-i` causes parsing errors
-**Temp file pattern:**
-1. Write the JSON to a temp file inside the project (e.g., `operations/.tmp-input.json`)
-2. Execute with `-f .tmp-input.json`
-3. Delete the temp file after
-**Sync vs async:**
-- Sync (default): blocks until execution completes, shows result inline
-- Async (`--async`): returns execution ID immediately, polls every 3s with elapsed timer
-- Use `--async` for workflows that may exceed 30 seconds
-**Connection failure recovery:** If the connection drops during sync execution, the CLI automatically searches recent executions for a running one and resumes polling.
-### List Resources
-View all deployed resources:
-```bash
-pnpm elevasis-sdk resources
-# JSON output
-pnpm elevasis-sdk resources --json
-```
-Shows: resource ID, type (workflow/agent), name, description, status.
-### Execution History
-View past executions for a resource:
-```bash
-# List recent executions (default: last 50)
-pnpm elevasis-sdk executions <resourceId>
-# Filter by status
-pnpm elevasis-sdk executions <resourceId> --status failed --limit 10
-# View specific execution (full detail with logs)
-pnpm elevasis-sdk execution <resourceId> <executionId>
-# Logs only (skip metadata)
-pnpm elevasis-sdk execution <resourceId> <executionId> --logs-only
-# Include input and result data
-pnpm elevasis-sdk execution <resourceId> <executionId> --input --result
-```
-**`executions` flags:** `--limit <n>` (default 50), `--status running|completed|failed`, `--json`
-**`execution` flags:** `--logs-only`, `--input`, `--result`, `--json`
-Execution detail shows: status, start/end times, duration, input, result, error (if failed), and timestamped logs with level (ERROR/WARN/INFO/DEBUG).
-### Deployments
-View deployment history:
-```bash
-pnpm elevasis-sdk deployments
-```
-Shows: deployment ID, SDK version, status (active/deploying/failed/stopped), created timestamp.
-### Credentials
-Manage integration credentials (API keys, webhook secrets):
-```bash
-# List credentials (metadata only, secrets not exposed)
-pnpm elevasis-sdk creds list
-# Create a credential
-pnpm elevasis-sdk creds create --name my-api-key --type api-key --value '{"apiKey":"sk-..."}'
-# Update a credential value
-pnpm elevasis-sdk creds update my-api-key --value '{"apiKey":"new-key"}'
-# Rename a credential
-pnpm elevasis-sdk creds rename old-name --to new-name
-# Delete a credential
-pnpm elevasis-sdk creds delete my-api-key --force
-```
-Credential names: lowercase, digits, hyphens only (`^[a-z0-9]+(-[a-z0-9]+)*$`). Types: `api-key`, `webhook-secret`.
-### Rename Resource
-Rename a resource ID across all platform tables:
-```bash
-# Dry run (preview only)
-pnpm elevasis-sdk rename old-id --to new-id
-# Apply rename
-pnpm elevasis-sdk rename old-id --to new-id --execute
-```
-Always dry-run first to see affected tables and row counts.
-### Error Resolution
-Mark execution errors as resolved:
-```bash
-# Resolve a specific error
-pnpm elevasis-sdk error resolve <errorId>
-# Resolve all errors for an execution
-pnpm elevasis-sdk error resolve-execution <executionId>
-```
-## Standard Workflow
-```
-1. Write/modify resources     operations/src/
-2. Type-check                 pnpm -C operations run check-types
-3. Validate                   /elevasis check
-4. Deploy                     /elevasis deploy --prod
-5. Describe                   /elevasis describe <id>
-6. Execute                    /elevasis exec <id> -f input.json
-7. Inspect logs               /elevasis logs <id>
-```
-## Debugging Checklist
-When an execution fails:
-1. **Get the execution ID** from the exec output or `executions <resourceId> --status failed`
-2. **Read the logs**: `execution <resourceId> <executionId> --logs-only`
-3. **Check the input**: `execution <resourceId> <executionId> --input`
-4. **Check the error**: `execution <resourceId> <executionId> --result`
-5. **Fix the handler**, redeploy, re-execute
----
-## Capability Surface
-When a user asks what skills or commands are available, do NOT answer from recollection.
-- **Skill inventory:** Read `.claude/Overview.md` — it is the authoritative list of skills available in this project.
-- **Live CLI capability:** Run `pnpm elevasis-sdk cli` — it outputs every command and domain currently registered in the SDK, grouped by domain.

package/reference/claude-config/skills/explore/SKILL.md DELETED Viewed

@@ -1,78 +0,0 @@
----
-name: explore
-description: Codebase exploration anchored to project documentation
----
-# Explore
-Codebase exploration anchored to project documentation.
-**Usage:** `/explore [area or question]`
-## Process
-### Step 0: OS-Vocab Classification
-Before orienting, scan the user's query for Organization OS terminology. If any of the following appear, classify the query as **OS-relevant** and follow the OS context steps below; otherwise skip to Step 1.
-**OS vocabulary triggers:**
-- System layer: `system`, `systems`, `SystemModule`, `system key`, `system gate`, `system access`, `gate`, `gating`, `access`, `enable`, `disable`
-- Shell / nav: `manifest`, `shell`, `sub-shell`, `sidebar`, `nav`, `navigation`, `route`
-- Auth / guards: `guard`, `SystemGuard`, `AdminGuard`, `ProtectedRoute`, `admin`
-- Org model: `organization`, `org model`, `organization model`, `domain`, `surface`
-- Foundations: `foundation`, `foundations`, `@core/`, `adapter`
-- Platform ops: `workflow`, `agent`, `deployment`, `resource`
-**If OS-relevant:**
-1. Read `.claude/rules/active-change-index.md` immediately. If the target area is flagged as under active refactor, surface the watch-area warning to the user before proceeding — include the "Load:" doc paths listed in that entry so investigation does not rely on stale scaffold prose.
-2. Build the OS context bundle to pass into Step 3:
-   - Always: `operations/node_modules/@elevasis/sdk/reference/scaffold/reference/glossary.md`, `.claude/rules/active-change-index.md`, `.claude/rules/agent-start-here.md`
-   - Systems / Shell / Gating queries: add `operations/node_modules/@elevasis/sdk/reference/scaffold/ui/feature-flags-and-gating.md` + `operations/node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md`
-   - Workflow / Operations queries: add `.claude/rules/operations.md` + glob `operations/src/**`
-   - Organization-model queries: add `operations/node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` + `core/config/README.md`
-**OS layer → query intent map** (guides which reference docs the investigator loads first):
-| Query intent                             | Primary OS layers                | Key reference                                                                            |
-| ---------------------------------------- | -------------------------------- | ---------------------------------------------------------------------------------------- |
-| "Why doesn't my system show up?"         | Systems + UI Shell Runtime       | `glossary.md` (SystemModule, SystemGuard), `feature-flags-and-gating.md`                 |
-| "How do I add a nav item?"               | Systems + Toolkit                | `feature-flags-and-gating.md`, `contracts.md`                                            |
-| "How does admin gating work?"            | Systems + UI Shell Runtime       | `glossary.md` (AdminGuard, requiresAdmin, ProtectedRoute), `feature-flags-and-gating.md` |
-| "What runs when this workflow triggers?" | Platform Public API + Operations | `.claude/rules/operations.md`, `resources.md`                                            |
-| "Why does the foundations adapter fail?" | Foundations                      | `glossary.md` (domain vs surface, settings asymmetry), `core/config/README.md`           |
-### Step 1: Orient
-1. Read `.claude/rules/agent-start-here.md` for project structure, task-class routing, and boundary resolution
-2. Determine which domain the user's question falls into
-### Step 2: Load Domain Context
-Read the relevant doc(s) and source directories based on the area being explored. Use the Navigation table in `CLAUDE.md` for quick reference.
-For OS-relevant queries, also inject the OS context bundle assembled in Step 0 into the investigator's starting context.
-### Step 3: Investigate
-For targeted questions:
-- Use Grep to search for specific patterns, function names, or strings
-- Use Glob to find files by pattern
-- Read specific files for detailed understanding
-For broad exploration:
-- Dispatch a `general-purpose` subagent with the domain context and exploration question
-- The subagent should read files, trace data flow, and return a structured report
-- For OS-relevant queries, pass the preloaded OS context bundle so the subagent starts with terminology already resolved
-### Step 4: Report
-Present findings with:
-- Direct answers to the question
-- Relevant code locations (file:function format)
-- Connections to other parts of the system
-- Suggestions for related areas to explore (if relevant)

package/reference/claude-config/skills/git-sync/SKILL.md DELETED Viewed

@@ -1,166 +0,0 @@
----
-name: git-sync
-description: Pull latest changes, surface new sync notes, install when needed, and run baseline verification without auto-reconciling template drift
----
-# Git Sync
-Pull the latest upstream changes for this project, detect any newly introduced template sync notes, install dependencies when the pull changed package baselines, and run the baseline verification flow.
-**Usage:** `/git-sync`
-Use this when:
-- you just pulled a release-train update from the template repo
-- the branch may include dependency or scaffold baseline changes
-- you want the current sync-note guidance before making any manual reconciliation edits
-This command is intentionally narrower than template reconciliation. It stops after pull, install, verification, and note surfacing. It never auto-overwrites project-owned files.
-## Sync Notes Contract
-Downstream release guidance lives in `.claude/sync-notes/`.
-- Operative note files are named `YYYY-MM-DD-<slug>.md`
-- `README.md` documents the contract and is ignored by note detection
-- Notes are append-only release guidance; do not rewrite old note filenames after they ship
-- Every operative note uses these exact headings:
-  - `## Why this note exists`
-  - `## Applies to`
-  - `## Required actions`
-  - `## Verification`
-  - `## Not handled by /git-sync`
-## Process
-### Step 1: Check for Uncommitted Changes
-```bash
-git status --short
-```
-If the worktree is dirty, stop and tell the user to commit, stash, or discard changes first. Do not pull on top of local edits.
-### Step 2: Snapshot Current Sync Notes
-Capture the current operative note filenames before pulling:
-```bash
-git ls-files ".claude/sync-notes/*.md"
-```
-Ignore `README.md` when building the pre-pull note set.
-### Step 3: Pull Latest Changes
-```bash
-git pull --rebase
-```
-If the pull conflicts, stop and report the conflict. Do not attempt auto-resolution.
-### Step 4: Detect Whether Install Is Required
-If the pull changed any dependency baseline files, run a fresh install:
-```bash
-git diff --name-only HEAD@{1} HEAD -- package.json pnpm-lock.yaml pnpm-workspace.yaml ui/package.json operations/package.json core/package.json
-```
-If the diff is non-empty:
-```bash
-pnpm install
-```
-If none of those files changed, skip install and report that the dependency baseline was unchanged.
-### Step 5: Verify the Installed SDK Bundle
-Tenant `.claude/` files (skills, rules pointers, sync notes) arrive via this git pull. The canonical rule bodies those pointers resolve to (`operations/node_modules/@elevasis/sdk/reference/rules/*.md`) arrive on a separate channel: the published npm tarball, pulled in by `pnpm install`. These two channels can silently disagree -- a pull can land new `.claude/` pointers aimed at rule files the installed SDK does not have yet. Check for that gap explicitly:
-1. **Confirm the bundle exists:**
-   ```bash
-   ls operations/node_modules/@elevasis/sdk/package.json
-   ```
-   If missing, the SDK is not installed at all -- run `pnpm install` and re-check before continuing.
-2. **Read the installed version:**
-   ```bash
-   node -p "require('./operations/node_modules/@elevasis/sdk/package.json').version"
-   ```
-3. **Read the declared range:**
-   ```bash
-   node -p "require('./operations/package.json').dependencies['@elevasis/sdk']"
-   ```
-   Compare the installed version against the declared semver range (e.g. `^1.37.0`). If the installed version does not satisfy the declared range -- most commonly because it is behind (older than the range allows) -- the lockfile and `node_modules` are out of sync with the manifest.
-4. **Confirm the rules bundle is present and non-empty:**
-   ```bash
-   ls operations/node_modules/@elevasis/sdk/reference/rules/
-   ```
-   An empty or missing directory means the tenant's `.claude/rules/*.md` compatibility pointers have nothing to resolve to, even if the package itself is present.
-**If the installed version is behind the declared range, or the rules directory is missing/empty:** run `pnpm install`, then repeat steps 1-4 to confirm the gap is closed. Report the before/after versions.
-**This step reports and stops -- it does not auto-reconcile template drift.** If after a fresh install the installed version still does not satisfy the declared range (e.g. the range itself needs bumping), or the rules directory is still empty, surface that as an explicit manual-reconciliation item in the final report. Do not attempt to hand-edit `operations/package.json` version ranges here.
-### Step 6: Run Baseline Verification
-Run the standard project verification flow:
-```bash
-pnpm -C ui check-types
-pnpm -C ui build
-pnpm -C operations check
-pnpm -C operations check-types
-```
-Stop on the first failure and report it clearly.
-### Step 7: Surface Newly Introduced Sync Notes
-Build the post-pull operative note set and compare it to the pre-pull set. Any newly added note filename is considered unread guidance for this pull.
-When new notes exist:
-- print each new note filename
-- summarize the `## Required actions`, `## Verification`, and `## Not handled by /git-sync` sections
-- tell the user exactly which manual follow-up remains
-When no new notes exist, say so explicitly.
-### Step 8: Stop Before Reconciliation
-`/git-sync` ends after pull, optional install, verification, and note surfacing.
-It does **not**:
-- run registry/template reconciliation
-- overwrite project-owned files
-- resolve downstream migration conflicts
-- treat a passing baseline verify as proof that manual follow-up is complete
-If a sync note or the pulled diff requires project-specific changes, leave those as an explicit next step.
-## Report
-```text
-Git Sync Complete
-=================
-Git:         pulled (<branch>)
-Install:     ran | skipped (no dependency baseline changes)
-SDK bundle:  <installed-version> satisfies <declared-range> | BEHIND (installed <x> < declared <y>) | reinstalled -> now satisfies
-Rules bundle: present (<n> files) | MISSING/EMPTY
-Verify:      PASS | FAIL at <step>
-Sync notes:  none | 2026-04-22-example-change.md
-Next step:   manual reconciliation required | none
-```