version: "1.0.0" name: replicate-vector description: Use when confirming that a previously-captured HTTP anomaly or finding still reproduces against its target host (e.g. cascade stage 1), before any minimisation or analysis

Replicate Vector

Confirm a captured HTTP anomaly reproduces against its target, write a self-describing replicate.py, then stop. This is the first step of investigating a finding — not the investigation itself.

Core principle

Your ONLY job is to make the anomalous response happen again and capture how. The moment it reproduces, you are DONE. Replicating is not understanding, minimising, or judging — those are later, separate steps.

How to use

1. Copy the template replicate-vector.py.
2. Set trigger_request to the original captured request, verbatim.
3. Set success_fingerprint to a string that appears in the response ONLY when the anomaly

triggers (see below).

1. Send via the turbo simulator MCP (start_run) against the target host.
2. Fingerprint present → REPLICATED. Stop now. Save the working script to replicate.py

and report the outcome.

1. Fingerprint absent → tweak trigger_request and re-run. Multiple tries are expected.

Tweaking to achieve replication (allowed)

Getting the original request to fire again may take several attempts. All of this is fair game:

• Adjusting transport (scheme/port) when the host is unreachable as captured.
• Fixing a request mangled by capture/encoding.
• Re-sending headers/body exactly as originally seen.

Keep tweaking until it reproduces or you've made a genuine effort and it won't. There is no turn pressure to rush — but there is a hard stop the instant it fires.

STOP the moment it reproduces

Once the fingerprint appears, you are finished. Do not:

• ❌ Minimise or simplify the trigger — that is the simplify-vector skill, a later step.
• ❌ Form or test hypotheses about why it happens — that is root-causing, a later step.
• ❌ Assess security impact or look for variants — later steps.
• ❌ Send "just one more request to understand it better."

Replicating proves that it happens. Nothing here asks why or how minimal. Answering those questions now is scope creep that burns the budget and is the single most common way this step goes wrong.

Choosing a good fingerprint

The fingerprint must be UNIQUE to the anomalous response, or you will get false positives.

• Use a distinctive string from the anomalous response (a reflected token, an unusual status

line, a leaked header, a concatenated second response).

• Avoid strings that also appear in normal responses (domain name, app name, generic errors).

Outcomes

• replicated — fingerprint confirmed and replicate.py saved.
• cant-replicate — genuine effort made, anomaly does not reproduce.

Red flags — you are over-stepping

• "Let me isolate which header causes this." → STOP. That's simplify-vector.
• "The root cause is probably…" → STOP. That's root-causing.
• "Is this exploitable?" → STOP. That's a later assessment.
• "One more request to confirm my theory." → STOP. It already reproduced.

It reproduced? You're done. Write the script and report.