[Bug] DevTools->Network assertions unreliable for XHRs triggered by a prior action (per-step capture resets)

[tlemmonds]

Environment: kane-cli 0.4.10 (verified latest on npm) · Node 24 · Windows 11 · account toddl

Summary

DevTools -> Network assertions are unreliable for an HTTP request that was triggered by a preceding action, because the network capture resets per internal agent-step. By the time the agent runs the network analyze, the request fired by an earlier action has already been flushed, so the assertion never finds it.

Steps to reproduce

_test.md step:

Navigate to the servicing portal login page.
Log in as 'nina.castellano' with password 'Demo1234!'.
Assert that the `GET /api/loans/L2001` network request returned HTTP status 200.
Store the response body of the `GET /api/loans/L2001` network request as {{api_loan}}.

The SPA fires GET /api/loans/L2001 (and /schedule) as an XHR on successful login.

Actual

• The login click and the network analyze are authored as separate internal agent-steps.
• ANALYZE(devtool_network, 'the HTTP status code returned by the GET /api/loans/L2001 network request') returns success:false — repeatedly (steps 4, 5, 6, 8 in one run) — because the request fired during the login agent-step and the per-step capture flushed before the analyze agent-step ran.
• The agent then tried to hard-refresh the dashboard to re-trigger the calls, which drops the SPA's in-memory auth -> redirect to login -> the loan XHR never fires. Run ends failed.

Impact

Network-layer UI<->API reconciliation (assert status + read the response body of the app's own API traffic) is impractical for anything triggered by a preceding UI action — which is the common case (data loads on login / navigation / button click). The documented guidance ("assert on traffic in the same step it happens") is defeated by the planner splitting the triggering action and the assertion into different agent-steps.

Expected

One of:

• Widen network capture to a rolling window across the whole testmd step (don't reset on every internal action), or
• Expose a way to pin "capture request matching <pattern> for the duration of this step" so a later assertion can read a request fired earlier in the same step.

Related

• Depends on the same subsystem as generate planner marks API calls UNSUPPORTED_OPERATION though the v16 runtime executes them #121 (v16 API/network capability).
• Complements the execute_api inline-URL bug (filed separately) — together they mean neither native API-reconciliation path (active call vs. passive capture) works cleanly from a _test.md today.