@elevasis/sdk 1.44.2 → 1.45.0

package/reference/claude-config/rules/vibe.md

@@ -1,22 +0,0 @@
----
-description: Compatibility pointer for the canonical Vibe rule bundled with @elevasis/sdk
----
-
-# Vibe
-
-Canonical rule source:
-
-`operations/node_modules/@elevasis/sdk/reference/rules/vibe.md`
-
-When working in the monorepo template snapshot before dependencies are installed,
-use the repo-local generated fallback:
-
-`packages/sdk/reference/rules/vibe.md`
-
-If the generated fallback is stale or missing, use the source:
-
-`packages/sdk/docs/agent-rules/vibe.md`
-
-Read the bundled rule first when available. This local file is intentionally kept
-as a thin compatibility pointer for existing local rule references in skills,
-sync notes, and older prompts.

package/reference/claude-config/scripts/statusline-command.js

@@ -1,18 +0,0 @@
-#!/usr/bin/env node
-let input = ''
-process.stdin.on('data', (chunk) => (input += chunk))
-process.stdin.on('end', () => {
-  const data = JSON.parse(input)
-  const model = data.model?.display_name || '?'
-  const pct = Math.floor(data.context_window?.used_percentage || 0)
-
-  const DIM = '\x1b[90m',
-    RESET = '\x1b[0m'
-
-  const ctxSize = data.context_window?.context_window_size || 0
-  const usedTokens = Math.round((ctxSize * pct) / 100)
-  const rounded = Math.round(usedTokens / 100) * 100
-  const tokenStr = rounded >= 1000 ? (rounded / 1000).toFixed(1).replace(/\.0$/, '') + 'k' : String(rounded)
-
-  console.log(`${DIM}[${RESET}${model}${DIM}]${RESET} ${tokenStr} Tokens`)
-})

package/reference/claude-config/settings.json

@@ -1,30 +0,0 @@
-{
-  "statusLine": {
-    "type": "command",
-    "command": "node .claude/scripts/statusline-command.js"
-  },
-  "hooks": {
-    "PostToolUse": [
-      {
-        "matcher": "Write|Edit|MultiEdit",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node .claude/hooks/post-edit-validate.mjs"
-          }
-        ]
-      }
-    ],
-    "PostToolUseFailure": [
-      {
-        "matcher": "Bash",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node .claude/hooks/tool-failure-recovery.mjs"
-          }
-        ]
-      }
-    ]
-  }
-}

package/reference/claude-config/skills/client/SKILL.md

