---
name: submit-request
description: Submit a structured request report to the Elevasis platform via CLI — enforces pre-analysis before posting
---

# Submit Request

Submit a structured request report to the Elevasis platform. The agent performs a six-phase analysis before posting so that every submitted request includes meaningful context, not just a one-liner.

**Usage:** `/submit-request [optional description]`

If a description is provided, it is the primary signal for Phase 1. Otherwise the agent analyzes recent conversation context plus any active error context.

## Env Requirements

`ELEVASIS_PLATFORM_KEY` must be present in the project's root `.env` (the same key used by all other `elevasis-sdk` commands — no additional setup needed if deploy is already working).

The organization and API base URL are resolved automatically by the CLI. No `ELEVASIS_API_KEY` or `ELEVASIS_API_URL` needed.

## 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 request 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 (if applicable):

- 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. For feature requests or questions, this phase may produce an empty `evidence` object — that is expected.

### Phase 4: Select Type and Classify Severity and Category

Select exactly one value for **type first**, then **severity**, then **category**:

**Type:**

| Value      | When to use                                        |
| ---------- | -------------------------------------------------- |
| `bug`      | Something is broken or behaving incorrectly        |
| `feature`  | A new capability or enhancement request            |
| `question` | Asking for clarification, guidance, or explanation |
| `other`    | Doesn't fit the above                              |

**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 |
| `feature_request`     | New feature or enhancement being requested             |
| `api_design`          | Feedback on API contract, naming, or behavior          |
| `documentation`       | Missing, incorrect, or unclear documentation           |
| `integration_request` | Request for a new integration or adapter               |
| `other`               | Doesn't fit above                                      |

### Phase 5: Build Structured Report

Assemble the report body from phases 1–4:

```json
{
  "title": "One-line summary — specific, not vague",
  "description": "What happened. What was expected. Steps to reproduce if applicable.",
  "type": "<bug|feature|question|other>",
  "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 request is clearly scoped to a specific project or task visible in context.

Do NOT include `source` or `organization_id` — the server sets both automatically.

### Phase 6: Confirm with User

Unless the command was invoked with `--auto`, present the assembled report to the user before submitting:

```
Request Report (ready to submit)
================================
Title:    <title>
Type:     <type>
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`), write the assembled JSON body to a temp file under the project-root `tmp/` directory, then submit via the SDK CLI:

```bash
# Write the report body to tmp/request-report.json from the project root
# The template keeps tmp/ gitignored for transient CLI payloads

pnpm elevasis-sdk request:submit -f tmp/request-report.json --cleanup-input --pretty
```

`--cleanup-input` removes the temp file automatically after a successful submission. If the command fails, leave the file in `tmp/` for inspection.

## Report Back

On success, the CLI prints the request ID. Surface it to the user:

```
Submitted — id: <uuid>
Track it in Command Center > Requests.
```

## Troubleshooting

| Error                           | Cause                                                             | Fix                                                                                                           |
| ------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| `ELEVASIS_PLATFORM_KEY` missing | Key not set in root `.env`                                        | Add `ELEVASIS_PLATFORM_KEY=sk_...` to `.env`. Provision from Command Center > Settings > API Keys.            |
| `401 Unauthorized`              | Key is malformed or revoked                                       | Verify the key starts with `sk_` and is 67 chars. Re-provision if needed.                                     |
| `403 Forbidden`                 | Key's org lacks access to request reporting                       | Contact the platform operator to verify the key's org permissions.                                            |
| `Invalid request body`          | Report failed CLI-side Zod validation before the request was sent | Read the field errors printed by the CLI. Common causes: missing `title`/`description`/`type`, invalid enum.  |
| `400 Bad Request`               | Body passed CLI validation but failed server-side validation      | Read the response body for the specific field error.                                                          |
| Connection refused              | API server unreachable                                            | Default target is `https://api.elevasis.io` — check network. For local dev, set `ELEVASIS_API_URL` in `.env`. |
