Files
adversarial-review/examples/review-output.md
T
ddadminandClaude Opus 4.6 b86a1778e6 feat: adversarial prompt rewrite + README + example
- Rewrite all review prompts with XML-structured adversarial stance
  (role, operating_stance, attack_surface, finding_bar, calibration)
- Rename skill from codex-review to adversarial-review
- Add verbatim output rule for reviewer findings
- Improve resume prompt with adversarial re-review focus
- Add README with installation, usage, architecture, roadmap
- Add synthetic example of review output
- Inspired by openai/codex-plugin-cc (Apache-2.0) prompt structure

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-03 18:29:15 +03:00

2.7 KiB

Example: Adversarial Code Review Output

This is a synthetic example showing what a typical adversarial review looks like.


Adversarial Review — Round 1 (mode: code, model: gpt-5.4)

Summary

This change adds a user deletion endpoint to the API. The endpoint accepts a user ID, deletes the user record, and returns 204. The implementation handles the happy path correctly but has two significant issues around data integrity and authorization.

Findings

[severity: critical] User deletion does not cascade to dependent records

  • File: src/api/users.py lines 45-52
  • What can go wrong: Deleting a user leaves orphaned records in orders, sessions, and audit_log tables. Foreign key constraints are set to NO ACTION, so the delete succeeds but dependent data becomes unreferenceable. Queries joining on user_id will silently drop rows.
  • Why vulnerable: The delete_user() function calls db.users.delete(user_id) directly without handling related tables. No cascade is configured at the database level.
  • Impact: Data integrity violation. Orphaned orders cannot be attributed to any user. Financial reconciliation reports will undercount.
  • Recommendation: Either add ON DELETE CASCADE to foreign keys in a migration, or delete dependent records explicitly in a transaction before deleting the user.

[severity: high] Missing authorization check on delete endpoint

  • File: src/api/users.py lines 38-40
  • What can go wrong: Any authenticated user can delete any other user by sending DELETE /api/users/{id}. The endpoint checks authentication (@require_auth) but not authorization — there is no admin role check or ownership validation.
  • Why vulnerable: The route decorator only has @require_auth, not @require_role('admin'). The user_id parameter comes from the URL path and is never compared to the authenticated user's ID.
  • Impact: Privilege escalation. Any logged-in user can delete arbitrary accounts including admins.
  • Recommendation: Add @require_role('admin') decorator, or if self-deletion is intended, verify request.user.id == user_id.

Verdict

VERDICT: REVISE


Fixes (Round 1)

  • Added ON DELETE CASCADE migration for orders.user_id and sessions.user_id
  • Added @require_role('admin') to the delete endpoint
  • Added test for unauthorized deletion attempt (returns 403)

Adversarial Review — Round 2 (mode: code, model: gpt-5.4)

Summary

Both critical issues from round 1 are resolved. The cascade migration is correct and the authorization check is in place. No new issues found.

Findings

No actionable findings.

Verdict

VERDICT: APPROVED