# Feeding Launch Readiness (Deploys & Tests)

Launch Readiness rolls up a single 0–100% score from five checks. Three of them populate themselves from data already in iKanban; two are fed by your own pipeline. This page explains how to feed them — the same way iKanban tracks its own delivery (DORA) metrics.

Use [Releases](/docs/teams-projects/releases) to create releases and assign issues. For progress charts and scope change, see [Release Analysis](/docs/teams-projects/release-analysis); that view is separate from this readiness score.

## What feeds each axis

| Axis             | Source                                                | Setup needed                              |
| ---------------- | ----------------------------------------------------- | ----------------------------------------- |
| **Scope**        | Your release's issues (done vs. total)                | None — automatic                          |
| **Quality**      | Bug-type issues in the release                        | None — automatic                          |
| **Ops**          | The launch checklist (docs / feature flag / rollback) | Toggle + link evidence in the app         |
| **Verification** | Recorded test runs                                    | "Record test run" button, or POST from CI |
| **Stability**    | Tracked deployments (change-failure rate)             | POST from your deploy pipeline            |

Scope, Quality and Ops need nothing — keep your issues and checklist up to date. **Verification** and **Stability** are the two you wire up.

## Step 1 — Create an API key

Go to **Settings → API Keys** and create a key. Store it in your CI secret manager and send it as a bearer token. The deployment and test-run routes shown here are agent-facing routes that accept API-key authentication; this does not make every `/api` route available to API keys. See [Setup and Access](/docs/getting-started/setup) for browser-session-only operations.

```
Authorization: Bearer vk_your_key_here
```

## Step 2 — Stability: report each deploy

Every time you deploy, POST a record. Start it when the deploy begins, then mark success/failure when it finishes.

**Start a deploy**

```bash
curl -s -X POST "https://api.i-kanban.com/api/deployments" \
  -H "Authorization: Bearer $IKANBAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "app_name": "frontend",
        "environment": "prod",
        "commit_sha": "'"$GIT_SHA"'",
        "deployed_by": "ci",
        "status": "started"
      }'
# → returns { "data": { "id": "<deployment-id>", ... } }
```

**Finish it** (set the outcome + duration):

```bash
curl -s -X PUT "https://api.i-kanban.com/api/deployments/<deployment-id>" \
  -H "Authorization: Bearer $IKANBAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "status": "success", "duration_seconds": 92 }'
```

Fields: `app_name` (must match your project name so the release can attribute it), `environment` (`dev` / `prod` / …), `commit_sha`, optional `version` / `deployed_by`, and `status` (`started` → `success` | `failure`). Stability = the change-failure rate over these records in the release window.

### GitHub Actions example

```yaml
- name: Report deploy to iKanban
  if: always()
  run: |
    STATUS=${{ job.status == 'success' && 'success' || 'failure' }}
    curl -s -X POST "https://api.i-kanban.com/api/deployments" \
      -H "Authorization: Bearer ${{ secrets.IKANBAN_API_KEY }}" \
      -H "Content-Type: application/json" \
      -d "{\"app_name\":\"frontend\",\"environment\":\"prod\",\"deployed_by\":\"github-actions\",\"commit_sha\":\"${{ github.sha }}\",\"status\":\"$STATUS\"}"
```

That is exactly how iKanban records its own deploys — each row you see under the **Stability** drill-down is one of these calls (commit · environment · status · time).

## Step 3 — Verification: report test runs

**Easiest — no setup:** on the Verification row, click **Record test run** and enter passed / total. No IDs or API key needed — use this if you don't have CI wired up.

**From CI** (after your suite runs):

```bash
curl -s -X POST \
  "https://api.i-kanban.com/api/teams/{TEAM_ID}/projects/{PROJECT_ID}/test-runs" \
  -H "Authorization: Bearer $IKANBAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "total": 22, "passed": 18, "failed": 4, "suite": "e2e" }'
```

Fields: `total`, `passed`, `failed`, optional `suite`, and optional `release_id` (omit it and the run auto-attributes to the project's active release). Verification = the latest run's pass rate.

> **Getting `{TEAM_ID}` / `{PROJECT_ID}`** — these are UUIDs, _not_ the slugs (e.g. `IKA` / `frontend`) shown in the browser URL. Fetch them with your API key:
>
> ```bash
> curl -s "https://api.i-kanban.com/api/teams" \
>   -H "Authorization: Bearer $IKANBAN_API_KEY"
> ```
>
> The response lists each team's `id` and its projects. (Stability doesn't need this — it keys on the project **name** via `app_name`.)

## How the score updates

Once deploys and test runs are flowing, Stability and Verification light up automatically and the composite score (and the **ship gate**) reflect real delivery data — no manual upkeep. Open any axis on the scorecard to drill into the underlying issues, deploys, test runs or checklist items.
