--- name: ironbee-verify description: > Verify the current code changes by driving the IronBee verification tools yourself — runs every active cycle wired up for this project (see the platform sections at the bottom). Use when the user types `$ironbee-verify`. Default is verify-only (report the verdict and stop); a leading `fix` argument adds the fix-and-re-verify loop until pass. Optionally pass a custom scenario (inline text or a file path) that defines what to verify. --- # IronBee Verify Verify the current code changes through real tools. This project runs IronBee in **main-agent** mode — the devtools tools (`mcp__browser-devtools__*` / `mcp__node-devtools__*` / `mcp__backend-devtools__*` / `mcp__android-devtools__*`) are wired into THIS session, so **you** drive them (there is no verifier sub-agent). The gate runs every active cycle and all must be satisfied within a single verification cycle for `status: pass`. The verdict shape is platform-agnostic (`status`, `checks`, `issues?`, `fixes?`); the gate enforces that you called each active cycle's required tools and that `checks` is non-empty. Your **Session ID** is injected into your context by the SessionStart hook (a `Session ID: ` line); author it in every `ironbee hook` command's JSON. ## 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, and STOP — do **not** edit code, do **not** re-verify. The fail verdict is still recorded (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 — either **inline text** or a **path to a file** (read at run time). The scenario is whatever the user provided alongside the command, after stripping a leading `fix` / `report` mode token. - **If the scenario part starts with `scenario:`** (after the mode token), everything after `scenario:` (to the end) is a **SAVED scenario reference** (exact name OR semantic description). Resolve it across enabled platforms (`*_scenario-search` for the description + an exact-name `*_scenario-list` match), pick the single strong match (ambiguous → ask; none → say so + fall back to the default flow), then **run it in ONE `*_scenario-run` call** (no re-discovery) and **judge its result (functional) + any returned visual evidence (e.g. screenshots)**. Its nested tool calls satisfy each active cycle's required tools. 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, exercising precisely the flows/states/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 and treat its contents as the scenario. Do not assume a fixed location or format. - **If the path does not resolve**, stop and report `scenario file not found: `, then ask how to proceed — do not verify the literal path string. - **If no scenario is supplied**, fall back to exercising the changed pages/endpoints per the active platform sections below. ## Universal steps 1. **Start verification — run this ALONE first** (Codex runs shell and MCP tools in separate lanes, so the open must land before any devtools call): ``` echo '{"session_id":""}' | ironbee hook verification-start ``` **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 ``` 2. **Build and start** the application if not already running (don't guess ports). Track what YOU started. 3. **For every active cycle, run its flow** — driven by the scenario above when supplied, otherwise per the platform sections near the bottom of this file. All active cycles must be exercised within this same verification cycle. 4. **Stop** only what you started (dev server / container), then honor any cycle-specific teardown (e.g. recording stop) BEFORE the verdict. 5. **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":["..."]}' | ironbee hook submit-verdict` 6. **If failed** → collect ALL issues first (finish every active cycle) and submit ONE fail verdict. Then branch by mode: - **Verify-only (default)**: report the issues and stop — do not edit code. Suggest `$ironbee-verify fix`. - **Fix mode (`fix` token)**: fix everything, rebuild, and re-verify until pass. Batch fixes to avoid repeated build/restart cycles. 7. 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 — you MUST submit a **fail** verdict. Do NOT rationalize problems away. A FALSE failure (a valid, in-scope operation that should succeed but errors) is a FAIL, not "verified failure handling". ## 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. - Every `apply_patch` edit clears your verdict — re-verify after edits.