mobius-broken-flow

mobius-broken-flow

"It doesn't work" arrives with nothing to grep for — no stack trace, no message, just a control that seems inert or a flow that dies partway. That could be six different bugs, and reading source won't tell you which. Driving it while watching the runtime will, in one pass.

Don't ask the user to click anything. Drive it yourself and let the action report what it caused.

When to use this

• A button, link, or form that "does nothing," with no console error reported.
• A multi-step flow (signup, checkout, upload) that fails at a step nobody can pin down.
• A feature that used to work and now silently no-ops.
• Before digging through source — confirm what actually happens first.

Workflow

1. mobius_diagnose. If it isn't ready, relay the remediation and stop.
2. clear_logs — without a clean baseline, "nothing happened" is ambiguous between truly nothing and buried in noise.
3. find({ query: "..." }) to locate the control by description ("submit order button"). Check totalMatched: exactly one is a confident hit, several means disambiguate by name/role/box before acting. Fall back to snapshot_page({ viewportOnly: true }) to survey if find comes back empty.
4. Act with an observation window. click(ref, { observe: { windowMs: 3000 } }). For a multi-step flow use run_sequence, giving the step you suspect its own observe. Address steps by CSS selector rather than ref if they follow a navigation — refs go stale, selectors resolve at step time.
5. Read hitTest before anything else. If it's "blocked", that is the bug and the rest of the timeline is a red herring:
   • covered — hitTestBlockedBy names the element eating the input. A modal backdrop, toast, or spinner left mounted; a full-screen opacity: 0 layer without pointer-events: none. take_screenshot or capture_element to see it.
   • pointer_events — the target has pointer-events: none, often paired with a disabled state styled to look enabled.
   • offscreen — the target's centre is outside the viewport. scroll_to first, then retry.
6. Otherwise diagnose from observed:
   • Empty — first confirm it's real: check notCaptured in the response. If a category is off, you're blind, not looking at silence. If capture is on and it's genuinely empty, the handler never ran — see "Nothing fired" below.
   • Console, no network — client-side logic ran and stopped short. Validation blocked it, an exception was swallowed by an empty catch, or state changed and nothing downstream reacted.
   • Request failed outright (error, or 4xx/5xx) — a real error that never reached the UI. Find the missing .catch() or error boundary.
   • Request returned 200 but nothing changed — read responseBody before touching frontend code. See "Successes that aren't" below.
7. Only now grep source, using what you learned to look for the specific gap.