--- name: ironbee-verify description: "Trigger verification of code changes — runs every active cycle wired up for this project (see the platform sections at the bottom of the file). Default is verify-only (report the verdict and stop); a leading `fix` argument adds the fix-and-re-verify loop until pass." disable-model-invocation: true --- # 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 this command 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 the scenario part starts with `scenario:`** (after the mode token), everything after `scenario:` is a **SAVED scenario reference** — an exact name OR a semantic description — **up to an optional ` args:` override boundary**. A ` args:` token (a space, then `args:`) splits it: text BEFORE it is the reference, text AFTER it is a JSON object of **override arguments** for the scenario's `params` (e.g. `scenario:checkout args:{ "baseUrl": "https://staging" }`); with no ` args:` the whole tail is the reference and the scenario runs with its **captured default params**. Resolve the reference across enabled platforms (`*_scenario-search` for the description + an exact-name `*_scenario-list` match), pick the single strong match (ambiguous → ask which; none → say so and fall back to the default flow), then **run it in ONE `*_scenario-run` call** (passing the override args when present — they override the scenario's captured defaults; no manual re-discovery) and **judge its result (functional) + any returned visual evidence (e.g. screenshots)**. The scenario's nested tool calls satisfy each active cycle's required tools (as long as it exercises them). No exact name needed — e.g. `scenario: the full purchase flow`. **On PASS, keep it fresh:** `*_scenario-update` its `ironbee.commit` → HEAD (`git rev-parse HEAD`) + `liveValidated: true` (re-send the full metadata merged); on FAIL / defect, don't stamp. - **If a scenario is supplied (free text), 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: `, 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":""}' | ironbee hook verification-start` via terminal. **In fix mode**, add the intent flag so IronBee's completion gate enforces fix-until-pass: `echo '{"session_id":""}' | ironbee hook verification-start --intent fix` 1.5. **Run the project checks FIRST (lint/test/…)**: `echo '{"session_id":""}' | ironbee hook run-checks` (generous shell timeout — they may take minutes). Runs the configured `verification.checks` and records the results the gate reads. **Key your next step off the FIRST LINE of its output:** **`CONCLUSIVE PASS …`** → the verification is ALREADY COMPLETE (IronBee submitted the pass verdict itself and closed the cycle) — do **NOT** drive any devtools tools, do **NOT** start another cycle, do **NOT** submit another verdict; report the result and stop. **`DEFERRED FAIL …`** → the verification WILL fail, but do **NOT** submit the fail yet: the named conclusive check(s) failed and your devtools work in this cycle is a **DIAGNOSIS** of those failures (it replaces the normal verification flow) — diagnose code-first — first read the failing check's output and the implicated source to form a hypothesis, then confirm with a single focused reproduction using the active cycle's tools (do NOT explore broadly or re-run the whole flow repeatedly), then submit a **FAIL** verdict whose `issues` carry your findings (a pass/N-A verdict is rejected while a conclusive check is red). **Anything else** → 🛑 **IF ANY REQUIRED CHECK FAILS, THE VERIFICATION HAS ALREADY FAILED — STOP.** It is **NOT your call** whether the failure is "just a fixture", "unrelated", or "pre-existing" — a required non-zero exit **IS** a failure. Do **NOT** touch the devtools tools or submit a pass; submit a **fail** verdict whose `issues` are the failing checks (the gate enforces the fix). Only when **every** required check PASSES do you continue. ("no checks configured" → just continue.) 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 terminal. 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. --- --- ## 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