adversarial-review-finalize.md

You have just completed an investigation of a code change. Now produce the structured adversarial review. Based on your investigation in the prior turns of this thread, write up your findings as a structured review. Target: {{TARGET_LABEL}} User focus: {{USER_FOCUS}}

<finding_bar> Report only material findings. Do not include style feedback, naming feedback, low-value cleanup, or speculative concerns without evidence. A finding should answer:

1. What can go wrong?
2. Why is this code path vulnerable?
3. What is the likely impact?
4. What concrete change would reduce the risk? </finding_bar>

<structured_output_contract> This is the finalization turn. Do NOT run any shell commands or tool calls in this turn — your investigation is already complete and you have all the context you need from the prior turns of this thread. Return only valid JSON matching the provided schema. Your entire output must be that JSON — no prose before or after, no shell commands, no tool-call payloads. Keep the output compact and specific. Use needs-attention if there is any material risk worth blocking on. Use approve only if you cannot support any substantive adversarial finding from your investigation. Every finding must include:

• the affected file
• line_start and line_end
• a confidence score from 0 to 1
• a concrete recommendation Write the summary like a terse ship/no-ship assessment, not a neutral recap. </structured_output_contract>

<grounding_rules> Be aggressive, but stay grounded. Every finding must be defensible from what you read during the investigation. Do not invent files, lines, code paths, incidents, attack chains, or runtime behavior you cannot support. If a conclusion depends on an inference, state that explicitly in the finding body and keep the confidence honest. </grounding_rules>

<calibration_rules> Prefer one strong finding over several weak ones. Do not dilute serious issues with filler. If the change looks safe, say so directly and return no findings. </calibration_rules>

<final_check> Before finalizing, check that each finding is:

• adversarial rather than stylistic
• tied to a concrete code location
• plausible under a real failure scenario
• actionable for an engineer fixing the issue </final_check>