RustFS Adversarial Validation
Use the repository risk tiers and review shape. This skill
routes a review to RustFS-specific probes without loading unrelated domains.
Select Lenses
Read only the references required by the diff:
| Lens |
When to read |
| Correctness |
Every non-exempt adversarial review |
| Simplicity |
Mechanical/standard changes and production growth |
| Test coverage |
Behavior or test changes |
| Security |
Authn/authz, IAM, RPC trust, paths, secrets, parsing, browser, encryption |
| Concurrency/durability |
Async shared state, locks, storage commit, cancellation, persisted queues |
| Compatibility |
S3 surface, MinIO interop, metadata, wire/disk formats, mixed versions |
| Performance |
Request/object hot paths, allocation, blocking work, fsync, fan-out |
Do not read all references as a precaution. A path name alone is insufficient;
the changed behavior must touch the lens's domain.
For a dedicated security audit or advisory analysis, use
security-advisory-lessons instead of loading it automatically during every
adversarial review.
Review Protocol
- Freeze the exact final diff/head (or the design under review) and list the
selected lenses.
- Run the review shape required by the repository risk tier.
- For each selected lens, either report a concrete finding or a null verdict
naming the attacks performed.
- Apply root
AGENTS.md's finding standard. Test each candidate against callers,
existing coverage, and invariants before accepting it; an adversarial role
does not have to produce a defect.
- Fix or rebut supported findings with code-path, test, or invariant evidence.
- After a non-trivial edit, rerun only lenses affected by that edit against the
new exact diff.
Do not turn a null verdict into a long checklist. Record concise evidence that
the relevant failure classes were attacked, then stop under the root completion
rule. Keep the required per-lens verdicts for high-risk PRs.
1---2name: adversarial-validation3description: Review RustFS diffs or designs for explicit adversarial requests, high-risk changes under the repository review policy, or substantial PR reviews. Skip ordinary questions, diagnosis, planning, status, routine low-risk implementation, and prose with no execution effect.4---56# RustFS Adversarial Validation78Use the [repository risk tiers and review shape](../../references/adversarial-validation.md). This skill9routes a review to RustFS-specific probes without loading unrelated domains.1011## Select Lenses1213Read only the references required by the diff:1415| Lens | When to read |16|---|---|17| [Correctness](references/correctness.md) | Every non-exempt adversarial review |18| [Simplicity](references/simplicity.md) | Mechanical/standard changes and production growth |19| [Test coverage](references/test-coverage.md) | Behavior or test changes |20| [Security](references/security.md) | Authn/authz, IAM, RPC trust, paths, secrets, parsing, browser, encryption |21| [Concurrency/durability](references/concurrency-durability.md) | Async shared state, locks, storage commit, cancellation, persisted queues |22| [Compatibility](references/compatibility.md) | S3 surface, MinIO interop, metadata, wire/disk formats, mixed versions |23| [Performance](references/performance.md) | Request/object hot paths, allocation, blocking work, fsync, fan-out |2425Do not read all references as a precaution. A path name alone is insufficient;26the changed behavior must touch the lens's domain.2728For a dedicated security audit or advisory analysis, use29`security-advisory-lessons` instead of loading it automatically during every30adversarial review.3132## Review Protocol33341. Freeze the exact final diff/head (or the design under review) and list the35 selected lenses.362. Run the review shape required by the repository risk tier.373. For each selected lens, either report a concrete finding or a null verdict38 naming the attacks performed.394. Apply root `AGENTS.md`'s finding standard. Test each candidate against callers,40 existing coverage, and invariants before accepting it; an adversarial role41 does not have to produce a defect.425. Fix or rebut supported findings with code-path, test, or invariant evidence.436. After a non-trivial edit, rerun only lenses affected by that edit against the44 new exact diff.4546Do not turn a null verdict into a long checklist. Record concise evidence that47the relevant failure classes were attacked, then stop under the root completion48rule. Keep the required per-lens verdicts for high-risk PRs.
rustfs