@elevasis/sdk 1.5.4 → 1.6.0

package/reference/scaffold/reference/feature-registry.md

@@ -25,7 +25,7 @@ Feature IDs defined in `DEFAULT_ORGANIZATION_MODEL.features` (`packages/core/src
 
 ```typescript
 // FeatureSchema: { id, label, enabled, color?, icon?, entityIds, surfaceIds, resourceIds, capabilityIds }
-type DefaultFeatureId = 
+type DefaultFeatureId = 'submitted-requests'
 ```
 
 These are the built-in feature IDs. The `featureId` field on a `FeatureModule` manifest must match the `id` of a feature in the organization model to enable access-flag gating.

package/reference/claude-config/commands/submit-issue.md

@@ -1,12 +0,0 @@
-# Submit Issue
-
-**Usage:** `/submit-issue [optional one-line description]`
-
-**Goal:** File a structured issue report to the Elevasis platform after agent-driven pre-analysis.
-
-**EXECUTE:** `.claude/skills/submit-issue/SKILL.md`
-
-## Env Requirements
-
-- `ELEVASIS_API_URL` (base URL of the Elevasis API)
-- `ELEVASIS_API_KEY` (Bearer `sk_*`, provisioned via Command Center → Settings → API Keys)

package/reference/claude-config/skills/submit-issue/SKILL.md

@@ -1,179 +0,0 @@
----
-name: submit-issue
-description: Submit a structured issue report to the Elevasis platform via API — enforces pre-analysis before posting
----
-
-# Submit Issue
-
-Submit a structured issue report to the Elevasis platform. The agent performs a six-phase analysis before posting so that every submitted issue includes meaningful context, not just a one-liner.
-
-**Usage:** `/submit-issue [optional description]`
-
-If a description is provided, it is the primary signal for Phase 1. Otherwise the agent analyzes recent conversation context (~20 messages) plus any active error context.
-
-## Env Requirements
-
-Both variables must be present in the project's root `.env`:
-
-| Variable           | Description                                                                                   |
-| ------------------ | --------------------------------------------------------------------------------------------- |
-| `ELEVASIS_API_URL` | Platform API base URL (e.g. `https://api.elevasis.io`)                                        |
-| `ELEVASIS_API_KEY` | API key starting with `sk_` (67 chars), provisioned from Command Center > Settings > API Keys |
-
-The organization is resolved server-side from the key. Never include an `organization_id` in the request body.
-
-## Pre-Analysis Phases
-
-Complete all six phases before assembling the report or asking for confirmation. Do not skip phases — they ensure the submitted record is actionable.
-
-### Phase 1: Collect Context
-
-Gather available context:
-
-- If the user provided a description with the command, treat it as the primary signal.
-- Otherwise review the last ~20 conversation messages for error output, failed commands, unexpected behavior, and any `explain_page` / active error context.
-- Ask one targeted follow-up question if a key detail is ambiguous. Do not fire multiple questions at once.
-
-### Phase 2: Identify Source
-
-Pinpoint where the issue originates:
-
-- File paths (if a code or config file is involved)
-- Workflow or agent resource IDs (if a platform execution failed)
-- Execution IDs (if available in logs or prior output)
-- Route or page path (if a UI issue)
-
-Record these for the `evidence` and `affected_page` fields.
-
-### Phase 3: Gather Errors
-
-Extract concrete error signals:
-
-- Full error messages and stack traces (truncated to the relevant portion)
-- HTTP status codes and response bodies
-- Log lines with timestamps if available
-- Screenshots or screenshot file references if the user provided them
-
-These go into the `evidence` object.
-
-### Phase 4: Classify Severity and Category
-
-Select exactly one value for each:
-
-**Severity:**
-
-| Value      | When to use                                                         |
-| ---------- | ------------------------------------------------------------------- |
-| `critical` | Data loss, security breach, complete feature outage, blocked deploy |
-| `warning`  | Degraded behavior, partial failure, noticeable but recoverable      |
-| `info`     | Minor UX glitch, cosmetic bug, improvement suggestion               |
-
-**Category:**
-
-| Value                | When to use                                            |
-| -------------------- | ------------------------------------------------------ |
-| `ui_bug`             | Frontend rendering or interaction problem              |
-| `data_inconsistency` | DB records, API responses, or UI state don't match     |
-| `performance`        | Slow load, timeout, high resource usage                |
-| `error_pattern`      | Recurring or systematic error across executions        |
-| `configuration`      | Misconfigured resource, credential, env var, or policy |
-| `other`              | Doesn't fit above                                      |
-
-### Phase 5: Build Structured Report
-
-Assemble the request body from phases 1–4:
-
-```json
-{
-  "title": "One-line summary — specific, not vague",
-  "description": "What happened. What was expected. Steps to reproduce if applicable.",
-  "severity": "<critical|warning|info>",
-  "category": "<category value>",
-  "affected_page": "<route or page path, omit if not a UI issue>",
-  "evidence": {
-    "errors": ["<error message or stack trace excerpt>"],
-    "log_snippets": ["<relevant log lines>"],
-    "screenshot_refs": ["<file path if user provided a screenshot>"]
-  },
-  "context": {
-    "source_files": ["<file paths>"],
-    "resource_ids": ["<workflow or agent IDs>"],
-    "execution_ids": ["<execution IDs>"],
-    "summary": "<one-paragraph agent analysis summary>"
-  }
-}
-```
-
-Omit any field that has nothing meaningful to record. `project_id` and `task_id` are optional UUID fields — include them only if the issue is clearly scoped to a specific project or task visible in context.
-
-### Phase 6: Confirm with User
-
-Unless the command was invoked with `--auto`, present the assembled report to the user before submitting:
-
-```
-Issue Report (ready to submit)
-================================
-Title:    <title>
-Severity: <severity>
-Category: <category>
-Page:     <affected_page or "—">
-
-Description:
-  <description>
-
-Evidence:
-  <summarized evidence>
-
-Context:
-  <summarized context>
-
-Submit? (yes / edit / cancel)
-```
-
-If the user says "edit", accept corrections and re-display the updated report before proceeding.
-If the user says "cancel", abort and confirm: "Submission cancelled."
-Auto-submit (`--auto`) skips this confirmation entirely — use only when the caller is a trusted agent pipeline.
-
-## Submit
-
-Once confirmed (or `--auto`), POST to the external issues endpoint:
-
-```bash
-curl -sS -X POST "${ELEVASIS_API_URL}/api/external/issues" \
-  -H "Authorization: Bearer ${ELEVASIS_API_KEY}" \
-  -H "Content-Type: application/json" \
-  -d @- <<'JSON'
-{
-  "title": "...",
-  "description": "...",
-  "severity": "warning",
-  "category": "ui_bug",
-  "affected_page": "/projects/abc",
-  "evidence": {},
-  "context": {}
-}
-JSON
-```
-
-Do NOT include `source` or `organization_id` in the body — the server sets both automatically.
-
-## Report Back
-
-On a successful response (2xx), surface the issue ID to the user:
-
-```
-Submitted — id: <uuid>
-Track it in Command Center > Issues.
-```
-
-If the response body contains additional fields (status, created_at), include them in a brief one-line summary.
-
-## Troubleshooting
-
-| Status             | Cause                                                             | Fix                                                                                                                                           |
-| ------------------ | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
-| `401 Unauthorized` | `ELEVASIS_API_KEY` is missing, malformed, or revoked              | Verify the key in root `.env` starts with `sk_` and is 67 chars. Re-provision from Command Center > Settings > API Keys if needed.            |
-| `403 Forbidden`    | Key exists but the associated org lacks access to issue reporting | Contact the platform operator to verify the key's org permissions.                                                                            |
-| `400 Bad Request`  | Request body failed validation                                    | Read the response body for the specific field error. Common causes: missing `title` or `description`, invalid `severity` or `category` value. |
-| `404 Not Found`    | `ELEVASIS_API_URL` is wrong or the endpoint path has a typo       | Confirm the URL in `.env` (no trailing slash) and that the path is exactly `/api/external/issues`.                                            |
-| Connection refused | API server unreachable                                            | Check `ELEVASIS_API_URL` and network connectivity. For local dev, confirm the API server is running.                                          |