---
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

```bash
pnpm lint
```

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]
```