@@ -1,201 +0,0 @@
----
-name: client
-description: "Client portfolio management -- list, resolve, inspect, and maintain client records and their lineage to companies, contacts, and source deals -- via the elevasis-sdk client:* CLI."
-argument-hint: "[list | status | get | resolve | create | update | delete] [args]"
-allowed-tools: Bash, Read, Write, Edit, Glob, Grep
----
-
-# Client Management
-
-`/client` is the entrypoint for all client-portfolio work in the template. It covers:
-
-- **Portfolio status** -- bare `/client` or `/client status` gives a portfolio-level overview of all clients.
-- **Lookup and resolution** -- `/client <query>` or `/client resolve <query>` resolves a name or search term to a canonical client ID.
-- **Detail and lineage** -- `/client get <id>` returns full client detail including linked companies, contacts, and source deals.
-- **CRUD surface** -- create, update, and delete client records via `elevasis-sdk client:*`.
-
-**Usage:**
-
-- `/client` / `/client status` -- Portfolio overview (see "Status Mode" below). Wraps `client:status`.
-- `/client list [--search q] [--status s] [--limit n] [--offset n]` -- Paginated client list. Wraps `client:list`.
-- `/client <query>` / `/client resolve <query>` -- Fuzzy-resolve a client by name, UUID, or search string. Wraps `client:resolve`.
-- `/client get <id>` -- Full client detail: name, status, source, linked company, contact, deals. Wraps `client:get`.
-- `/client create --name "..." [options]` -- Create a new client (confirm ceremony). Wraps `client:create`.
-- `/client update <id> [options]` -- Update client fields (confirm ceremony). Wraps `client:update`.
-- `/client delete <id>` -- Delete a client (destructive -- explicit confirmation required). Wraps `client:delete`.
-
----
-
-## Ambient Vibe Integration
-
-`/client` is the landing point for client-scoped vibe intents. Agents arriving from the ambient layer behave identically to a direct invocation.
-
-| Vibe intent    | What vibe detected                                          | What to do here                                                                                       |
-| -------------- | ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
-| **Describe**   | "tell me about Acme", "what's the status of this client"    | Resolve the client name via `client:resolve`, then run `client:get <id>` and narrate detail + lineage |
-| **Query**      | "which clients are active", "list clients", "client status" | Run `client:list [--status s] [--search q]` or `client:status` and present the results                |
-| **Navigate**   | "focus on Acme", "switch to Acme", "back to Acme"           | Resolve via `client:resolve <query>`, update scope to that client, narrate the new context            |
-| **Capture**    | "add a new client", "create a client for Beta LLC"          | Draft fields from the user's message, confirm with user (Capture ceremony), then `client:create`      |
-| **Transition** | "update Acme's status", "mark Acme as active"               | Confirm the change with user (Transition ceremony), then `client:update <id> --status <new>`          |
-
-`client:create`, `client:update`, and `client:delete` MUST route through the standard Capture/Transition confirm step before executing. The destructive `client:delete` requires explicit user confirmation (show what will be deleted and ask "Are you sure?" before proceeding).
-
----
-
-## Prerequisites
-
-**Run from the project root** (the directory containing `.elevasis`). Before issuing any other commands, run:
-
-```bash
-pnpm elevasis-sdk doctor
-```
-
-If `doctor` fails, stop immediately and surface the error -- do not retry other commands. Fix the reported issue first (missing `.env`, bad API key, wrong directory), then re-run `doctor` before proceeding.
-
----
-
-## Invocation Contract
-
-All `elevasis-sdk` commands in this skill use the wrapper script form:
-
-```bash
-pnpm elevasis-sdk <subcommand> [flags]
-```
-
-Available from the **project root** -- the directory that contains the `.elevasis` marker file. The long form `pnpm -C operations exec elevasis-sdk <subcommand>` is equivalent.
-
----
-
-## Status Mode (bare `/client` or `/client status`)
-
-When invoked without a subcommand or with `status`, enter **client portfolio mode**: present a high-level overview and offer next actions.
-
-```bash
-pnpm elevasis-sdk client:status --pretty
-```
-
-Present the result as a compact summary: total clients, breakdown by status, and a suggestion of what to do next (e.g. "3 active clients. Inspect one with `/client get <id>` or list all with `/client list`").
-
----
-
-## Operations
-
-### `list [options]` -- Client List
-
-```bash
-pnpm elevasis-sdk client:list --pretty
-
-# Filter by status
-pnpm elevasis-sdk client:list --status active --pretty
-
-# Search by name
-pnpm elevasis-sdk client:list --search "Acme" --pretty
-
-# Paginate
-pnpm elevasis-sdk client:list --limit 20 --offset 0 --pretty
-```
-
-**Options:** `--status <status>`, `--search <query>`, `--limit <n>`, `--offset <n>`, `--api-url <url>`, `--pretty`
-
-Present as a compact table: name, status, source.
-
-### `resolve <query>` -- Name-to-ID Resolution
-
-Resolves a name, UUID, or search string to a canonical client record. This is the primary tool for name-to-ID translation before any `get`, `update`, or `delete` call.
-
-```bash
-pnpm elevasis-sdk client:resolve "Acme" --pretty
-```
-
-If multiple candidates match, the CLI returns candidates -- pick the right one and confirm with the user before proceeding. If zero match, surface the error and suggest `client:list --search "<query>"` to browse.
-
-### `get <id>` -- Client Detail and Lineage
-
-```bash
-pnpm elevasis-sdk client:get <id> --pretty
-```
-
-Returns full client detail: name, status, source, source deal, linked primary company, primary contact, and metadata. Narrate the lineage in plain language (e.g. "Acme Corp -- active client, sourced from deal john@acme.com, linked to Acme Corp (acq_companies)").
-
-### `create` -- Create Client (Confirm Ceremony)
-
-**Always confirm before creating.** Collect required and optional fields, draft a summary, and ask the user to confirm before executing.
-
-**Required:** `--name <name>`
-
-**Optional:** `--status <status>`, `--source <source>`, `--source-deal-id <uuid>`, `--primary-company-id <uuid>`, `--primary-contact-id <uuid>`, `--metadata <json>`
-
-```bash
-pnpm elevasis-sdk client:create \
-  --name "Acme Corp" \
-  --status active \
-  --source deal \
-  --source-deal-id <deal-uuid> \
-  --pretty
-```
-
-After creation, show the new client ID and suggest `/client get <id>` to verify.
-
-### `update <id>` -- Update Client (Confirm Ceremony)
-
-**Always confirm before updating.** Show the current state via `client:get <id>`, draft the proposed changes, and ask the user to confirm before executing.
-
-**Options:** `--name <name>`, `--status <status>`, `--source <source>`, `--source-deal-id <uuid>`, `--clear-source-deal`, `--primary-company-id <uuid>`, `--clear-primary-company`, `--primary-contact-id <uuid>`, `--clear-primary-contact`, `--metadata <json>`
-
-```bash
-pnpm elevasis-sdk client:update <id> --status active --pretty
-```
-
-To clear a linked field, use the corresponding `--clear-*` flag (e.g. `--clear-source-deal`, `--clear-primary-company`, `--clear-primary-contact`). Do NOT pass an empty string -- it is rejected. Use the clear flag instead.
-
-### `delete <id>` -- Delete Client (Destructive -- Explicit Confirmation Required)
-
-**ALWAYS confirm before deleting.** Show the client record first (via `client:get <id>`), then ask the user explicitly: "Delete client `<name>` (`<id>`)? This cannot be undone." Only proceed after an affirmative confirmation.
-
-```bash
-pnpm elevasis-sdk client:delete <id> --pretty
-```
-
----
-
-## Client Inference
-
-When the user refers to a client by name rather than ID, resolve using these steps (in priority order):
-
-1. **Exact UUID** -- if the argument looks like a UUID, use it directly with `client:get`
-2. **`client:resolve`** -- run `client:resolve "<name>"` to fuzzy-match by name; use the returned ID
-3. **`client:list --search`** -- if `resolve` returns no match, search with `client:list --search "<name>"` and present candidates
-4. **Context from conversation** -- if a specific client was resolved earlier in this session, prefer it
-5. **Ambiguous** -- if multiple match or none match, show candidates and ask
-
----
-
-## Natural Language Mode
-
-When args do not match any command pattern, infer intent from natural language:
-
-| User says                                         | Inferred operation                                          |
-| ------------------------------------------------- | ----------------------------------------------------------- |
-| "show me Acme"                                    | `resolve "Acme"` then `get <id>`                            |
-| "who are our active clients"                      | `list --status active --pretty`                             |
-| "client overview" / "how many clients do we have" | `status --pretty`                                           |
-| "add a new client: Beta LLC"                      | `create --name "Beta LLC"` (confirm ceremony)               |
-| "update Acme to active"                           | `resolve "Acme"` then `update <id> --status active`         |
-| "delete the Gamma client"                         | `resolve "Gamma"` then `delete <id>` (explicit confirm)     |
-| "link Acme to deal <uuid>"                        | `resolve "Acme"` then `update <id> --source-deal-id <uuid>` |
-| "remove Acme's source deal"                       | `resolve "Acme"` then `update <id> --clear-source-deal`     |
-
----
-
-## Safety Rules
-
-1. **Always confirm create/update/delete** -- show proposed changes and ask the user before executing any write operation
-2. **Explicit confirmation for delete** -- `client:delete` is irreversible; require an affirmative "yes" before running
-3. **Organization scoping** -- all API calls are automatically org-scoped via `ELEVASIS_PLATFORM_KEY`; no `--org` flag is required
-4. **Read before write** -- when updating, show current state via `client:get` before applying changes
-5. **Use `--clear-*` flags to unlink** -- never pass empty strings to clear linked fields; use `--clear-source-deal`, `--clear-primary-company`, or `--clear-primary-contact`
-6. **Template project assumption** -- the template is a single-organization project; all `/client` operations are scoped by `ELEVASIS_PLATFORM_KEY`; there is no cross-org capability
-
----
-
-**Last Updated:** 2026-06-03

