- 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>
2.7 KiB
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, andaudit_logtables. Foreign key constraints are set toNO ACTION, so the delete succeeds but dependent data becomes unreferenceable. Queries joining onuser_idwill silently drop rows. - Why vulnerable: The
delete_user()function callsdb.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 CASCADEto 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'). Theuser_idparameter 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, verifyrequest.user.id == user_id.
Verdict
VERDICT: REVISE
Fixes (Round 1)
- Added
ON DELETE CASCADEmigration fororders.user_idandsessions.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