Quick answer: A static flag names a line that might break and the reason behind it, and it never executes the code. To turn that suspicion into evidence, pair it with a real request that exercises the same path, send it against the live endpoint, and assert the response and the side effect. The flag tells you where the risk is, and the request tells you whether it actually happens, and neither alone gives a confident answer.
Why one without the other is weak
Static analysis is fast and cheap, and it can read every changed file without a running environment, but its output is a hypothesis. It reasons about the code structure and can raise a false alarm when a guard already handles the case, or miss a defect that depends on real data. A flag on its own carries no runtime evidence.
A real request is the opposite strength. It confirms the behavior the endpoint actually produces, but writing requests for every line blindly is slow, and without the flag you do not know which paths deserve the check. Pairing them uses the static pass to target the request and the request to confirm the flag.
What each contributes
| Evidence | Strength | Limit |
|---|---|---|
| Static flag | Fast, covers every changed file, names the line | A hypothesis, can be wrong, never runs |
| Real request | Confirms live behavior and side effects | Only covers the path it sends |
| Paired result | A targeted suspicion with runtime confirmation | Still bounded to the exercised paths |
The paired row is the goal: a suspicion that is no longer just a model claim because a reproducible request backs it.
How to run the pairing
- Read the flagged line and state the trigger in concrete terms.
- Build a request that reaches the same branch with the data the trigger needs.
- Send it against the live endpoint and assert the status, the body, and the contract.
- Check the side effect, such as a row written or a record removed, not just the response.
- Mark the flag confirmed when the request reproduces it, or dismissed when the guard blocks it.
- Keep a request that fails to exercise the path as inconclusive rather than a pass.
Take a flag that says archived notes can be deleted during a selection change. The request sends a delete action with a selection that excludes archived notes but a visible list that includes them. The response returns 200, which looks fine, but the side effect check shows an archived row was removed, confirming the flag. If the request instead shows the archived row kept, the static flag is dismissed with evidence rather than argued.
Reproducible evidence
Each confirmed item should carry a reproducible request and the raw response as the basis for trust, so the check can be rerun rather than relying on a one-time observation. The evidence is classified by type, with an AI-only claim always staying a hypothesis until a dynamic or contract check backs it.
The verdict stays deterministic with no LLM involved: failing evidence fails, partial verification is partial, and an empty result is not a pass.
Powerduck keeps the static flag and the request workflow connected, so a reviewer can confirm each suspicion with a real call rather than switching between disconnected tools.
Choosing which flags deserve a request
Not every static flag needs a full request, and the pairing routine starts with a quick triage. A flag that changes a behavior or a data path earns a real call, while a flag that is purely structural, such as a naming or a dead import, can be settled from the code and recorded without a request. The risk is under-checking, so when a flag is ambiguous, prefer the request rather than dismissing it statically. A request that confirms a flag is cheap relative to the defect it catches, and one that dismisses a false alarm still leaves evidence. Keep the request-backed findings focused on behavioral risk, and the structural ones in their own pass so the dynamic work stays targeted.
Honest limits
The paired result only covers the paths the request actually sends, and edge cases outside those requests remain open. Dynamic loading and external consumers can keep a branch invisible to the static pass, and the model can still raise false suspicions.
When a request cannot reach the flagged branch, treat the item as inconclusive and adjust the input rather than counting the empty result as verification.
Frequently asked questions
Why not trust the static flag alone? It is a hypothesis that never runs, and a guard can already block the trigger.
Why not send requests without flags? You can, but the static pass targets the risky paths and keeps the request set small and focused.
Does a 200 response confirm the flag? No. Assert the body and the side effect, since a 200 can still break the contract or the data.
The bottom line
Use the static flag to find the risk and the real request to confirm it, asserting the response and the side effect rather than trusting either alone. A flag is a hypothesis until a reproducible request reproduces or dismisses it, and a check that never reaches the branch stays inconclusive. This pairing turns fast static coverage into verified behavior without pretending one can replace the other. Read more in the API scenario testing guide.
Top comments (0)