package/reference/claude-config/skills/deploy/SKILL.md

@@ -1,159 +0,0 @@
----
-name: deploy
-description: Test, build, fix issues, then commit and push
----
-
-# Deploy
-
-Test, build, fix issues, then commit and push.
-
-**Usage:** `/deploy [--skip] [--minor | --major] [commit message]`
-
-## Flags
-
-- `--skip` -- Skip tests, type checking, and build (Steps 2-4). Go straight from pre-flight to commit and push.
-- `--minor` -- Bump the minor version instead of patch (e.g. 1.0.0 -> 1.1.0).
-- `--major` -- Bump the major version instead of patch (e.g. 1.0.0 -> 2.0.0).
-
-## Process
-
-### Step 1: Pre-flight Check
-
-Run in parallel:
-
-```bash
-git status
-git diff --stat
-```
-
-If there are no changes, report "Nothing to deploy" and stop.
-
-### Step 1b: Version Bump
-
-Read the current version from `package.json`, then bump it:
-
-- Default: bump **patch** (e.g. 1.0.0 -> 1.0.1)
-- `--minor`: bump **minor** (e.g. 1.0.0 -> 1.1.0)
-- `--major`: bump **major** (e.g. 1.0.0 -> 2.0.0)
-
-Use the Edit tool to update the `"version"` field in `package.json` directly. Do not use `npm version` or any CLI command.
-
-### Step 2: Run Tests
-
-```bash
-pnpm test
-```
-
-If tests fail:
-
-1. Read the failing test output
-2. Attempt to fix the issue
-3. Re-run tests
-4. If still failing after 2 attempts, stop and report the failures
-
-### Step 3: Type Check
-
-Root has no `lint` script -- `lint` only exists in `ui/package.json` (`tsc --noEmit`). `operations/package.json` has an equivalent `check-types` script; `core/package.json` has neither `lint` nor `check-types` (only `test`). Run:
-
-```bash
-pnpm -C ui lint
-pnpm -C operations check-types
-```
-
-If type errors exist:
-
-1. Read the errors
-2. Attempt to fix
-3. Re-run
-4. If still failing after 2 attempts, stop and report
-
-### Step 4: Build
-
-```bash
-pnpm build
-```
-
-If build fails:
-
-1. Read the error output
-2. Attempt to fix
-3. Re-run
-4. If still failing after 2 attempts, stop and report
-
-### Step 5: Commit
-
-1. Stage all changed files: `git add -A`
-2. Create commit with the provided message (or auto-generate from changes)
-3. Format: conventional commits (feat:, fix:, chore:, docs:, etc.)
-
-```bash
-git add -A
-git commit -m "<message>"
-```
-
-### Step 6: Push
-
-```bash
-git push
-```
-
-If push fails (e.g., remote has new commits):
-
-1. `git pull --rebase`
-2. Re-run tests to verify no conflicts broke anything
-3. `git push`
-
-### Step 7: Report
-
-```
-Deploy Complete
-===============
-Version: <old> -> <new>
-Tests:   passed
-Types:   clean
-Build:   success
-Commit:  <hash> - <message>
-Push:    pushed to <branch>
-```
-
-### Step 8: Project Task Status Transition
-
-After a successful push, mark any linked project task as `submitted`. This is a best-effort fanout -- it must never fail the deploy.
-
-1. **Resolve the task ID.** Look for a `prj_tasks` UUID tied to the current work, in this order:
-   - A task UUID explicitly captured in the current conversation (e.g. from a previous `/save`, `/project work`, or `project:task:*` invocation).
-   - The most recent in-progress task on the most-recently-touched project, via:
-
-     ```bash
-     pnpm elevasis-sdk project:list --status active --pretty
-     pnpm elevasis-sdk project:list --status blocked --pretty
-     pnpm elevasis-sdk project:task:list --project <project-id> --status in_progress --pretty
-     ```
-
-   - If the session produced an ambiguous or empty result, PROMPT the user once: "Mark a project task as submitted? (task UUID, or 'skip')". Default is skip.
-
-2. **Fire the transition** (only when a single confident task ID is resolved):
-
-   ```bash
-   pnpm elevasis-sdk project:task:update <task-id> --status submitted
-   ```
-
-3. **Failure handling.** If the CLI call errors, no task ID can be resolved, or the user declines, emit a single warning line and continue:
-
-   ```
-   Warning: skipped project:task status transition (<reason>). Deploy itself succeeded.
-   ```
-
-   Never retry, never block the deploy report, never exit non-zero on this step.
-
-## Error Recovery
-
-If any step fails and cannot be auto-fixed:
-
-```
-Deploy Failed at Step N: [step name]
-=====================================
-Error: [description]
-Attempted fixes: [what was tried]
-Manual action needed: [what the user should do]
-```

