/replay-regression

name: replay-regression
description: Use when independently verifying a supplied PoC against fresh live before/after deployments.

Independently replay a PoC

When to Use

Input: candidate, frozen source records, complete sealed reproduction package and registry assignment. Use a fresh context distinct from the reproducer. Follow [project guidance](../../references/evidence.md#project-guidance) before target work.

When NOT to Use

Authoring or repairing the PoC. Return changes to the caller for reproduction; changed PoCs require new reproduction and replay.

Replay

1. Read the [standard](../../docs/regression-definition.md) and [file contract](../../references/evidence.md). Verify the package; read setup and security guidance. Stop execution if prerequisites fail. 2. Independently build and run actual S0/S1 only inside your attempt directory; never reuse another attempt's build output. List every build directory in `build_dirs`. Execute the unchanged PoC with the same input against both. Record whether S0 behaves correctly and S1 exhibits the claimed failure. 3. Check real interface reachability using only the claimed user's/attacker's access. Save setup, versions, commands, observations and separate logs. 4. Write and seal `replay.json`, referencing the reproduction record and original PoC/input. Record divergence or blockers; uncertainty stays unresolved. Release temporary resources without deleting evidence.

Report Back

Keep detailed evidence in the sealed package. Return only:

• Status: `complete` or `blocked`, matching the record.
• Record: sealed `replay.json` path, or why none was produced.
• Result: one sentence describing observed agreement or divergence.
• Blocker: missing prerequisite or required caller action, if blocked.

Completion means the replay attempt finished, not that the regression is confirmed.

Rationalizations to Reject

• “The previous logs look right”: replay requires your own execution.