--- argument-hint: "[fix|report] [scenario: | scenario text | path to scenario file]" description: Delegate verification of the current code changes to the ironbee-verifier sub-agent. Default is verify-only (report the verdict and stop); a leading `fix` argument adds the fix-and-re-verify loop until pass. Pass `scenario:` to run a SAVED scenario (fast, no re-discovery), or a custom scenario (inline text / file path) defining what to verify. --- # IronBee Verify Verify the current code changes by **delegating to the `ironbee-verifier` sub-agent**. It drives the verification tools out-of-band in this **shared session** and returns a verdict summary — so the heavy devtools output (DOM, console, screenshots) stays in its context, not yours. **You do not run the verification tools yourself**: you resolve the mode and scenario (below), spawn the verifier, and relay its result. The gate still runs every active cycle and all must pass for `status: pass`. ## Mode The FIRST whitespace-delimited token of the arguments selects the mode; everything after it is the scenario: - `fix` → **verify-and-fix**: on a fail verdict, fix the reported issues and re-delegate until the verdict passes. - `report` → **verify-only** (the explicit form of the default). - Anything else, or no arguments → **verify-only** (default), and the WHOLE argument string is the scenario. **Verify-only** means: relay the verdict and STOP — do **not** edit code, do **not** re-delegate on fail. The fail verdict is still submitted and recorded (that's the point — an honest status report). If the user wants the issues repaired, suggest `/ironbee-verify fix`. One caveat (enforce mode): if code was edited earlier in THIS turn, the Stop gate may still block on the fail verdict and demand fixes — follow the gate then; the mode token never overrides enforcement. ## Verification scenario > Mode + scenario argument: `$ARGUMENTS` > *(strip a leading `fix` / `report` mode token first — the remainder is the scenario part)* The scenario part (after the optional mode token) is one of three forms: - **A SAVED scenario** — the remainder **starts with `scenario:`**. Then **everything after `scenario:` (to the end) is the reference** — an exact name OR a semantic description (`scenario:` must come AFTER the mode token; it consumes the rest of the line). Do NOT read a file or treat it as free text. Relay it to the verifier verbatim as a `Saved scenario: ` line; the verifier resolves it (`scenario-search` semantic + exact-name match), runs it in one `scenario-run` call (no re-discovery), and judges the result (functional + any visual evidence it returned). (No exact name needed — a description like `scenario: the full purchase flow` works; the verifier picks the match, asks if ambiguous, falls back to discovery if none.) - **A free-text scenario** — inline text describing what to verify. Authoritative: the verifier exercises exactly what it names (replaces the default "exercise the changed pages/endpoints"). - **A file path** — read that file yourself and pass its **contents** to the verifier (it has no file-read tool). If the path doesn't resolve, stop and report `scenario file not found: ` and ask how to proceed — don't delegate the literal path. **If no scenario part is supplied**, the verifier exercises the changed pages/endpoints per the active cycles. ## Steps 1. **Resolve the mode and scenario**: strip a leading `fix` / `report` token (see **Mode**); then on the remainder — starts with `scenario:` → it's a SAVED scenario reference (everything after `scenario:`); a file path → read it now; inline text → use as-is; empty → none. 2. **Spawn the verifier** via the Agent tool with `subagent_type: "ironbee-verifier"` and a prompt that states the task, the mode, and the scenario, e.g.: > Verify the current code changes. > Mode: \<`fix` in fix mode — OMIT this line entirely in verify-only mode> > \` (when `scenario:` was given — the verifier resolves + runs it) — OR — `Scenario: ` (free text / file contents) — OR — `Scenario: none — exercise the changed pages/endpoints`>> The verifier runs `verification-start` (relaying the fix intent to IronBee's completion gate, which then enforces fix-until-pass on you) → drives every active cycle's tools → submits the single verdict, all in this shared session. It resolves the session id from the environment, so you don't pass one. **Wait for the verifier in the same turn — do NOT background it.** Let it run to completion and read its verdict before responding; a backgrounded verifier can let your turn end (and the Stop gate fire) before its verdict is recorded. 3. **Relay the verifier's summary** — the verdict status and, on fail, the issues it found. 4. **On a fail verdict, branch by mode**: - **Verify-only (default)**: stop here. Report the issues clearly and suggest `/ironbee-verify fix` to repair them. Do not edit code. - **Fix mode (`fix` token)**: fix the issues it reported. Optionally record what you fixed so the next pass verdict can describe it: ``` echo '{"fixes":["what you repaired"]}' | ironbee hook record-fix ``` Then re-run the verification by re-delegating (step 2) — repeat until the verdict passes. (If you skip `record-fix`, IronBee fills `fixes` from the files you changed since the fail.) Do NOT verify inline — always delegate, so your context stays clean. The per-cycle "how to verify" detail (which tools to drive, the verdict expectations) lives in the `ironbee-verifier` sub-agent itself — you don't need it here to delegate. --- ## What the verifier judges (so you know what to expect back) - It submits a **fail** verdict on ANY problem on any active cycle — wrong data, unexpected errors, broken interactions, missing evidence. It does not rationalize problems away. - Its `checks` are specific observations (e.g. `"submitted valid credentials, redirected to /dashboard"`, `"console clean — 0 errors"`), not `"it works"`. ## Important - The **verifier** produces the verdict; your job is to delegate, relay it, and — in fix mode — fix on fail. - **Fix mode only**: a fail verdict means you must fix the issues and re-delegate until pass. In verify-only mode (the default) you report and stop — fixing without the `fix` token is overstepping. - Never verify inline to "save a round trip" — delegation keeps your context clean and is the supported path.