package/reference/claude-config/skills/dsp/SKILL.md

@@ -1,66 +0,0 @@
----
-name: dsp
-description: Dispatch subagents in parallel for implementation tasks
----
-
-# DSP -- Dispatch Subagents in Parallel
-
-Parallel agent dispatch for implementation tasks. Orchestrate, then delegate to subagents.
-
-**Usage:** `/dsp <instructions>`
-
-## Rules
-
-1. **Always dispatch, never self-execute** -- the purpose is to offload work to subagents
-2. **Parallel within waves** -- all agents in a wave dispatched in a SINGLE message
-3. **Orient first** -- read `.claude/rules/agent-start-here.md` before planning to understand project structure and task routing
-
-## Process
-
-### Step 1: Understand Context
-
-1. Read `.claude/rules/agent-start-here.md` for project structure, task-class routing, and boundary resolution
-2. Read relevant architecture/feature docs based on the task domain
-3. If the task touches code, explore the relevant `src/` directories
-
-### Step 2: Analyze Complexity
-
-**Single-Wave** -- all tasks independent, dispatch everything at once
-**Multi-Wave** -- tasks have dependencies, execute waves sequentially
-
-### Step 3: Plan
-
-For each unit of work, identify:
-
-- What files/areas are affected
-- What context the subagent needs
-- Whether it depends on another task's output
-
-Print the plan:
-
-```
-DSP Plan: N waves, M tasks
-Wave 1: [description] -- N tasks
-Wave 2: [description] -- N tasks (if multi-wave)
-Dispatching Wave 1...
-```
-
-### Step 4: Dispatch
-
-Use the Agent tool with `subagent_type="general-purpose"` and `model="sonnet"`.
-
-Each agent prompt must include:
-
-- The specific task to accomplish
-- Relevant file paths and context
-- Instruction to use backslash paths for file operations on Windows
-
-### Step 5: Aggregate Results
-
-```
-DSP Results: [description]
-
-Tasks completed: X/Y
-Files modified: [list]
-Next steps: [if any]
-```