---
name: ironbee-sync-scenario
description: >
  Re-validate saved IronBee verification scenarios against the current code and repair MECHANICAL
  drift, by driving the scenario-* MCP tools yourself. Use when the user types
  `$ironbee-sync-scenario`. A leading `check` token = dry-run (report drift, no repair).
---

# IronBee — Sync scenario(s)

This project runs IronBee in **main-agent** mode — the devtools `*_scenario-*` MCP tools are wired
into THIS session, so **you** drive them. Re-validate + repair saved verification **scenarios**. This
is NOT a verification cycle — no verdict, no gate.

## Steps
1. **Resolve mode + target**: strip a leading `check` token (→ dry-run) and a leading `force` token
   (→ include ALL scenarios, not just stale); remainder = `all` (stale ones; with `force`, every one)
   or a name / description (one). Empty → `all`. **Print the target list + count before running.**
   Run targets that share an `ironbee.group` in ascending `ironbee.order` (a flow split across platforms).
2. **For each target scenario** (resolve via `*_scenario-search` / `*_scenario-list`; `all` = the stale
   ones — covered files changed since their `ironbee.commit`, or authored as drafts) **run it**
   (`*_scenario-run`, against the live app — start it if needed, tear down what you started) and classify:
   - **passes** → still current; (non-check) `*_scenario-update` to stamp `ironbee.commit` → HEAD
     (read via `git rev-parse HEAD`) + `ironbee.liveValidated: true`. `*_scenario-update`
     shallow-replaces metadata — read current metadata and re-send it MERGED with these two keys
     (don't drop `coveredPaths` / `group` / `argsSchema`).
   - **mechanical DRIFT** (the way to reach / drive the flow changed, not the expected outcome) →
     repair the SCRIPT mechanics only, `*_scenario-update`, re-run until green, then stamp.
   - **real DEFECT** (the expected outcome is unreachable — the app broke) → **STOP, report, do NOT
     touch the scenario.**
   - **expectation CHANGED** (a deliberate behavior / spec change) → do NOT auto-edit the assertion;
     ask the user.
   - **`check` mode** → only run + report drift; never repair / update.
   - **Classify safely** (repair is the only branch that edits a scenario, so a defect mistaken for
     drift masks a regression): before repairing, self-check whether the fix changes *how* the flow
     is driven (drift — OK to repair) or *what* it asserts (never drift — a defect → STOP, or a
     deliberate change → ask). A failure while reaching / driving the flow leans drift; a failure at
     the terminal assertion leans defect. **Uncertain → treat as a defect and STOP.**
3. **Report** per scenario: repaired / still-fresh / defect-reported / needs decision.

**Hard rule: repair MECHANICS, never the ASSERTION / expected outcome** — silently relaxing an
assertion to make a stale scenario pass would mask a regression. (To just *detect* staleness without
running anything, use `ironbee scenario status`.)

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

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

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

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

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