---
name: ironbee-verify
description: >
  Manually trigger an IronBee verification cycle for the current code changes.
  Use when the user types `$ironbee-verify` to explicitly run the verify flow,
  or when you need to verify ad-hoc outside the normal post-edit gate. Runs the
  full multi-cycle verification (browser/node/backend as configured) and
  submits a verdict. Default is verify-only (report the verdict and stop); a
  leading `fix` argument adds the fix-and-re-verify loop until pass. A custom
  scenario may ride along with the invocation — inline text or a path to a
  scenario file — defining exactly what to verify.
---

# IronBee Verify

Verify the current code changes through real tools. The gate runs every cycle that has been wired up for this project, and all active cycles must be satisfied within a single verification cycle for `status: pass`. Each cycle has its own tools and flow — **see the platform sections near the bottom of this file** for which cycles apply and what to call. The verdict shape itself is platform-agnostic (`status`, `checks`, `issues?`, `fixes?`); the gate enforces that you called each cycle's required tools and that `checks` is non-empty.

## Mode

The FIRST whitespace-delimited token of whatever the user provided alongside `$ironbee-verify` selects the mode; everything after it is the scenario:

- `fix` → **verify-and-fix**: on a fail verdict, fix the reported issues, rebuild, and re-verify until the verdict passes.
- `report` → **verify-only** (the explicit form of the default).
- Anything else, or nothing → **verify-only** (default), and the WHOLE provided text is the scenario.

**Verify-only** means: submit the (possibly fail) verdict, report the issues to the user, and STOP — do **not** edit code, do **not** re-verify. The fail verdict is still recorded (that's the point — an honest status report). If the user wants the issues repaired, suggest `$ironbee-verify fix`. The mode token never overrides the gate: if enforcement blocks completion because of this turn's edits, follow the gate.

## Verification scenario

A custom verification scenario may be supplied when this command is invoked — either as **inline text** or as a **path to a file** (any location, any format; it is read at run time). The scenario is whatever the user provided alongside invoking this command, after stripping a leading `fix` / `report` mode token (see **Mode**).

- **If a scenario is supplied, it is authoritative**: verify exactly what it describes. Drive each active cycle's tools to exercise precisely the flows, states, and endpoints it names — this **replaces** the default "exercise the changed pages/endpoints" guidance.
- **If the scenario is (or points to) a file path**, read that file with your file-read tool and treat its contents as the scenario. Do not assume a fixed location or format — read whatever path was given.
- **If the path does not resolve to an existing file**, stop and report `scenario file not found: <path>`, then ask how to proceed — do not verify the literal path string or guess a target.
- **If no scenario is supplied**, fall back to the default flow: exercise the changed pages/endpoints per the active platform sections below.

Whatever the scenario directs, the gate is unchanged — you must still call every active cycle's required tools and submit a non-empty `checks`. Map each `checks` entry to a concrete scenario step/expectation, and each `issues` entry to a scenario step that failed.

## Universal steps

1. **Start verification**: Run `echo '{"session_id":"<your-session-id>"}' | ironbee hook verification-start` via Bash (substitute the actual session ID printed by the SessionStart hook).
   **In fix mode**, add the intent flag so IronBee's completion gate enforces fix-until-pass:
   `echo '{"session_id":"<your-session-id>"}' | ironbee hook verification-start --intent fix`
2. **Build and start** the application if not already running.
3. **For every active cycle, run its flow** — driven by the **Verification scenario** above when one was supplied, otherwise as described in the platform sections near the bottom of this file. All active cycles must be exercised within this same verification cycle.
4. **Stop** the dev server when verification is complete (every cycle — including the final one).
5. **Honor any cycle-specific teardown** noted in the platform sections BEFORE submitting your verdict.
6. **Submit your verdict** via Bash. One verdict covers every active cycle:
    - Pass: `echo '{"session_id":"...","status":"pass","checks":["..."]}' | ironbee hook submit-verdict`
    - Fail: `echo '{"session_id":"...","status":"fail","checks":["..."],"issues":["describe what failed"]}' | ironbee hook submit-verdict`
7. **If failed** → collect ALL issues first (finish testing every active cycle) and submit ONE fail verdict with all issues. Then branch by mode:
   - **Verify-only (default)**: report the issues to the user and stop — do not edit code. Suggest `$ironbee-verify fix` to repair them.
   - **Fix mode (`fix` token)**: fix everything, rebuild, and re-verify until pass. Do not fix one issue at a time — batch fixes to avoid repeated build/restart cycles.
8. If pass after a previous fail, include `"fixes"` in the verdict describing what was fixed.

---

<!--IRONBEE:PLATFORM:browser-->
<!--/IRONBEE:PLATFORM:browser-->

<!--IRONBEE:PLATFORM:node-->
<!--/IRONBEE:PLATFORM:node-->

<!--IRONBEE:PLATFORM:backend-->
<!--/IRONBEE:PLATFORM:backend-->

<!--IRONBEE:PLATFORM:android-->
<!--/IRONBEE:PLATFORM:android-->

---

## When to FAIL

If you observe ANY problem on any active cycle — wrong data, unexpected errors, broken interactions, missing evidence, anything that doesn't match the spec — you MUST submit a **fail** verdict.

**Do NOT rationalize away problems.** If something looks wrong or behaves unexpectedly, it IS wrong.

**After a fail verdict in fix mode, you MUST fix the issues and re-verify** — do not just report and stop. In verify-only mode (the default) the opposite holds: report and stop; fixing without the `fix` token is overstepping.

## Verdict Quality

Your `checks` array must list **specific observations**, not generic statements:
- GOOD: `["login form renders with email and password fields", "submitted valid credentials, redirected to /dashboard", "console clean — 0 errors"]`
- BAD: `["it works", "looks good", "feature implemented"]`

## Important
- ALWAYS submit a verdict after every verification attempt — both pass AND fail
- Do NOT edit code before submitting a fail verdict
- **Noticing a bug and submitting pass is the #1 violation** — if you see it, fail it