ddadminandClaude Opus 4.7
1237e168c3
- Зачем:
- актуализация под новый Codex CLI (0.132 убрал флаг -a,
ввёл -c approval_policy / -c approvals_reviewer);
- переход на безопасные операторские дефолты
(sandbox=workspace-write для эмпирической верификации,
явные overrides sandbox:* и approvals:*);
- наведение порядка в принятии решений по раунду ревью:
review_quality + evaluation matrix + structural operator gate
вместо «оператор сам разбирается».
- Что:
- SKILL.md: override-граммар (sandbox:*, approvals:*, model:*,
low/medium/high/xhigh), детект OPERATOR_LANGUAGE, runtime hint,
conditional dirty-file warning в Step 2 (после захвата REPO_ROOT),
dual-layer mutation snapshots (git status + sha256sum input-файлов),
operation-aware dispatch table, evaluation matrix + structural
operator gate (batch-pause), structured resume body
(Applied / Re-scoped / Rejected / Specific asks), final operator
summary на OPERATOR_LANGUAGE.
- references/runner.md: переведён на Sonnet runner, добавлен
Step R2.5 bwrap preflight, Step R4.5 review_quality + bounded
triage, расширена 11-полевая JSON-схема результата.
- docs/DESIGN.md: §4.14–§4.21 с обоснованиями новых решений,
§7.8 refresh-era smoke checks, §8 version log с двумя раундами
dogfood-а этого refresh-а (включая R2-корректировку
обоснования residual gap для уже-грязных tracked-файлов).
- README.md: таблица дефолтов, Safety considerations (честно
задокументирован residual gap), Linux sandbox prerequisites
(bwrap + AppArmor user namespaces), Operator language,
Final operator summary, troubleshooting.
- examples/review-output.md: модель в сэмпле обновлена на gpt-5.5.
- docs/superpowers/specs/2026-05-20-...: сохранена спека дизайна
с уточнениями после dogfood.
- Проверка:
- dogfood: 2 раунда /adversarial-review code на этом refresh-е,
R2 верифицировал R2#1 (ordering) и R2#2 (Option B, honest
residual gap);
- smoke: codex --version ≥ 0.132.0, bwrap preflight зелёный
на reference WSL2.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
78 lines
2.7 KiB
Markdown
78 lines
2.7 KiB
Markdown
# 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.5)
|
|
|
|
## 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 without transaction leaves partial state on failure
|
|
|
|
- **File:** src/api/users.py lines 45-52
|
|
- **What can go wrong:** The `delete_user()` function deletes from `sessions`,
|
|
`orders`, and `users` in three separate queries without a transaction.
|
|
If the process crashes or the DB connection drops after deleting sessions
|
|
but before deleting the user, the user record persists with missing session
|
|
history. There is no retry or cleanup mechanism.
|
|
- **Why vulnerable:** The function calls `db.sessions.delete(user_id)`,
|
|
`db.orders.delete(user_id)`, and `db.users.delete(user_id)` sequentially
|
|
without wrapping them in `db.transaction()`.
|
|
- **Impact:** Data loss. Partial deletion leaves the database in an
|
|
inconsistent state that requires manual intervention to fix.
|
|
- **Recommendation:** Wrap all three deletes in a single transaction:
|
|
`with db.transaction(): ...`. If any step fails, the entire operation
|
|
rolls back.
|
|
|
|
### [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)
|
|
|
|
- Wrapped all three deletes (`sessions`, `orders`, `users`) in `db.transaction()`
|
|
- 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.5)
|
|
|
|
## Summary
|
|
|
|
Both issues from round 1 are resolved. The transaction wraps all deletes
|
|
atomically and the authorization check is in place. No new issues found.
|
|
|
|
## Findings
|
|
|
|
No actionable findings.
|
|
|
|
## Verdict
|
|
|
|
VERDICT: APPROVED
|