docs(agents): streamline instruction routing (#6358)

2026-08-22 04:16:38 +00:00 · 2026-08-22 08:19:53 +08:00
parent 61b5edf16e
commit 37c5ce1399
32 changed files with 545 additions and 1254 deletions
@@ -1,277 +1,45 @@
 ---
 name: adversarial-validation
-description: Execute the Adversarial Validation policy from the root AGENTS.md — run the applicable reviewer roles with RustFS-specific attack probes. Use on every behavior-affecting code change, bug fix, design proposal, or agent-instruction change that alters execution before declaring it done.
+description: Review a final RustFS diff adversarially when the user requests adversarial review, the root AGENTS.md classifies the change as high risk, or a substantial PR is being reviewed. Do not use for ordinary questions, diagnosis, planning, status, documentation-only work, or routine low-risk implementation.
 ---
-# Adversarial Validation Playbooks
+# RustFS Adversarial Validation
-The policy — risk tiers, role list, protocol, exit criteria — lives in the
+Use the risk tier and review shape defined in the root `AGENTS.md`. This skill
-root `AGENTS.md` under "Adversarial Validation (Default On)". Read it first;
+routes a review to RustFS-specific probes without loading unrelated domains.
 this skill does not restate it. This file adds the RustFS-specific probe
 playbook for each role: concrete attacks, where they apply, and the real
 shipped bug or rule that earns each probe its place.
-## How to run a role
+## Select Lenses
-1. Pick the tier and the applicable roles per the root `AGENTS.md`.
+Read only the references required by the diff:
 2. Run each role as an independent pass over the final diff — a parallel
   reviewer agent where the tooling supports it, otherwise a fresh
   sequential pass that starts from the diff and the nearest scoped
   `AGENTS.md`, discarding the writing session's assumptions.
 3. Within a role, execute the probes whose domain the diff touches, plus any
   attack the diff obviously invites that no probe lists — the playbook is a
   floor, not a ceiling.
 4. Report findings (concrete failure scenario or named missing test, with
   file:line) or the role's null report: "attacked X, Y, Z — no break
   found". A bare pass is not a result.
-## Role playbooks
+| Lens | When to read |
 |---|---|
 | [Correctness](references/correctness.md) | Every non-exempt adversarial review |
 | [Simplicity](references/simplicity.md) | Mechanical/standard changes and production growth |
 | [Test coverage](references/test-coverage.md) | Behavior or test changes |
 | [Security](references/security.md) | Authn/authz, IAM, RPC trust, paths, secrets, parsing, browser, encryption |
 | [Concurrency/durability](references/concurrency-durability.md) | Async shared state, locks, storage commit, cancellation, persisted queues |
 | [Compatibility](references/compatibility.md) | S3 surface, MinIO interop, metadata, wire/disk formats, mixed versions |
 | [Performance](references/performance.md) | Request/object hot paths, allocation, blocking work, fsync, fan-out |
-### Correctness adversary
+Do not read all references as a precaution. A path name alone is insufficient;
 the changed behavior must touch the lens's domain.
- For any change touching error aggregation or quorum decisions, build the exact disk-error slice at the quorum boundary: N disks where successes == quorum, then flip one success to an error (quorum-1) and separately inject None/nil placeholder entries into the slice. Trace whether reduce_errs (or the new equivalent) picks the placeholder as the dominant error or lets quorum-1 pass as success. Also check heal/write paths: does a per-target failure at quorum-1 return an explicit error, or silently degrade to success?
+For a dedicated security audit or advisory analysis, use
-  - Where: crates/ecstore/src/disk/error_reduce.rs; crates/ecstore/src/set_disk/{core,ops}; crates/heal
+`security-advisory-lessons` instead of loading it automatically during every
-  - Evidence: Commit 20d61c73b 'stop reduce_errs leaking nil placeholder as dominant error' (#4551) and 47c1e730c 'make erasure heal write quorum best-effort per target' (#4545); crates/ecstore/AGENTS.md: 'Do not weaken quorum checks... Prefer explicit failure over silent data corruption or implicit success.'
+adversarial review.
 - For any change in EC read/reconstruct/streaming code, trace the mid-stream error path: the first K shards read fine, then a shard turns out bitrot-corrupt or inconsistent after N bytes have already been sent to the client. Verify the error propagates as a stream error (client sees failure), not a clean end-of-body — a silently truncated GET body is data corruption. Also re-check byte accounting: sum of per-part bytes vs object size, and partNumber-to-offset routing for the first and last part.
  - Where: crates/ecstore/src/set_disk/read.rs (reconstruct-read, inconsistent_source_indexes handling ~line 3827); codec streaming paths in crates/ecstore/src/erasure_coding
  - Evidence: Known live bug: EC reconstruct-read failing on inconsistent shards mid-stream silently truncates GET body → client 'unexpected EOF'; commit 15808254d 'correct codec-streaming byte accounting and partNumber routing' (#4535).
 - For any listing/pagination change, construct the exact-boundary inputs: (a) exactly max_keys/max_uploads matching entries — assert the response contains max and is_truncated=false, then max+1 entries — assert exactly max returned with is_truncated=true and a correct continuation marker; (b) a delimiter listing where folding into CommonPrefixes re-fills a full page; (c) an object 'a' coexisting with prefix dir 'a/'. Off-by-one and dropped-truncation bugs live exactly at these boundaries.
  - Where: crates/ecstore listing/merge paths (metacache, list_objects, list_multipart_uploads); rustfs/src/storage
  - Evidence: Three recent real bugs: fefa70b31 'stop ListMultipartUploads from returning one upload past max-uploads' (#4447), d91f4d455 'report truncation when delimiter list re-folds a full page' (#4538), 7e1f7f242 'preserve CommonPrefixes when an object and same-named prefix dir coexist' (#4563).
 - Run the diff's logic with a directory object key (trailing slash, e.g. 'pre/dir/') as input. Check which layer encodes/decodes __XLDIR__ — set_disk never sees the trailing slash, so any trailing-slash branch added below the store layer is dead code and a wrong-layer bug. For delete paths, check whether options force a nil versionId onto directory keys: the resulting miss surfaces as version-not-found, not object-not-found, so callers matching only ObjectNotFound leak ghost directory entries.
  - Where: crates/ecstore/src/store*.rs (store layer) vs crates/ecstore/src/set_disk/*; delete option construction (del_opts) and its callers
  - Evidence: trailing-slash branches must live at store layer; del_opts injects nil version for dir keys, PR#4220 ghost-directory cleanup never fired on the real path (rustfs#4307, backlog#798 still OPEN).
 - Feed every new binary-UUID metadata read the three degenerate values: key absent, zero-length bytes, and 16 zero bytes (nil UUID). All three must mean 'no value' — any path that produces Uuid::nil() and then acts on it (e.g. sends it as a versionId) is a finding. For tier code specifically: with remote-tier version None or "", assert the tier GET/DELETE request carries no versionId parameter at all — sending versionId="" or nil yields NoSuchVersion against unversioned tier buckets.
  - Where: crates/filemeta/src/filemeta/version.rs; crates/ecstore/src/bucket/lifecycle/; crates/ecstore/src/services/tier/; any new consumer of crates/utils/src/http/metadata_compat.rs
  - Evidence: AGENTS.md Cross-Cutting Domain Invariants (defensive Uuid read pattern + unversioned-tier rule); docs/operations/tier-ilm-debugging.md ('nil transition_ver_id = corrupt legacy write-back, readers must filter'); commit 726f3dc18 'accept empty remote version_id in tier recovery paths' (#4552).
 - For each match/if-let on an error or algorithm enum touched by the diff, enumerate what the wildcard/else arm swallows. Inject the variants the author didn't think of — DiskNotFound during listing, an unsupported checksum algorithm, an Err from a cleanup rename/delete — and trace whether they degrade into 'not found', a wrong-but-plausible value, or silent success. Any error path that converges with the success path without logging and propagating is a finding.
  - Where: crates/ecstore (listing, delete/rename cleanup); crates/checksums; error-mapping layers in rustfs/src/storage
  - Evidence: Three recent real bugs of this exact shape: e0619e355 'stop treating DiskNotFound as object not-found in listing' (#4536), afaf8c681 'reject md5 instead of silently returning crc32' (#4513), f7d2b2563 'propagate disk delete/rename failures instead of swallowing them' (#4546).
 - For any change to version ordering, index lookup, or shard/part indexing: (a) call the accessor with index == len() and len()-1 — a get_idx-style bound must reject, not panic or wrap; (b) construct two versions with identical mod-times and check the sort tie-break is total and deterministic (equal keys must not compare as both before each other); (c) for EC shard math, compute shard size for object sizes 0, 1, blockSize-1, blockSize, blockSize+1 and cross-check total reconstructed length against the object size.
  - Where: crates/filemeta/src/filemeta/*.rs (version sort, get_idx); crates/ecstore/src/erasure_coding shard-size math
  - Evidence: Commit 8bfb00bc0 'guard get_idx bound and fix sorts_before tie-break' (#4509) — both bug classes shipped before; ecstore AGENTS.md high-risk designation for read/write/repair correctness.
 - Exercise the zero/empty end of every new size or count parameter: zero-length object PUT then GET (body must be empty, not error), part count 0, empty Vec of disks/entries into aggregation functions, and env/config values of 0 (must clamp or reject, never divide-by-zero or 'scan nothing and report zero usage'). Anywhere the diff computes a ratio, capacity, or progress percentage, plug in 0 and the max value.
  - Where: crates/ecstore aggregation and scanner paths; crates/object-capacity; config/env parsing in touched crates
  - Evidence: Commits 787cc77a7 'clamp zero capacity env values to safe defaults' (#4559) and 32b1094ec 'resolve a symlinked scan root instead of silently counting zero' (#4564) — zero-as-silent-wrong-answer is a recurring repo bug class.
 - For any diff touching multipart or object commit paths, order the operations on paper and attack the failure point between them: kill the process (or return Err) after the commit rename but before cleanup, and after cleanup but before commit. Verify the earlier-failure case leaves the object readable and the later-failure case leaves no half-visible object; part meta files must never be deleted before the commit is durable.
  - Where: crates/ecstore multipart commit/cleanup (set_disk/ops); rustfs/src/storage multipart handlers
  - Evidence: Commit c77c5f047 'defer multipart part.N.meta cleanup until after commit' (#4548) — cleanup-before-commit ordering already caused a real data-loss window; the #4221 durability work shows fsync/ordering bugs are endemic here.
-Null report example: "Attacked quorum-1 error reduction, exact max-keys listing boundary, trailing-slash dir keys, nil-UUID tier versionId, and mid-stream reconstruct error propagation — no break found."
+## Review Protocol
-### Simplicity adversary
+1. Freeze the exact final diff/head and list the selected lenses.
 2. Run the review shape required by root `AGENTS.md`.
 3. For each selected lens, either report a concrete finding or a null verdict
   naming the attacks performed.
 4. A finding needs `file:line`, a triggering input/state/interleaving, the wrong
   outcome, and a focused fix or missing regression check.
 5. Fix or rebut every finding with code-path, test, or invariant evidence.
 6. After a non-trivial edit, rerun only lenses affected by that edit against the
   new exact diff.
- Smaller-diff attack: inspect production growth separately from tests, fixtures, generated code, and documentation; test additions have no growth budget. Rewrite the production diff mentally (or in scratch) as the minimal equivalent edit. Report a finding only with a concrete smaller design that preserves correctness, compatibility, readability, and real boundaries; fewer lines alone are not evidence.
+Do not turn a null verdict into a long checklist. Record concise evidence that
-  - Where: Any diff; extra scrutiny for crates/ecstore, crates/lock, rustfs/src/storage where 'preserve the existing control-flow shape' is an explicit rule
+the relevant failure classes were attacked.
  - Evidence: AGENTS.md 'Change Style for Existing Logic' (conditional extraction rule, preserve sensitive control flow, canonical modules) and 'Reuse Before You Write'; the Adversarial Validation roles list charters this attack.
 - Reuse-and-necessity attack: for each new helper, search `crates/utils`, `crates/common`, the touched crate, the likely domain owner, and relevant direct dependencies. A reimplementation is a finding, but forced reuse with mismatched normalization, error, backoff, or durability semantics is also a finding. Demand a nameable trigger for new defensive branches. Tests remain subject to validity and near-duplicate coverage review, never a size limit.
  - Where: Any diff adding helpers, branches on decoded/peer data, or tests
  - Evidence: AGENTS.md 'Reuse Before You Write' and 'Necessary Code Only'; GHSA-f4vq-9ffr-m8m3 (normalization-asymmetry traversal — why forced reuse of normalizing helpers on raw keys is itself an attack); docs/operations/tier-ilm-debugging.md nil-versionId incident (why boundary re-checks are load-bearing).
 - Replacement-and-comment attack: when the diff introduces a replacement path or representation, trace all callers and flag a superseded in-scope path left behind without a compatibility requirement. Keep one canonical core behind compatibility adapters. Comments must state non-obvious invariants completely without narration or change history. Never demand unrelated deletion or trade away correctness, compatibility, or readability to reduce the diff.
 Null report example: "Separated production growth from tests/docs, tested a smaller equivalent, checked helper reuse and superseded paths, and found no break."
 ### Security reviewer
 - For every admin handler in the diff, grep the exact AdminAction constant it passes to validate_admin_request and confirm it names the operation the handler actually performs. Construct the escalation: a low-privileged user whose policy grants the wrong-but-adjacent action (e.g. Export while the handler Imports, or Update while it Lists) — if the mismatched constant lets them through, that is the bug. Also confirm read-only endpoints (metrics, list, server-info, diagnostics) still call an operation-specific admin authz path and not a mere 'credentials exist' check.
  - Where: rustfs/src/admin/handlers/**, rustfs/src/admin/router registration; check_permissions / validate_admin_request / AdminAction::* call sites
  - Evidence: GHSA-vcwh-pff9-64cc (ImportIam checked ExportIAMAction), GHSA-mm2q-qcmx-gw4w (ListServiceAccount used UpdateServiceAccountAdminAction), GHSA-f5cv-v44x-2xgf (/admin/v3/metrics accepted any authenticated IAM user). advisory-patterns.md 'Admin authorization and route exposure'; rustfs/src/admin/AGENTS.md 'route registration, whitelist, handler authz must agree'.
 - If the diff touches service-account or IAM import/update, treat parent, claims, accessKey, secretKey, status, policy names, and groups as attacker-controlled. Construct an ImportIam/create payload where parent points at root (or another user) and prove the code writes credentials without proving caller ownership or root authority. Separately, set deny_only=true (or 'no explicit deny') on a restricted account and check it does not skip the required allow check, letting it mint an unrestricted child.
  - Where: crates/iam/, rustfs/src/admin/handlers (service account / import IAM), rustfs/src/auth.rs
  - Evidence: GHSA-566f-q62r-wcr8 (attacker-controlled parent/claims/accessKey/secretKey → persistent backdoor under root), GHSA-xgr5-qc6w-vcg9 (deny_only=true skipped allow checks → privilege creation). crates/iam/AGENTS.md security boundaries; advisory-patterns.md 'IAM import, service accounts'.
 - For a changed protocol-frontend handler (FTP/FTPS/SFTP/WebDAV/gateway), enumerate ALL sibling command handlers in the same driver — not just the changed one. For each, confirm it calls the per-operation IAM authorize hook mapped to the correct S3 action (RETR→GetObject, SIZE/MDTM→HeadObject, MKD→CreateBucket, bucket probe→ListBucket/HeadBucket) BEFORE touching storage. Construct a denied-authz case and prove the storage backend is never reached.
  - Where: crates/protocols/ (FtpsDriver, SftpDriver, WebDAV), authorize_operation call sites
  - Evidence: GHSA-3g29-xff2-92vp (FTP RETR/SIZE/MDTM authenticated but skipped IAM), GHSA-g3vq-vv42-f647 (FTPS MKD called create_bucket without s3:CreateBucket). advisory-patterns.md: 'RustFS advisories show mixed guarded and unguarded siblings in the same driver.'
 - For any secret/token/signature/password comparison in the diff, check it uses a constant-time compare (e.g. subtle/constant_time_eq), not == or early-return byte loops. Then check the failure-response paths: construct an invalid-user request and an invalid-secret request and confirm they are indistinguishable (same error, no early length short-circuit) so an attacker cannot enumerate valid users or time-side-channel the secret.
  - Where: crates/protocols/ (FTPS/WebDAV/FormPost auth), crates/credentials/, rustfs/src/auth.rs, RPC signature verification
  - Evidence: GHSA-3p3x-734c-h5vx (FTPS/WebDAV early-return string equality + distinguishable invalid-user vs invalid-password). Fix commits 3c3113619 (constant-time FTPS/WebDAV) and c41062f27 (constant-time FormPost signature). 3p3x was fixed by PR #4403.
 - If the diff parses or transports secret-bearing config (env vars, key files, connection strings), grep every error-construction and format site on that value's path (`format!` feeding `Error::other`/`configuration_error`/`panic!`/`expect`) for interpolation of the raw value or of variables named like secret material. Construct the likeliest misconfiguration: the operator supplies the bare secret without the expected `<name>:` prefix (or with a stray newline) — if the parse-failure hint echoes the input, the secret lands in startup logs. Error strings are log content; the hint may name the env var and expected format, never the value. If the diff re-implements an existing parse helper, diff the two error paths — the duplicate is where the leak hides.
  - Where: rustfs/src/init.rs (env plumbing), crates/kms/src/config.rs, crates/credentials/, any from_env/parse on secret values; mechanical backstop in scripts/check_logging_guardrails.sh (secret-interpolation check)
  - Evidence: PR #5222 introduced `got: {secret_str}` in build_static_kms_config's format-hint error — a bare base64 key (the secret itself) would have been echoed into startup logs; fixed by PR #5243. The parallel parse in KmsConfig::from_env already omitted the value: the leak lived only in the duplicated copy (AGENTS.md 'Reuse Before You Write').
 - If the diff touches internode/RPC auth secret handling, trace whether the RPC HMAC secret can fall back to a public default (e.g. 'rustfsadmin', 'rustfs rpc') or be derived deterministically from the S3 root credentials. Construct the case where RUSTFS_RPC_SECRET is unset and confirm the code fails closed rather than silently using a default or a root-derived key. Verify RPC signing keys are independent random secrets, not reused across S3-root/RPC-HMAC/STS-JWT roles.
  - Where: crates/credentials/, crates/ecstore/src/rpc/, internode auth setup
  - Evidence: GHSA-r5qv-rc46-hv8q (fell back to 'rustfsadmin'), GHSA-75fx/68cw (RPC secret derivable from root creds → forgeable signatures), GHSA-h956 (hard-coded 'rustfs rpc'), GHSA-m77q (STS JWT reused root secret). Fix commit 7b2055405 (fail closed when deriving RPC secret from default credentials, PR#4402).
 - If the diff touches RPC/NodeService authentication, verify the HMAC payload binds the EXACT concrete gRPC method path (not a service prefix), the HTTP method surrogate, and a fresh timestamp. Construct captured valid metadata for method A and replay it to method B within the timestamp window — if it authorizes, the signature is under-bound. Also test stale timestamp, wrong path, wrong method, wrong secret.
  - Where: crates/ecstore/src/rpc/, verify_rpc_signature / NodeServiceServer, x-rustfs-signature handling
  - Evidence: GHSA-c667-rgrv-99vj (signed service prefix instead of concrete method path → cross-method replay in timestamp window). advisory-patterns.md 'RPC input validation and panic safety'; Minimum Regression Test Expectations lists replay across two methods.
 - For any RPC/gRPC handler or deserialization touched, feed empty bytes, truncated MessagePack/protobuf, invalid enum discriminants, and stale timestamps. Grep the deserialization path for unwrap()/expect()/panic-prone decode and prove malformed attacker payloads return a typed error, not a panic (remote DoS). Weak internode auth makes reachability worse, so combine with the RPC-secret probe.
  - Where: crates/ecstore/src/rpc/, any #[derive(Deserialize)] decoded from wire bytes, RPC handler bodies
  - Evidence: GHSA-gw2x-q739-qhcr (malformed GetMetrics reached unwrap() → remote DoS). advisory-patterns.md 'Treat all RPC payload bytes as attacker-controlled.' rust-code-quality skill: unwrap abuse.
 - Take any object key, RPC disk path, or archive/tar/zip entry name introduced or handled in the diff and construct traversal payloads: '../', URL-encoded '%2e%2e%2f', absolute paths, platform separators, empty components. Trace the value through parse → authz check → final storage path and prove (a) authz and storage normalize the SAME way, and (b) the canonicalized path cannot escape the bucket/prefix root. Attack the case where authz sees the raw attacker bucket but storage cleaning crosses into a victim bucket.
  - Where: crates/ecstore (path join/canonicalize), rustfs/src/storage/, Snowball auto-extract / normalize_extract_entry_key, rpc read_file_stream
  - Evidence: GHSA-pq29-69jg-9mxc (read_file_stream joined untrusted paths, no canonical boundary check), GHSA-8r6f-hmq2-28rg (traversal object keys bypassed authz), GHSA-f4vq-9ffr-m8m3 (Snowball '../victim-bucket/object' authorized raw path then storage crossed boundary). Note __XLDIR__ trailing-slash encoding is store-layer only.
 - If the diff touches multipart/copy or presigned POST, verify UploadPartCopy enforces source GetObject AND destination PutObject semantics equivalent to CopyObject, including copy-source policy conditions (not just independent source-read + dest-write). Construct a cross-bucket UploadPartCopy from a bucket the caller cannot read. For presigned POST, submit an upload that violates content-length-range, key prefix, or exact content-type and prove the server rejects it.
  - Where: rustfs/src/storage / S3 API handlers: upload_part_copy, CompleteMultipartUpload, PostObject policy enforcement
  - Evidence: GHSA-mx42-j6wv-px98 (UploadPartCopy missed source authz → cross-bucket exfil), GHSA-wfxj-ph3v-7mjf (missed destination copy-source policy constraint), GHSA-w5fh-f8xh-5x3p (presigned POST didn't enforce signed policy conditions). advisory-patterns.md 'S3 copy, multipart, and upload policy validation'.
 - Grep the diff for debug!/trace!/info!/error! and any ?value / {:?} on structs or response bodies that can carry secret_key, session_token, JWT claims, HMAC secrets, expected signatures, access keys beyond safe identifiers, or raw credential-bearing responses. Check custom Debug impls and merged-config dumps too. Construct the error path (invalid signature, failed auth) and confirm it does not log the secret or the derived authenticator. Verify audit/notify entries redact credential request headers.
  - Where: rustfs/src/**, crates/iam/, crates/audit/, crates/notify/, crates/targets/, RPC signature error paths
  - Evidence: GHSA-r54g (STS creds logged at info), GHSA-8cm2 (debug logs leaked tokens/secrets/JWT claims/raw STS bodies), GHSA-333v (invalid RPC signature log included HMAC secret + expected signature). Fix commit ee6f79110 (redact credential request headers from audit/notify, backlog#963). rustfs-logging-governance skill.
 - For any struct in the diff deserialized from untrusted input (S3 XML/JSON, lifecycle rules, bucket policy, replication config, RPC payload), check for #[serde(deny_unknown_fields)]. Construct a payload with a typo'd field (e.g. 'NoncurentDays') or an extra field and prove it is rejected, not silently ignored. Flag #[serde(default)] on security-critical fields (retention days, limits, permissions) lacking explicit post-deserialize validation, and any user-controlled integer cast with `as` (i32 as u32) — feed a negative value and check it doesn't wrap to a huge positive.
  - Where: crates/policy/ (bucket policy), crates/ecstore lifecycle/ILM config, replication config structs, crates/protocols XML parsing
  - Evidence: AGENTS.md 'Serde Safety'; advisory-patterns.md 'Serde deserialization' (no deny_unknown_fields found repo-wide; 'NoncurentDays' typo silently accepted; i32 as u32 wrap). Fix commit 1acd47f15 (SSE crash-loop DoS + credential reserved-char bypass, backlog#806).
 - If the diff touches SSE / encryption reader-writer composition, do not trust API metadata claiming encryption. Trace the reader wrapper order (HashReader / EncryptReader / compression / warp) and confirm EncryptReader is actually in the chain that writes to disk — construct the case where a helper unwraps a nested reader and bypasses encryption, storing plaintext. Require a regression test that inspects the ACTUAL stored bytes on disk, not just read-back. Also check encrypted-object checksums are not exposed.
  - Where: rustfs/src/storage/ecfs.rs, crates/rio/ (reader wrappers), crates/kms/, SSE-C replication
  - Evidence: GHSA-xrrf-67jm-3c2r (SSE metadata reported encryption while composition bypassed EncryptReader, stored plaintext). Fix commits a7b9659e7 (hide encrypted object checksums, #4529), 80cc3b1fc (preserve SSE-C checksum state, #4410). advisory-patterns.md 'SSE and on-disk storage invariants'.
 - If the diff touches CORS or the console/browser/object-preview surface: confirm default CORS does not reflect an arbitrary Origin while also sending Access-Control-Allow-Credentials: true — construct a request with a spoofed Origin and check the response. For preview, confirm attacker-controlled object content is origin-isolated (not rendered in a same-origin iframe with console creds), served with nosniff/CSP, and that preview trust derives from validated content-type + sandboxing, NOT from object name/extension (.pdf, .html). Separately, if aws:SourceIp is evaluated, spoof X-Forwarded-For / X-Real-IP as a direct (non-trusted-proxy) client and confirm the socket peer IP is used instead.
  - Where: rustfs/src/server/layer.rs (CORS), console preview/auth code, aws:SourceIp / policy condition evaluation, X-Forwarded-For handling
  - Evidence: GHSA-x5xv-223c-8vm7 (default CORS reflected arbitrary origins with credentials), GHSA-v9fg-3cr2-277j (preview rendered attacker HTML same-origin, exposed localStorage creds), GHSA-7gcx-wg4x-q9x6 (extension-based PDF detection bypassed sandbox), GHSA-fc6g-2gcp-2qrq (aws:SourceIp trusted client XFF). advisory-patterns.md 'Browser, CORS' + 'Trusted proxy'.
 Null report example: "Attacked admin action-constant matching in the two changed handlers (both call validate_admin_request with the exact AdminAction), the FTPS RETR/SIZE authz parity, and the new lifecycle struct's serde surface (has deny_unknown_fields) — no break found."
 ### Concurrency/durability reviewer
 - For every new or moved lock acquisition, enumerate all other code paths that take any overlapping subset of those locks and construct the concrete ABBA interleaving (thread 1 holds A wants B, thread 2 holds B wants A). If the diff acquires 2+ locks without a comment documenting acquisition order, that alone is a finding.
  - Where: crates/ecstore/** (namespace locks, set_disk, disk registry), crates/audit/**, crates/lock/**, any Mutex/RwLock pair in a diff
  - Evidence: crates/ecstore/AGENTS.md 'Lock Ordering' (document order; same set in different orders = deadlock); real ABBA deadlock fixed in c0d5f938f (#4421, audit registry vs stream_cancellers)
 - If the diff touches the object write/commit path or a lock guard's lifetime, construct the timeline where the distributed lock is lost (heartbeat refresh fails / expiry) after shard writes but before the xl.meta rename commit — verify the commit is fenced on guard.is_lock_lost() (set_disk/ops/object.rs:874-880) and the diff does not move the commit outside the fenced region or drop the guard early.
  - Where: crates/ecstore/src/set_disk/ops/object.rs, ops/multipart.rs, crates/lock/**
  - Evidence: 1e6207c08 (#4406) fence write commit on lock loss; ddf197ba5 (#4388) heartbeat lock refresh; backlog#899 fencing comment in object.rs
 - For any change to file creation or write-then-rename: write out the exact syscall order (write tmp -> fdatasync tmp -> rename -> fsync parent dir -> fsync ancestor dirs on first object under a prefix) and simulate a power cut after each step. Flag any dropped/reordered sync, and check the change honors the durability gate (RUSTFS_DRIVE_SYNC_ENABLE, strict/relaxed/none modes, per-bucket overrides) instead of hardcoding one mode. The 'skip tmp parent fsync' optimization is only sound when the file is renamed out of tmp — verify that precondition still holds.
  - Where: crates/ecstore/src/disk/local.rs, disk/os.rs, disk/fs.rs, crates/ecstore/src/bucket/durability.rs, set_disk/core/io_primitives.rs
  - Evidence: PR #4221 (the repo previously had no fsync anywhere); 2df315baf/c081586e7 (#4493) fsync ancestor dirs; 062a68d15 (#4387) tmp-parent-fsync skip is rename-conditional; eaff17cad (#4397) durability modes; 54872d52d (#4478) rename_data crash harness exists — extend it for the diff
 - If the diff touches quorum counting or per-disk error aggregation, construct adversarial error vectors for reduce_errs: nil/placeholder entries, DiskNotFound mixed with FileNotFound, exactly quorum-1 agreeing errors — and show which dominant error wins. Specifically attack the case where offline-disk errors get counted as 'object does not exist', flipping a read/heal decision into data loss. Also check quorum monotonicity: a retry or heal pass must never conclude with a LOWER quorum than the original write.
  - Where: crates/ecstore/src/disk/error_reduce.rs, crates/ecstore/src/api/mod.rs, set_disk read/heal paths
  - Evidence: 20d61c73b (#4551) reduce_errs leaked nil placeholder as dominant error; e0619e355 (#4536) DiskNotFound treated as object-not-found in listing; quorum monotonicity flagged as open follow-up to #4221 (#4221 follow-up list); crates/ecstore/AGENTS.md 'Do not weaken quorum checks'
 - For any multi-disk fan-out (delete, rename, heal write, cleanup), trace each per-disk Result: find any `let _ =`, `.ok()`, or best-effort collapse that keeps a failed disk out of the quorum math. Construct the run where exactly write_quorum-1 disks succeed and prove the op still returns success — that is the bug. Conversely, for heal writes, check one bad target cannot fail the whole heal (best-effort per target).
  - Where: crates/ecstore/src/set_disk/ops/*.rs, disk/disk_store.rs, crates/heal/**
  - Evidence: f7d2b2563 (#4546) disk delete/rename failures were swallowed; 47c1e730c (#4545) heal write quorum made best-effort per target; 2b063b0c4 (#4400) disk-replacement heal missed versions
 - For every new .await placed between a state mutation and its cleanup/commit (or inside select!/timeout/spawned task that can be aborted), construct the cancellation point: client disconnects and the future is dropped exactly there. Enumerate what is left behind — tmp files, incremented counters never decremented, half-written xl.meta, a held permit/waiter — and verify cleanup runs in Drop or the state is re-entrant. Background loops the diff adds must have a hard outer timeout so a wedged awaitee cannot pin them forever.
  - Where: crates/ecstore/** write paths, crates/object-capacity/** scanners, crates/audit/**, anything using tokio::select! or spawn+abort
  - Evidence: d608e320f io_uring cancel-safety spike (cancellation known-hard here); 5a372557e (#4533) wedged scans needed hard outer timeout; 7b87d4d13 (#4520) waiter-count leak; e44bece00 (#4497) audit start race + paused drops
 - If the diff touches metacache/list producers or cursor resume, construct the interleaving where the producer task completes (or errors) while a reader with a saved cursor comes back for the next page — verify a completed producer is tolerated (no error, no hang) and that a re-folded/full page reports truncation instead of silently ending the listing early. Also feed a corrupt/oversized length prefix into any metacache decode the diff touches.
  - Where: crates/ecstore/src/cache_value/metacache_set.rs, crates/ecstore/src/store/list_objects.rs, crates/filemeta/**
  - Evidence: 91a23361e (#4531) tolerate completed metacache producers; d91f4d455 (#4538) delimiter re-fold dropped truncation flag; d2c100fd3 (#4226) corrupt length-prefix guard
 - For multipart changes, construct concurrent operations on the SAME uploadId: put_object_part racing put_object_part (same part number), abort racing complete between the parts listing and the commit rename, and list-parts racing cleanup. Verify every metadata read/list/abort holds the per-uploadId lock, and that part.N.meta cleanup is deferred until AFTER the commit rename — cleanup before commit loses parts on a crash between the two.
  - Where: crates/ecstore/src/set_disk/ops/multipart.rs, rustfs/src/storage/
  - Evidence: 3bc8d79fe (#4329) serialize put_object_part per uploadId; 7fb95d4fc (#4428) unlocked upload metadata reads/aborts; 93ffbdb9b (#4437) unlocked part listings; c77c5f047 (#4548) part.N.meta cleanup moved after commit
 - Any cleanup/rollback logic added near a commit: verify it runs strictly AFTER the commit is durable, is best-effort (its failure must not fail an already-committed write), and is safe under retry — i.e., re-running it after a partial first attempt must never delete the newly-committed data dir or the last surviving copy.
  - Where: crates/ecstore/src/set_disk/ops/object.rs (rename_data tail), ops/multipart.rs, disk cleanup helpers
  - Evidence: afc7f1d6f/d908243e6 (#4386, backlog#898) post-commit old-data-dir cleanup had to be made best-effort; e7cc719c1 (#4389) speculative tmp cleanup moved off hot path
 - If the diff does read-modify-write on any persisted shared state (bucket metadata, notify/target config, queue store), construct two concurrent writers: show whether the second write silently discards the first (lost update) — RMW must be serialized or CAS-guarded. For persisted queues/replay, construct crash-mid-replay and prove entries are neither lost nor delivered twice without an idempotency key.
  - Where: crates/notify/**, crates/targets/** (queue store, SQL backends), crates/ecstore/src/bucket/metadata_sys.rs
  - Evidence: 2490d4ee2 (#4425) persisted config RMW lost updates; 08e44b95f (#4505) queue store crash-safety + replay lifecycle; e008cc5da (#4500) SQL backend idempotency
 - If the diff touches erasure decode/reconstruct or streaming GET, construct the failure mid-stream: shards become inconsistent (or a disk read fails) after N bytes of the body have already been sent — verify the stream surfaces an error to the client instead of ending cleanly at a truncated length. Silent truncation on a 200 response is the known failure mode.
  - Where: crates/ecstore/src/set_disk/read.rs (reconstruct-read validation, historically ~line 3117), crates/ecstore/src/erasure/coding/decode.rs
  - Evidence: Known open bug: EC reconstruct-read 'inconsistent shards' mid-GET silently truncates body -> client unexpected EOF; crates/ecstore/AGENTS.md 'explicit failure over silent corruption'
 Null report example: "Attacked lock ordering on the new disk-registry mutex pair, lock-loss fencing across the moved commit, power-cut points around the added rename, and cancellation at the two new awaits — no break found; quorum math and metacache paths untouched by this diff."
 ### Compatibility reviewer
 - Grep the diff for raw 'x-rustfs-internal-' or 'x-minio-internal-' string literals used with map.insert/remove/get instead of the metadata_compat helpers. If found, construct the MinIO-written object case: a metadata map containing ONLY 'X-Minio-Internal-<suffix>' (mixed case, no RustFS key) and trace the diff's read path — does it miss the value? Then construct the removal case: does remove leave the twin key behind so a stale MinIO-key value resurrects on next read? Also check the value-type trap: get_bytes has NO case-insensitive fallback (unlike get_str), so a diff that moves a suffix from FileInfo.metadata (String) to meta_sys (Vec<u8>) silently loses mixed-case MinIO keys.
  - Where: Any code touching FileInfo.metadata / user_defined / meta_sys: crates/ecstore/, crates/filemeta/, rustfs/src/storage/, crates/utils/src/http/metadata_compat.rs
  - Evidence: Repo-wide invariant in AGENTS.md 'Cross-Cutting Domain Invariants' and CLAUDE.md; helpers and the asymmetry are pinned by tests test_str_lookup_accepts_minio_metadata_case and test_get_bytes_no_case_insensitive_fallback in crates/utils/src/http/metadata_compat.rs
 - For any diff reading a binary UUID from internal metadata (transitioned-versionID, tier-free-versionID, data_dir), trace the three degenerate inputs — key absent, value empty (b""), value nil UUID — through to the outgoing tier/S3 request. The bug shape to hunt: unwrap_or_default() or Uuid::from_slice(..).unwrap_or(Uuid::nil()) turning 'no value' into Uuid::nil(), which then gets serialized as ?versionId=00000000-... and the remote tier returns NoSuchVersion. The required pattern is .and_then(|v| Uuid::from_slice(&v).ok()).filter(|u| !u.is_nil()).
  - Where: crates/ecstore/src/bucket/lifecycle/ (bucket_lifecycle_ops.rs, tier_sweeper.rs), crates/ecstore/src/services/tier/warm_backend_*.rs, crates/filemeta/src/filemeta/version.rs
  - Evidence: Historical production bug documented in docs/operations/tier-ilm-debugging.md ('Nil-UUID versionId sent to tier'); regression tests live in crates/filemeta/src/filemeta/version.rs; follow-up fix 726f3dc18 'accept empty remote version_id in tier recovery paths' (#4552)
 - For any diff touching tier or replication GET/DELETE against a remote S3 target, enumerate BOTH directions of the versionId contract and trace each: (a) remote version None/"" means the tier bucket is unversioned — the request must carry NO versionId parameter at all (not an empty one, not nil); (b) remote version Some(v) on a versioned target — the versionId MUST be sent, especially on version-purge deletes, or the delete lands on the wrong version / creates a delete marker instead of purging. Check whether the diff collapses these cases through a single Option/String conversion that loses the distinction.
  - Where: crates/ecstore/src/services/tier/warm_backend*.rs, crates/ecstore/src/bucket/lifecycle/tier_sweeper.rs, replication code under crates/ecstore/src/bucket/
  - Evidence: Invariant in AGENTS.md and docs/operations/tier-ilm-debugging.md; real bug fixed by 0fad35645 'send versionId on version-purge deletes to generic S3 targets' (#4401) — the versioned direction, and #4552 — the unversioned direction
 - If the diff changes xl.meta encoding (adds/reorders msgpack header fields, touches FileMeta::marshal_msg or codec.rs encode paths), attack downgrade and cross-vendor parse: encode an object with the new code and decode it with (a) the meta_ver<=3 read path and (b) the real-MinIO fixture tests from #4377. Then check the header signature: is it recomputed over the new bytes, or copied/hardcoded? MinIO validates it; a stale or zero signature makes MinIO reject the file. Finally verify XL_META_VERSION was not silently bumped — old RustFS/MinIO nodes reject meta_ver > 3 during a rolling upgrade.
  - Where: crates/filemeta/src/filemeta.rs (XL_HEADER_VERSION/XL_META_VERSION, lines ~46-54), crates/filemeta/src/filemeta/codec.rs (check_xl2_v1, decode_xl_headers)
  - Evidence: Real bug 073bc9675 'compute header signature instead of hardcoding zero' (#4343); format contract pinned in docs/architecture/minio-file-format-compat.md (write meta_ver 3, read <=3, XL2 magic); parity fixtures from a91d9cefc (#4377)
 - If the diff touches xl.meta / FileInfo decode (into_fileinfo, version parsing, part arrays), construct hostile foreign input: a MinIO- or corruption-shaped msgpack with a parts-count that disagrees with the etags/sizes array lengths, missing optional fields, and a meta_ver 2 object with legacy checksum. Trace whether the new code indexes past an array, panics, or fabricates default values instead of returning a decode error. Run the pinned legacy fixtures (test_issue_2265_legacy_meta_v2_object_compatibility, test_issue_2288) plus the #4377 real-MinIO xl.meta parse tests against the diff.
  - Where: crates/filemeta/src/ (fileinfo.rs, filemeta.rs, filemeta/codec.rs, filemeta/version.rs)
  - Evidence: Real bug 7efacbdf9 'validate part array lengths in into_fileinfo' (#4382); legacy meta_ver 2 regression fixtures at crates/filemeta/src/filemeta.rs (~:1130-:1174) cited by docs/architecture/minio-file-format-compat.md
 - If the diff 'corrects' a formula, constant, or layout that is a byte-for-byte MinIO port (shard-size math, bitrot hash interleaving, erasure distribution, inline-data prefix), treat the correction itself as the bug: verify against legacy on-disk data before accepting. Concretely: run crates/ecstore/tests/legacy_bitrot_read_test.rs and the ECA-18 pinning tests; check whether existing objects written by old RustFS or MinIO still verify byte-for-byte. Known trap examples: bitrot_shard_file_size's bare return for non-streaming algorithms is CORRECT MinIO whole-file behavior, and the 32-byte prefix on inline data is the HighwayHash256 bitrot hash, not corruption.
  - Where: crates/ecstore/src/erasure/coding/bitrot.rs, crates/ecstore/src/io_support/bitrot.rs, crates/filemeta/src/fileinfo.rs
  - Evidence: f96314a1d 'pin streaming-only bitrot layout invariant (ECA-18)' (#4553) — audit explicitly decided NOT to change the formula because it breaks legacy interop; #4377 proved the inline-data prefix is the bitrot hash
 - For any diff that copies object metadata into an S3-client-visible surface (GET/HEAD response headers, notification event userMetadata, ListObjects/replication payloads, copy-object metadata directives), construct an object carrying internal keys under BOTH prefixes and in non-canonical casing ('X-Minio-Internal-Compression') and confirm every one is stripped via is_internal_key (which is case-insensitive) — not by an exact-match filter on one prefix. Leaked internal keys are an API-semantics break and an information leak.
  - Where: rustfs/src/storage/, crates/notify/, replication and copy_object paths in crates/ecstore/
  - Evidence: Real bug cf8929189 'strip rustfs/minio internal metadata from event userMetadata' (#4419); is_internal_key contract in crates/utils/src/http/metadata_compat.rs
 - If the diff touches crates/protos (node.proto, models.fbs) or internode RPC request/response structs, attack the rolling-upgrade interleaving: an old node sends a message without the new field to a new node, and a new node sends the extended message to an old node. Verify proto field numbers are only appended (never reused/renumbered), FlatBuffers tables are only extended at the end, and that an absent new field decodes to a safe default on the receiving side — 'safe' meaning it must not be interpreted as success/authorization (RPC errors fail closed) and must not flip a quorum decision.
  - Where: crates/protos/ (node.proto, models.fbs, generated/), gRPC transport and dispatch in the internode layer
  - Evidence: 6f613317f 'optimize gRPC transport' (#4337) shows the wire layer churns; security advisory 68cw fixed by PR#4402 established RPC fail-closed as a repo rule (see .agents/skills/security-advisory-lessons)
 - For S3 handler diffs, replay the request shapes real clients actually send, not just the canonical one: mc and aws-sdk differ on path normalization (root '//' ListBuckets), virtual-host vs path style, and header casing. Then attack every pagination boundary the diff touches: request exactly max-keys/max-uploads/max-parts items and verify the response returns exactly N (not N+1), sets IsTruncated correctly, and yields a NextMarker/KeyMarker that resumes without skipping or duplicating — construct the N+1st-item case explicitly.
  - Where: rustfs/src/storage/ S3 handlers, listing paths in crates/ecstore/src/store/ and set_disk/
  - Evidence: Real bugs 511ad31ba 'normalize root double-slash ListBuckets requests' (#4336) and fefa70b31 'stop ListMultipartUploads from returning one upload past max-uploads' (#4447); docs/architecture/s3-compatibility-matrix.md is the compat source of truth
 - If the diff changes bucket-metadata (.metadata.bin) or IAM/config parsing structs, run it against the real MinIO RELEASE.2025-07-23 fixtures: the msgpack blob uses PascalCase field names, so any serde rename, field-type change, or derive tweak silently drops MinIO-written fields instead of erroring. Verify parse_all_configs still loads all ten config types from the fixture without loss, and that drop-in migration still decrypts MinIO-encrypted IAM/server config rather than treating ciphertext as corrupt.
  - Where: crates/ecstore/src/bucket/metadata*, crates/ecstore/src/bucket/migration.rs, IAM/config load paths in crates/iam/ and crates/config/
  - Evidence: Fixture parity test parses_real_minio_bucket_metadata_blob_without_loss from a91d9cefc (#4377); real bug 717cdd2ab 'decrypt MinIO IAM & server config on drop-in migration' (#4358); format matrix in docs/architecture/minio-file-format-compat.md
 - If the diff adds a compatibility shim, legacy fallback, wrapper, or old-endpoint alias (grep the diff for 'legacy', 'fallback', 'compat', 'deprecated'), verify two things: (1) it carries a RUSTFS_COMPAT_TODO(<task-id>) marker with an exact removal condition and a matching entry in the register — an unmarked shim becomes permanent dead weight; (2) the fallback's default direction is safe for old data: e.g. a new decode path must fall back to the legacy decode for old objects by default, not gate legacy reads behind an opt-in flag that makes existing data unreadable after upgrade.
  - Where: Anywhere in the diff; register at docs/architecture/compat-cleanup-register.md; recent example: allow_inplace_legacy_fallback flag in the ecstore erasure codec streaming path
  - Evidence: docs/architecture/compat-cleanup-register.md review checklist; d232a46b4 wired legacy decode prefetch behind a default-OFF gate while keeping legacy reads working (#4542), with arity fallout fixed in 05890d6e2 (#4573)
 Null report example: "Attacked dual-key metadata writes/removals against MinIO-only-key objects, nil/empty transitioned-versionID paths to the tier, xl.meta encode against meta_ver<=3 decoders and the #4377 real-MinIO fixtures, and proto field-number evolution for old-node/new-node RPC — no compatibility break found."
 ### Performance reviewer
 - For each `.clone()` or allocation added to a per-request/per-object path, identify the copied data and execution frequency. Report a finding only for a concrete repeated cost or benchmark regression. Recommend borrowing, moving, `Bytes`/`Arc`, `Cow`, or capacity reservation only when it reduces that cost without obscuring ownership or APIs.
  - Where: crates/ecstore/src/set_disk/**, crates/ecstore/src/store*.rs, rustfs/src/storage/, crates/filemeta/, request handlers in rustfs/src/
  - Evidence: crates/ecstore/AGENTS.md 'Allocation Discipline in Hot Paths'; .agents/skills/rust-code-quality/SKILL.md requires a concrete hot-path cost rather than a proxy metric
 - For every new sync_all/sync_data/fdatasync/flush/File::sync call in the diff, trace the call chain to DurabilityMode / RUSTFS_DRIVE_SYNC_ENABLE resolution (crates/ecstore/src/disk/local.rs:291 DurabilityMode, :347 resolve_durability_mode) and to per-bucket durability overrides. Construct the run where the operator sets mode=none (or legacy RUSTFS_DRIVE_SYNC_ENABLE=false) and the new fsync still fires — that is an ungated durability cost and a regression on 4KiB writes.
  - Where: crates/ecstore/src/disk/local.rs, crates/ecstore/src/bucket/durability.rs, crates/ecstore/src/set_disk/** (rename_data/commit paths), any crate doing tokio::fs or std::fs writes
  - Evidence: #4221 fsync work caused a measured -10% 4KiB write regression (#814 investigation), later gated; durability modes added in eaff17cad (#4397), per-bucket tier overrides in 13e48d93a (#4407); 2df315baf (#4493) shows even ancestor-dir fsyncs are routed through the gate
 - Attack blocking-work placement from both directions: (a) find new synchronous fs calls, hashing, or EC encode/decode executed directly on an async runtime thread without spawn_blocking/block_in_place — construct the stall (a slow disk blocks a worker thread and every task queued on it); (b) find new code that splits one logical disk operation into multiple spawn_blocking hops per object — each hop is a threadpool round-trip, so K hops x N objects multiplies latency. Demand the author justify the placement with the size of the work, not habit.
  - Where: crates/ecstore/src/disk/local.rs, crates/ecstore/src/erasure_coding/, crates/ecstore/src/bitrot/, crates/rio/
  - Evidence: 608ab14d7 (#4554, HP-12) folded metadata open+fstat+read into a single spawn_blocking because per-op hops were measurably slow; 8fc637fb1 (#4484) moved the short EC encode inline because block_in_place cost exceeded the work — direction depends on measured work size
 - For each lock acquisition the diff adds or relocates, mark the guard's live range and list every .await and disk/RPC call inside it. Construct the contention interleaving: N concurrent requests serialize on the guard while the holder waits on IO; for namespace/multipart commit locks, compute worst-case hold time (fsync + rename per disk) against the lock's timeout. Also diff the acquisition order against other paths taking the same locks (ABBA).
  - Where: crates/ecstore/src/set_disk/** (commit/rename paths), crates/lock/, crates/audit/ registry, any RwLock/Mutex in per-request paths
  - Evidence: crates/ecstore/AGENTS.md 'Lock Ordering'; c0d5f938f (#4421) fixed a real ABBA deadlock between registry and stream_cancellers; #4370 history: fsync-heavy serial cross-disk commits held a lock long enough to blow test timeouts (#4370)
 - Trace exactly what executes inside the PUT commit critical section (under the object write lock, between tmp write and rename_data completion) before vs after the diff. Any newly added work there — cleanup, extra stat, additional rename, O_DIRECT write, logging — is an attack target: construct the per-PUT latency delta and demand it be moved off the critical section or parallelized across disks.
  - Where: crates/ecstore/src/set_disk/ops/*, crates/ecstore/src/disk/local.rs rename_data path
  - Evidence: Three real optimizations removed exactly this class of regression: e7cc719c1 (#4389) moved speculative PUT-tail tmp cleanup off the hot path, 92c8c6db7 (#4411) moved O_DIRECT shard-writes off the commit critical section, 651ccac13 (#4487) parallelized tmp xl.meta write and shard fdatasync on commit
 - Find any new loop in a batch API that performs a per-item stat/read/RPC sequentially. Construct the concrete blowup: a 1000-key DeleteObjects or a full listing page -> 1000 serial round-trips added by the diff. Demand either a gate (skip when not needed) or bounded parallelism; for startup/load paths, check for accidental O(n^2) (re-scanning the full list per item).
  - Where: crates/ecstore/src/store_delete*.rs / batch object APIs, listing/metacache paths, crates/iam/ store loading, crates/heal/
  - Evidence: a413729b1 (#4398) had to gate and parallelize the DeleteObjects per-object stat fanout after it shipped serial; 16a91c35e (#4537) fixed O(n^2) IAM startup load by chunking — both were diff-introduced fanouts of this exact shape
 - For every buffer the diff allocates on the encode/decode/shard path, check: is it sized with with_capacity to the EC-expanded block (not the logical size, not default-grown)? Does it copy into a fresh Vec where Bytes::slice/clone (refcount) or the io-core buffer pool would avoid the copy? Does the diff read hash and data in separate passes where one pass suffices? Construct the per-block byte-copy count before vs after. If the diff touches the io-core pool, verify gauge accounting still balances.
  - Where: crates/ecstore/src/erasure_coding/, crates/ecstore/src/bitrot/, crates/io-core/src/pool.rs, crates/rio/
  - Evidence: 92bf55ce6 (#4396) fixed a real regression by right-sizing BytesMut encode ingest capacity to the EC-expanded block; 47bee8b31 (#4475) merged bitrot hash+data into one read pass; 7fa3d0d4b (#4534) shows pool gauge accounting is easy to drift when touching buffer reuse
 - For every logging or instrumentation statement the diff adds, classify the call site frequency: per-request, per-object, per-shard, or per-block. Anything info!/warn!/error! at per-object frequency or higher is a finding — construct the flood (one listing under client cancellation, one 10k-object heal) and count emitted lines. New metrics/timers on the data path must be feature-gated, not always-on. Run scripts/check_logging_guardrails.sh on the diff.
  - Where: any per-request/per-object code, especially crates/ecstore listing and heal loops, rustfs/src/storage/ handlers; scripts/check_logging_guardrails.sh
  - Evidence: .agents/skills/rustfs-logging-governance/SKILL.md (trace level for hot-path/repetitive success events); d25ddb0e1 (#4372) fixed real listing-cancellation error-log noise; hotpath instrumentation is deliberately feature-gated (3f13d098b #4394, f262fcfce #4541 HP-14)
 - Count how many times the diff's request path parses or fetches the same metadata: xl.meta/FileMeta decoded more than once per object, bucket metadata (metadata_sys) re-fetched inside a per-object loop, or the dual x-rustfs-internal/x-minio-internal key lookup re-run repeatedly on the same map. Construct the per-request parse count before vs after; a second full FileMeta decode per GET is a finding.
  - Where: crates/filemeta/, crates/ecstore/src/set_disk/** read paths, crates/ecstore/src/bucket/metadata_sys.rs, crates/utils/src/http/metadata_compat.rs
  - Evidence: 608ab14d7 (#4554) exists because redundant metadata-read syscall sequences per object were measurable; CLAUDE.md dual-key metadata convention makes repeated get_bytes lookups an easy hidden double-parse
 - If the diff touches PUT/GET/commit/erasure paths and claims 'no perf impact', demand numbers, not assertion: run the criterion benches (cargo bench -p ecstore — comparison_benchmark, erasure_benchmark, rename_data_meta_benchmark, single_block_non_inline_benchmark per crates/ecstore/benches/) against origin/main, and for end-to-end paths the warp A/B relative-budget gate (scripts/run_hotpath_warp_ab.sh --baseline-ref origin/main, as .github/workflows/performance-ab.yml runs it). Probe specifically at 4KiB object size — that is where the last real regression hid.
  - Where: crates/ecstore/benches/, .github/workflows/performance-ab.yml, scripts/run_hotpath_warp_ab.sh
  - Evidence: crates/ecstore/AGENTS.md: 'Benchmark-sensitive changes should include measurable rationale'; performance-ab.yml (215747022 #4480) is the repo's own relative-budget gate; the #4221 regression was only visible at 4KiB writes (#814 bisect)
 Null report example: "Attacked the new rename_data commit-section work, durability-gate routing of the added fdatasync, guard live-range across the shard-write awaits, and per-object clone count in the PUT path; ran comparison_benchmark + rename_data_meta_benchmark vs origin/main (4KiB delta within noise) — no break found."
 ### Test-coverage skeptic
 - For every testable behavior claim in the PR description, revert that hunk and name the focused test or executable check that detects the revert. If no reasonable check exists, require the reason and residual risk from the validation floor. Especially verify the check exercises the real production path, not a lookalike helper.
  - Where: All crates; highest value in crates/ecstore, rustfs/src/storage, crates/heal
  - Evidence: AGENTS.md testable-behavior exit criterion. Real bug: PR #4220 (ghost-directory cleanup) merged with green tests but its fix never executed on the real delete path — required follow-up rustfs#4307, backlog#798 stayed OPEN. The tests exercised a path the production flow never took.
 - Read each added/modified test and confirm it asserts the real outcome (returned value, stored bytes, error variant), not merely 'call succeeded' or 'no panic'. Flag any test whose only observable is that the function returned, and any `assert!(result.is_err())` that never checks WHICH error. Then check: does the test prove the exploit/failure form is denied, or only that the intended form still works?
  - Where: crates/e2e_test (security_boundary_test.rs pattern), and every #[cfg(test)] module in the diff
  - Evidence: Commit dee8e4e63 (#4466) had to rewrite 277 lines of crates/e2e_test/src/security_boundary_test.rs because 'security boundary tests' passed without asserting real outcomes. .agents/skills/rust-code-quality/SKILL.md requires an observable failure criterion; .agents/skills/security-advisory-lessons/SKILL.md asks whether the exploit form is denied.
 - When the diff adds a boolean/mode parameter or config flag, find the test that fails if the flag's effect is INVERTED inside the changed function. Tests that were mechanically updated to pass `false`/default at every call site assert nothing about the new behavior. Execute the check: flip the flag's branch in the source and confirm at least one test goes red for each branch.
  - Where: crates/ecstore/src/set_disk/ (e.g. build_codec_streaming_part_reader), any function gaining a parameter
  - Evidence: Commit 05890d6e2 (#4573): PR #4560 added a 15th param allow_inplace_legacy_fallback; the arity tests were fixed by passing `false` everywhere — they assert Err outcomes independent of the flag, so the fallback behavior itself has no revert-detecting test at those sites.
 - Mutation spot-check on error propagation: for each newly added `?`, `return Err`, or error-mapping line, mentally replace it with `Ok(default)`/ignore and ask which test fails. The swallowed-error bug class recurs in this repo and always ships with green tests — a fix that propagates errors needs a test that injects the failure (faulty disk, failed rename, dispatch error) and asserts the caller sees Err.
  - Where: crates/ecstore (disk delete/rename, reduce_errs), crates/audit, crates/notify, crates/targets
  - Evidence: Three recent fixes for the same class: f7d2b2563 (#4546, disk delete/rename failures swallowed), dbc628f16 (#4424, audit dispatch failures swallowed), 20d61c73b (#4551, reduce_errs leaking nil placeholder as dominant error). All existed while tests were green.
 - Any test touching GET/read/reconstruct/stream paths must assert the FULL body content and exact length against a known value, not status-ok or first-bytes. Construct the degraded-read case (missing/inconsistent shards forcing EC reconstruction) and assert byte-for-byte equality; a mid-stream failure that truncates the body passes every test that only checks headers or the first chunk.
  - Where: crates/ecstore/src/set_disk/read.rs and ops/, crates/rio, crates/e2e_test GET scenarios
  - Evidence: Known live bug: EC reconstruct-read verification failure mid-GET at set_disk read path silently truncates the body → client 'unexpected EOF'; version-independent, undetected by existing suites because none assert full-body integrity under shard inconsistency.
 - For on-disk / on-wire format changes (xl.meta, .metadata.bin, bitrot framing), reject round-trip-only tests: a struct serialized and deserialized by the same code under test cannot catch format drift. Demand the test parse a REAL captured fixture from crates/filemeta/tests/fixtures, crates/ecstore/tests/fixtures, or crates/rio-v2/tests/minio_fixture_lab — or capture a new one from a single-disk MinIO instance (RELEASE.2025-07-23 procedure from #4377).
  - Where: crates/filemeta, crates/ecstore (headers, msgpack bucket metadata), crates/rio-v2, migration code
  - Evidence: Commit 073bc9675 (#4343): filemeta header signature was hardcoded to zero — round-trip tests passed for months. Commit a91d9cefc (#4377) established the real-MinIO fixture convention (inline/versioned/multipart xl.meta, HighwayHash256-prefixed inline bodies) precisely because synthetic fixtures proved nothing about interop.
 - Attack new concurrency tests for flakiness-by-construction: grep the added tests for `sleep(`, fixed timeouts under ~30s on lock acquisition, and use of shared global state (disk registry, lock client, GLOBAL_*). Serialized cross-disk commits exceed small lock timeouts under full-suite CI disk load. If the test shares global state or saturates IO, it must join the `ecstore-serial-flaky` nextest test-group in .config/nextest.toml (note: serial_test's #[serial] does NOT work — nextest runs each test in its own process). Require readiness polling, never fixed sleeps.
  - Where: crates/ecstore tests, crates/e2e_test, .config/nextest.toml
  - Evidence: Commit 2dfa3d3c3 (#4370): concurrent_resend test flaked with Lock(Timeout 5s) on CI — six legitimate serialized cross-disk commits under IO pressure needed 30s. Commit 7c701d9f2 (#4558) created the nextest test-group after bucket_delete_* raced make_bucket into InsufficientWriteQuorum. 65849740f (#4213) deflaked global-state contamination. crates/e2e_test/AGENTS.md: 'readiness checks and explicit polling over fixed sleep-based timing'.
 - If the diff writes internal object metadata, run the dual-key mutation: delete the `x-minio-internal-<suffix>` write (keeping only `x-rustfs-internal-`) and check whether any test fails. Because `get_bytes` prefers the RustFS key, every read-back test stays green while MinIO interop is silently broken — coverage must include an assertion that BOTH keys are present in the stored metadata map.
  - Where: crates/utils/src/http/metadata_compat.rs and all its callers in crates/ecstore and rustfs/src/storage
  - Evidence: CLAUDE.md domain convention: metadata must be written under both x-rustfs-internal- and x-minio-internal- keys for MinIO interop; get_bytes prefers the RustFS key, making the MinIO-key half of the invariant invisible to read-back tests.
 - For changed quorum/version/UUID logic, name the tests covering the specific poison values: quorum−1 disks, nil UUID, absent vs empty vs nil-serialized UUID bytes, remote-tier version_id of None/"" (unversioned tier bucket → no versionId sent), and the same metadata read on both MetaObject and MetaDeleteMarker version types. Mutation check: remove a `.filter(|u| !u.is_nil())` guard from the diff and confirm a test fails; if none does, the nil-UUID class is uncovered.
  - Where: crates/ecstore (tier recovery, heal, quorum paths), crates/filemeta, code reading UUIDs from xl.meta metadata
  - Evidence: Commit 726f3dc18 (#4552) fixed rejection of empty remote version_id in tier recovery. CLAUDE.md invariant: absent/empty/nil UUID all mean 'no value', not Uuid::nil(). docs/operations/tier-ilm-debugging.md: None/"" tier version means unversioned bucket. df9cbc4ed (#4427): unvalidated distribution values caused shuffle index panic — edge values reached production untested.
 - For any pagination/limit/truncation change, construct the exact-boundary test: result count == max (page exactly full), max+1, and a delimiter re-fold that lands precisely on the page boundary — assert both the item count AND the is_truncated/continuation marker. Off-by-one at the page boundary is a recurring shipped bug here.
  - Where: crates/ecstore listing paths (list_objects, ListMultipartUploads, metacache), S3 handlers in rustfs/src/storage
  - Evidence: Two shipped boundary bugs: fefa70b31 (#4447) ListMultipartUploads returned one upload past max-uploads; d91f4d455 (#4538) delimiter re-fold of a full page lost the truncation flag. Both survived existing tests because no test pinned n == max exactly.
 - A green focused test is evidence only for the targets it builds. Follow the `AGENTS.md` validation tier: add package-scoped Clippy or broader test-target compilation only when changed targets, features, or dependents remain uncovered; do not require a workspace-wide build by default.
  - Where: All crates; especially concurrent-branch merges into crates/ecstore
  - Evidence: #4322 broke main because only cargo test ran (field_reassign_with_default is clippy-only). b06f3df6b (#4441) and 05890d6e2 (#4573): test code broke the workspace test build (E0061) on main after textually-clean merges, failing CI for every open PR.
 Null report example: "Attacked revert-detection for all 3 claimed behaviors (each has a named test that fails on revert), flag-inversion on the new fallback parameter (both branches covered in codec_streaming tests), full-body assertions on the changed GET path, and n==max pagination boundary — no coverage gap found."
 ## Sources and maintenance
 Probes are distilled from shipped bugs in git history (commit/PR references
 above), GitHub security advisories (see the security-advisory-lessons
 skill), scoped `AGENTS.md` rules, and invariants under `docs/architecture/`
 and `docs/operations/`. Line numbers drift; re-locate the invariant. Merge
 new incidents into an existing probe when they share a failure class; add a
 new probe only for a distinct attack, rather than growing the root policy.
@@ -0,0 +1,24 @@
 # Compatibility Lens
 - Internal metadata uses `metadata_compat` helpers for dual RustFS/MinIO keys,
  including mixed casing and removal of both twins.
 - Binary UUID metadata treats absent, empty, and nil as no value. Unversioned
  remote tiers receive no `versionId`; versioned purge requests retain the real
  version ID.
 - `xl.meta` changes preserve supported header/meta versions, recompute
  signatures, decode legacy fixtures, and remain readable by old RustFS/MinIO.
 - Foreign/corrupt metadata validates parallel array lengths and missing fields;
  it returns a decode error rather than indexing, panicking, or fabricating data.
 - Do not “correct” byte-for-byte MinIO ports without legacy fixture evidence.
  Bitrot framing, shard math, distribution, and inline prefixes are contracts.
 - Client-visible metadata/events strip both internal prefixes
  case-insensitively.
 - Proto fields are appended, never reused/renumbered; FlatBuffers tables extend
  compatibly and absent new fields fail closed where authorization/quorum is
  involved.
 - Replay real client request shapes and exact pagination boundaries for S3
  handler changes.
 - Bucket metadata/IAM/config parsing remains compatible with pinned real MinIO
  fixtures and encrypted migration data.
 - Compatibility shims use `RUSTFS_COMPAT_TODO(<task-id>)`, have a removal
  condition, and default toward reading old data safely.
@@ -0,0 +1,23 @@
 # Concurrency and Durability Lens
 - For every changed lock, enumerate overlapping lock sets and construct the
  ABBA interleaving. Multiple-lock order must be documented and consistent.
 - Mark guard lifetimes and every `.await`, disk, and RPC call inside them.
  Estimate contention and timeout behavior under concurrent requests.
 - Object commits remain fenced if the distributed lock is lost after shard
  writes and before metadata rename.
 - For write/rename changes, trace `write tmp -> sync tmp -> rename -> sync parent
  -> sync required ancestors`; simulate a crash after each step and honor the
  configured durability gate.
 - Multi-disk fan-out counts every result. Quorum-minus-one cannot become success;
  heal remains best-effort per target where that is the established contract.
 - At every new cancellable await between mutation and cleanup/commit, drop the
  future and inspect leftover files, counters, permits, and replay state.
 - Multipart operations on the same upload ID are serialized where required;
  abort/complete/list races cannot delete parts before durable commit.
 - Post-commit cleanup is best-effort, retry-safe, and cannot fail an already
  committed write or delete the last surviving copy.
 - Persisted read-modify-write uses serialization/CAS. Queue replay is crash-safe
  and duplicate delivery has an idempotency contract.
 - Streaming reconstruction failures after partial output surface as errors, not
  successful EOF.
@@ -0,0 +1,29 @@
 # Correctness Lens
 Attack the changed behavior, not every subsystem in the repository.
 - Trace new error paths to the caller. Inject the ignored/wildcard variants and
  verify they cannot become success, not-found, or a plausible default.
 - Exercise zero/empty/missing, maximum, and exact-boundary inputs for every
  changed count, size, index, page limit, or optional value.
 - For aggregation/quorum changes, test exactly quorum and quorum-minus-one with
  mixed disk errors and nil/placeholder entries.
 - For listing/pagination, test `n == max`, `n == max + 1`, delimiter folding,
  continuation markers, and object/prefix name collisions.
 - For EC/read/streaming changes, inject failure after partial output and verify
  the client receives an error rather than a clean truncated body. Assert exact
  bytes and length.
 - For multipart/object commits, fail before/after rename and cleanup; committed
  data must remain readable and pre-commit cleanup must not destroy parts.
 - For version/index ordering, test `len - 1`, `len`, equal timestamps, missing
  versions, and deterministic tie-breaking.
 - For directory-object behavior, trace `__XLDIR__` at the store layer; branches
  below the layer that sees trailing slashes are dead.
 - For binary UUID metadata, absent, empty, and nil all mean no value. Never send
  nil/empty `versionId` to an unversioned tier.
 - For agent rules/skill routers, test a trigger matrix covering ordinary
  inquiry, low-risk implementation, explicit review, high-risk code, PR
  creation, release, and post-PR monitoring. Each case must select only the
  intended workflow and retain required safety/authorization boundaries.
 Null verdicts name only the probes relevant to the diff.
@@ -0,0 +1,20 @@
 # Performance Lens
 - For added clones/allocations on request/object/block paths, quantify copied
  data and frequency. Recommend borrowing, move, `Bytes`/`Arc`, `Cow`, or
  capacity reservation only for a concrete repeated cost.
 - Route every new sync/flush through the durability-mode and bucket override
  gates; mode `none` must not pay the new fsync.
 - Keep blocking filesystem/CPU work off async runtime threads, but do not split
  one small operation into many `spawn_blocking` round trips.
 - Measure lock hold time across I/O and compare acquisition order for ABBA.
 - Keep cleanup, extra stat/rename, and diagnostics out of the PUT commit critical
  section when they need not be there.
 - Detect per-item serial I/O/RPC in batch APIs and accidental quadratic scans;
  use a gate or bounded concurrency when the concrete fan-out warrants it.
 - Count buffer growth and byte copies in EC/bitrot paths; preserve pool gauge
  balance and avoid repeated metadata decode/fetch per object.
 - Repetitive success logs stay at `trace`; metrics/instrumentation on hot paths
  require an existing gate.
 - Claims of no impact on PUT/GET/commit/erasure paths need relevant benchmark or
  A/B evidence, especially for 4 KiB objects.
@@ -0,0 +1,31 @@
 # Security Lens
 Use `security-advisory-lessons` only for a dedicated advisory/security audit.
 For an ordinary matched diff, attack these boundaries:
 - Admin routes: route registration, whitelist, handler authn, and the exact
  `AdminAction` must agree. Read-only diagnostics still require admin authz.
 - IAM/service accounts: treat parent, claims, keys, groups, status, and policy
  names as attacker-controlled; prove ownership/root authority before writes.
 - Protocol frontends: every changed/sibling command authorizes the matching S3
  action before reaching storage.
 - Secrets/signatures: use constant-time comparison, normalize public failures,
  keep RPC/root/STS keys independent, and fail closed when secrets are absent.
 - RPC: bind signatures to the exact method/path and timestamp; reject replay,
  stale, malformed, truncated, and invalid-enum payloads without panic.
 - Paths/object/archive entries: reject traversal, absolute/platform escapes,
  and normalization differences between authz and storage.
 - Copy/multipart/presigned POST: enforce source, destination, version-aware
  actions, copy-source conditions, and every signed policy condition.
 - Logging/errors: never expose credentials, tokens, expected signatures, raw
  secret-bearing input, or merged configs—including via `Debug` and parse errors.
 - Untrusted serde: reject unknown fields where compatible and validate
  security-critical defaults/ranges before numeric conversion.
 - SSE/browser/CORS/trusted proxy: inspect stored ciphertext and wrapper order;
  isolate user content; never reflect credentialed arbitrary origins or trust
  forwarded identity from direct clients.
 - Object Lock: unreadable/fabricated/unparsable metadata fails closed across
  foreground, lifecycle, scanner, and force-delete paths.
 Security findings distinguish unauthenticated compromise from a
 low-privileged authenticated bypass.
@@ -0,0 +1,22 @@
 # Simplicity Lens
 - Compare the production diff with the smallest equivalent local edit. Fewer
  lines alone are not evidence; the replacement must preserve correctness,
  compatibility, readability, and real boundaries.
 - Search the touched crate, domain owner, `crates/utils`, `crates/common`, and
  relevant dependencies for each new helper, constant, wrapper, or fixture.
 - Reject forced reuse when normalization, error, deadline, or durability
  semantics differ.
 - Require a concrete trigger for every new defensive branch. Keep boundary
  checks for disk/RPC/version data and checks immediately before destructive
  actions.
 - Flag one-caller helpers only when they merely forward or split a short linear
  flow without adding domain naming, invariant isolation, or useful context.
 - Ensure a replacement removes the superseded in-scope path or keeps one
  canonical core behind a documented compatibility adapter.
 - Remove narration/change-history comments; preserve concise safety, lock,
  durability, and compatibility invariants.
 - Treat tests, fixtures, generated code, and documentation separately from
  production growth. Do not optimize away meaningful regression coverage.
 A finding must include a concrete smaller design, not a style preference.
@@ -0,0 +1,24 @@
 # Test-Coverage Lens
 - For every behavior claim, name the focused test/check that fails if the
  changed hunk is reverted. If none is practical, require the reason and
  residual risk.
 - Confirm tests exercise the real production path and assert returned values,
  exact bytes, stored state, or the specific error variant—not only success,
  `is_err()`, or no panic.
 - For new flags/modes, verify each branch and ask which test fails if the branch
  is inverted.
 - For new error propagation, inject the failure and assert the caller observes
  it; mentally replacing `?`/`return Err` with success must break a test.
 - Streaming GET tests assert the complete body and length under degraded reads.
 - Disk/wire-format tests use pinned foreign/legacy fixtures; same-code
  round-trips are insufficient for compatibility.
 - Concurrency tests use readiness polling, isolate global state, and avoid fixed
  sleeps or unrealistically short timeouts. Use nextest groups when process-level
  serialization is required.
 - Internal metadata tests assert both RustFS and MinIO keys, not only read-back
  through a helper that prefers one key.
 - Boundary companions are distinct coverage: `n == max` vs `max + 1`, and
  absent vs empty vs nil UUID.
 - A focused test proves only the targets/features it builds. Add compilation or
  Clippy only for uncovered changed targets.
@@ -1,11 +1,12 @@
 ---
 name: code-change-verification
-description: Verify code changes by identifying correctness, regression, security, and performance risks from diffs or patches, then produce prioritized findings with file/line evidence and concrete fixes. Use when reviewing commits, PRs, and merged patches before/after release.
+description: Review a commit, PR, or merged patch when the user requests ordinary code-change verification. Do not combine with adversarial-validation; use that skill instead for explicitly adversarial, substantial, or high-risk RustFS reviews.
 ---
 # Code Change Verification
-Use this skill to review code changes consistently before merge, before release, and during incident follow-up.
+Use this skill for an ordinary requested review. If the root policy or user calls
 for adversarial validation, use `adversarial-validation` instead of running both.
 ## Quick Start
@@ -79,4 +80,3 @@ Run the full checklist in [rust-code-quality](../rust-code-quality/SKILL.md) —
  - Impact: ...
  - Fix suggestion: ...
  - Validation: ...
@@ -1,4 +1,4 @@
 interface:
  display_name: "Code Change Verification"
  short_description: "Prioritize risks and verify code changes before merge."
-  default_prompt: "Inspect a patch or diff, identify correctness/security/regression risks, and return prioritized findings with file/line evidence and fixes."
+  default_prompt: "Use $code-change-verification for an ordinary requested diff review with prioritized findings."
@@ -1,97 +1,46 @@
 ---
 name: pr-creation-checker
-description: Prepare PR-ready diffs by validating scope, checking required verification steps, drafting a compliant English PR title/body, and surfacing blockers before opening or updating a pull request in RustFS.
+description: Perform the final RustFS PR preflight and draft compliant English title/body metadata immediately before creating or updating a PR. Do not use during implementation or as a second general code review.
 ---
 # PR Creation Checker
-Use this skill before `gh pr create`, before `gh pr edit`, or when reviewing whether a branch is ready for PR.
+Use this skill only at the PR boundary. Reuse completed diff review and
 verification evidence; do not reread the repository or rerun equivalent checks.
-## Read sources of truth first
+## Preflight
- Read `AGENTS.md`.
+1. Confirm the branch is based on current `origin/main` and contains only the
- Read `.github/pull_request_template.md`.
+   intended task diff.
- Use `Makefile` and `.config/make/` for local quality commands.
+2. Inspect `git diff --stat`, `git diff --check`, and changed file names for
- Use `.github/workflows/ci.yml` for CI expectations.
+   secrets, logs, generated artifacts, or unrelated edits.
- Do not restate long command matrices or template sections from memory when the files exist.
+3. Confirm the checks selected by root `AGENTS.md` passed on the final diff.
   Do not replace focused behavioral tests with a generic gate or rerun checks
   already covered by an unchanged umbrella run.
 4. Read `.github/pull_request_template.md`. Consult `Makefile`, `.config/make/`,
   or CI only when the required command/current gate is uncertain.
 5. Return `BLOCKED` for an unclean scope, missing required evidence, failed
   required checks, or non-compliant metadata.
-## Workflow
+## Metadata
-1. Collect PR context
+- Title: English Conventional Commit, at most 72 characters, with no tool
- Confirm base branch, current branch, change goal, and scope.
+  prefix.
- Confirm whether the task is: draft a new PR, update an existing PR, or preflight-check readiness.
+- Body: English, exact template headings, `N/A` where needed, concise rationale,
- Confirm whether the branch includes only intended changes.
+  actual verification commands, and material risks/rollback notes.
 - Use repository-relative paths; never include local absolute paths.
 - Keep prose paragraphs on one logical line and never include the literal
  sequence `\n`.
 - Use a temporary body file with `gh pr create --body-file` or
  `gh pr edit --body-file`; never pass multiline Markdown inline.
-2. Inspect change scope
+## Output
 - Review the diff and summarize what changed.
 - Inspect `git diff --stat` and `git diff --numstat`; assess production-code growth separately. Tests, fixtures, generated code, and documentation have no growth budget. Treat line counts as signals, not quotas.
 - Call out unrelated edits, generated artifacts, logs, or secrets as blockers.
 - Mark risky areas explicitly: auth, storage, config, network, migrations, breaking changes.
 - Use the simplicity-adversary verdict instead of producing a per-symbol inventory. Block growth only when the review identifies duplication or gives a concrete smaller design that preserves correctness, compatibility, readability, and real boundaries.
 - Confirm replacement implementations remove the superseded in-scope path or adapt compatibility at the boundary to one canonical core.
 - Scan the diff for newly added string literals and confirm whether they duplicate values already defined as constants/enums/typed wrappers in the same module or shared modules.
 - Treat introducing a new hardcoded literal where a project constant already exists as a likely regression risk; require either a refactor to reuse the constant or an explicit exception explanation in the PR body.
-3. Verify readiness requirements
+- Status: `READY` or `BLOCKED`.
- Select checks from `AGENTS.md` "Verification Before PR" based on the final diff's risk tier. Do not replace a focused behavioral test with `make pre-commit`, or a required high-risk `make pre-pr` with a narrower gate.
+- Title.
- For focused verification, state why the selected tier is sufficient and list the scope-specific commands in the PR body.
+- Complete PR body.
- If `make` is unavailable, use the equivalent commands from `.config/make/`.
+- Verification commands and results.
- Add scope-specific verification commands when the changed area needs more than the baseline.
+- Risks or `N/A`.
 - If required checks fail, stop and return `BLOCKED`.
-4. Draft PR metadata
+Immediately before the GitHub write, repeat only the five preflight checks above
- Write the PR title in English using Conventional Commits and keep it within 72 characters.
+against the final head.
 - If a generic PR workflow suggests a different title format, ignore it and follow the repository rule instead.
 - In RustFS, do not use tool-specific prefixes such as `[codex]` when the repository requires Conventional Commits.
 - Keep the PR body in English.
 - Use the exact section headings from `.github/pull_request_template.md`.
 - Fill non-applicable sections with `N/A`.
 - Include verification commands in the PR description.
 - Do not include local filesystem paths in the PR body unless the user explicitly asks for them.
 - Prefer repo-relative paths, command names, and concise summaries over machine-specific paths such as `/Users/...`.
 5. Prepare reviewer context
 - Summarize why the change exists.
 - Summarize what was verified.
 - Call out risks, rollout notes, config impact, and rollback notes when applicable.
 - Mention assumptions or missing context instead of guessing.
 6. Prepare CLI-safe output
 - When proposing `gh pr create` or `gh pr edit`, use `--body-file`, never inline `--body` for multiline markdown.
 - Return a ready-to-save PR body plus a short title.
 - If not ready, return blockers first and list the minimum steps needed to unblock.
 ## Output format
 ### Status
 - `READY` or `BLOCKED`
 ### Title
 - `<type>(<scope>): <summary>`
 ### PR Body
 - Reproduce the repository template headings exactly.
 - Fill every section.
 - Omit local absolute paths unless explicitly required.
 ### Verification
 - List each command run.
 - State pass/fail.
 ### Risks
 - List breaking changes, config changes, migration impact, or `N/A`.
 ## Blocker rules
 - Return `BLOCKED` if the checks required by the `AGENTS.md` validation tier have not passed.
 - Return `BLOCKED` if a documentation-only, agent-instruction-only, or local developer-tooling-only change lacks focused verification for the changed surface.
 - Return `BLOCKED` if the diff contains unrelated changes that are not acknowledged.
 - Return `BLOCKED` if required template sections are missing.
 - Return `BLOCKED` if the title/body is not in English.
 - Return `BLOCKED` if the title does not follow the repository's Conventional Commit rule.
 - Return `BLOCKED` if the diff introduces string literals that should use existing constants but did not.
 - Return `BLOCKED` for production-code growth only when the review identifies a duplicated or superseded implementation, or supplies a concrete smaller design with equivalent semantics. Fewer lines alone are not evidence.
 ## Reference
 - Use [pr-readiness-checklist.md](references/pr-readiness-checklist.md) for a short final pass before opening or editing the PR.
@@ -1,4 +1,4 @@
 interface:
  display_name: "PR Creation Checker"
  short_description: "Draft RustFS-ready PRs with checks, template, and blockers."
-  default_prompt: "Inspect a branch or diff, verify required PR checks, and produce a compliant English PR title/body plus blockers or readiness status."
+  default_prompt: "Use $pr-creation-checker for final PR preflight and compliant English title/body metadata."
@@ -1,16 +0,0 @@
 # PR Readiness Checklist
 - Confirm the branch is based on current `main`.
 - Confirm the diff matches the stated scope.
 - Confirm no secrets, logs, temp files, or unrelated refactors are included.
 - Confirm the checks required by the `AGENTS.md` validation tier passed.
 - For focused verification, confirm it covered the changed surface and the PR body explains why the selected tier is sufficient.
 - Confirm extra verification commands are listed for risky changes.
 - Confirm the PR title uses Conventional Commits and stays within 72 characters.
 - Confirm the PR title does not use tool-specific prefixes such as `[codex]`.
 - Confirm the PR body is in English.
 - Confirm the PR body keeps the exact headings from `.github/pull_request_template.md`.
 - Confirm non-applicable sections are filled with `N/A`.
 - Confirm the PR body does not include local absolute paths unless explicitly required.
 - Confirm multiline GitHub CLI commands use `--body-file`.
 - Confirm new hardcoded string literals were not introduced for values already represented by existing constants/enums (including protocol labels, error identifiers, headers, and metric names), or record a justified exception.
@@ -1,11 +1,12 @@
 ---
 name: rust-code-quality
-description: Enforce Rust-specific code quality rules on every Rust change. Use before merge to catch unwrap abuse, silent truncation, unnecessary cloning, lock ordering violations, recursion risks, and error type anti-patterns.
+description: Run a focused Rust quality review when the user requests one, when reviewing a Rust PR/commit, or when another selected review workflow delegates Rust-specific checks. Do not auto-load for every implementation edit.
 ---
 # Rust Code Quality Gate
-Use this skill on every Rust code change to enforce quality rules that `cargo clippy` does not catch.
+Use this skill for a dedicated Rust review to cover rules that `cargo clippy`
 does not catch.
 ## Quick Start
@@ -45,7 +46,7 @@ rg -n 'unwrap_or_default\(\)|unwrap_or\(' <changed-files>
 ## Manual Review Checklist
-For every Rust code change, verify:
+For the Rust diff under review, verify:
 ### Error Handling
 - [ ] Every production `unwrap()` or `expect()` is infallible by type or a checked invariant; explain only non-obvious invariants, using an existing type, a useful `expect` message, or a concise comment
@@ -1,107 +1,34 @@
 ---
 name: rustfs-logging-governance
-description: Standardize and review RustFS logging with structured `tracing` events, lower noise on hot paths, preserve security-sensitive diagnostics, and extend guardrails to prevent legacy logging patterns from returning. Use whenever a change adds or edits any `tracing` macro call (`error!`/`warn!`/`info!`/`debug!`/`trace!`/`#[instrument]`) — including a single log line added in passing while fixing unrelated logic, which is how most new log sites enter the repo — and when reviewing RustFS logs, startup/config diagnostics, cloud metadata logs, request validation logs, or `scripts/check_logging_guardrails.sh`.
+description: Add or review RustFS `tracing` events with the repository field shape, level policy, privacy boundaries, and guardrails. Use when a change adds or edits a tracing macro/instrumentation site or the logging guardrail script.
 ---
 # RustFS Logging Governance
-Use this skill when RustFS logging needs to be added, cleaned up, reviewed, or protected against regressions.
+Apply this skill only to changed logging sites; do not turn a local log edit into
 a broad logging cleanup.
-## Quick Start
+## Workflow
-1. Identify the files whose logs are changing.
+1. Read the changed function/module context and classify the site as lifecycle,
-2. Scan current `tracing` or `log` macros before editing.
+   request/hot path, fallback, external fetch, or summary.
-3. Convert sentence-style logs to short event-style logs.
+2. Match neighboring structured events and reuse existing `EVENT_*`,
-4. Demote hot-path success logs unless operators truly need them at `info`.
+   `LOG_COMPONENT_*`, and `LOG_SUBSYSTEM_*` constants.
-5. Preserve failure, fallback, and security-relevant diagnostics.
+3. Put stable fields first (`event`, `component`, `subsystem`, `state`/`result`,
-6. Update `scripts/check_logging_guardrails.sh` when a broad cleanup removes a legacy pattern class.
+   then context) and a short label last.
-7. Validate with formatting, targeted checks/tests, and the logging guardrail script.
+4. Select the level by operational meaning:
   - `error`: behavior/security-affecting failure;
   - `warn`: degraded/fallback/operator-actionable state;
   - `info`: low-frequency lifecycle/mode change;
   - `debug`: targeted diagnostics;
   - `trace`: repetitive request/object/shard success paths.
 5. Never log secrets, tokens, auth headers, credential payloads, raw
   attacker-controlled bodies, or merged config dumps. Error strings and
   `Debug` output are log surfaces too.
 6. Prefer one aggregate summary over inventories or startup banners.
 7. Run `./scripts/check_logging_guardrails.sh` and the checks selected by root
   `AGENTS.md`.
-## Core Workflow
+Read [logging-governance.md](references/logging-governance.md) only for a broad
-
+logging audit, event-model migration, or guardrail expansion. Ordinary single-
-### 1. Scope the logging surface
+site edits do not require the full workspace scope map.
 - Read the changed module in full before touching log lines.
 - Classify the log site:
  - lifecycle/startup
  - request or validation path
  - background loop or hot path
  - fallback/degraded behavior
  - cloud metadata or external fetch path
  - metrics/config summary
 - Do not rewrite business logic to make logging easier.
 ### 2. Use the RustFS event shape
 - Prefer fields first, message second.
 - Use short labels, not prose paragraphs.
 - Default field shape:
  - `event`
  - `component`
  - `subsystem`
  - `state` or `result`
  - key context fields
 - Reuse stable field names and avoid inventing near-duplicates.
 See `references/logging-governance.md` for the event model, level policy, and anti-pattern list.
 ### 3. Choose the right level
 - `error`: operation failure that affects behavior or security guarantees.
 - `warn`: degraded path, fallback, suspicious input, or operator-actionable misconfiguration.
 - `info`: low-frequency lifecycle or mode selection.
 - `debug`: targeted diagnostics and low-volume detail.
 - `trace`: hot-path and repetitive success-path events.
 When in doubt, lower the verbosity of normal success paths and keep structured detail in fields.
 ### 4. Preserve security and privacy boundaries
 - Do not log secrets, tokens, auth headers, raw credential payloads, or merged config dumps.
 - Avoid logging raw forwarded headers or full trusted network inventories above `debug`.
 - Keep warning/error logs useful without echoing attacker-controlled payloads unnecessarily.
 ### 5. Keep summaries aggregated
 - Replace multi-line startup banners or checklist logs with one structured event.
 - If metrics already express a concept, avoid duplicating it with many `info!` lines.
 - Prefer counts, modes, and sources over inventories unless debug detail is truly needed.
 ### 6. Update guardrails when needed
 - Broad logging cleanup should usually extend `scripts/check_logging_guardrails.sh`.
 - Add forbidden patterns only for styles the repo has intentionally retired:
  - sentence-style lifecycle logs
  - noisy hot-path `info!`
  - checklist-style summary logs
  - legacy fallback wording that has been replaced by structured fields
 - Keep guardrails concrete and grep-friendly.
 ### 7. Validate manually
 Use the smallest relevant set:
 ```bash
 cargo fmt --all --check
 ./scripts/check_logging_guardrails.sh
 cargo check -p <affected-crate>
 cargo test -p <affected-crate>
 ```
 For broader Rust changes, add:
 ```bash
 ./scripts/check_unsafe_code_allowances.sh
 ./scripts/check_architecture_migration_rules.sh
 cargo clippy -p <affected-crates> --all-targets -- -D warnings
 ```
 ## RustFS-Specific Notes
 - The durable RustFS logging direction is `event + component + subsystem + state/result + key context fields`.
 - `crates/concurrency` and `crates/trusted-proxies` are examples of this style for lifecycle, fallback, and cloud metadata logs.
 - `scripts/check_logging_guardrails.sh` is the enforcement point for preventing removed log styles from returning.
 ## References
 - Read `references/logging-governance.md` when you need the detailed field set, anti-pattern examples, or guardrail update checklist.
@@ -1,285 +1,62 @@
-# RustFS Logging Governance Reference
+# Logging Audit and Migration Reference
-## Workspace Scope Map
+Read this reference only for a broad logging audit, an event-model migration,
 or a change to `scripts/check_logging_guardrails.sh`. Use `Cargo.toml` for the
 current workspace/crate list instead of maintaining one here.
-Use `Cargo.toml` `[workspace].members` as the source of truth for crate membership. When doing a broad logging sweep, classify crates by operational role so logs stay consistent within each role.
+## Audit by Operational Role
-### Core Server And Request Handling
+- Server/protocol/admin: lifecycle, authorization failures, request boundaries,
  and degraded subsystems; avoid normal request success at `info`.
 - Storage/heal/scanner/capacity: integrity failures and aggregate lifecycle;
  avoid per-object, per-shard, and folder iteration noise.
 - IAM/policy/credentials/KMS/crypto: safe identifiers and enforcement results;
  never emit secrets, claims, payloads, or expected authenticators.
 - Notify/audit/targets: target lifecycle and batch/backpressure summaries; avoid
  per-event success logs.
 - Locking/concurrency/I/O foundations: contention anomalies and state changes;
  prefer metrics for high-frequency worker/permit signals.
 - Shared type/schema crates: log at the operational caller boundary unless the
  crate itself owns the failure context.
- `rustfs`
+## Event Shape
  - Role: top-level server, startup, auth, admin wiring, S3 request handling.
  - Logging focus: startup lifecycle, config summaries, authn/authz failures, protocol entrypoints, degraded subsystems.
 - `crates/protocols`
  - Role: protocol integrations such as FTP, SFTP, WebDAV, and related server-side protocol layers.
  - Logging focus: listener lifecycle, per-protocol enablement/disablement, request bridge failures.
 - `crates/madmin`
  - Role: admin API contracts and management interfaces.
  - Logging focus: admin action boundaries, validation failures, compatibility warnings.
 - `crates/trusted-proxies`
  - Role: forwarded IP trust, proxy chain validation, cloud metadata sources.
  - Logging focus: direct/trusted/fallback decisions, degraded metadata fetches, aggregated config summaries.
 - `crates/keystone`
  - Role: Keystone auth integration.
  - Logging focus: integration enablement, upstream auth failures, config safety without credential leakage.
-### Storage, Healing, And Data Plane
+Prefer stable fields in this order when available:
- `crates/ecstore`
+1. `event`
-  - Role: erasure-coded storage implementation and peer/store initialization.
+2. `component`
-  - Logging focus: disk/peer lifecycle, storage fallback, object I/O failures, avoid per-object noise.
+3. `subsystem`
- `crates/heal`
+4. `state` or `result`
-  - Role: healing orchestration and repair workflows.
+5. stable context such as mode, duration, reason, counts, safe identifiers, or
-  - Logging focus: scheduler lifecycle, repair decisions, backlog or skipped work summaries, avoid repetitive task spam at `info`.
+   capacity/permit values
- `crates/scanner`
+6. short message label
  - Role: data integrity scanning and health monitoring.
  - Logging focus: scan lifecycle, compaction/deep-heal transitions, lag/backlog, noisy folder iteration should stay at `debug/trace`.
 - `crates/object-capacity`
  - Role: capacity scan and refresh core.
  - Logging focus: refresh lifecycle, degraded capacity sources, aggregate stats rather than per-object chatter.
 - `crates/filemeta`
  - Role: file metadata parsing and helpers.
  - Logging focus: parse failures, schema/format mismatch, avoid dumping raw metadata payloads.
 - `crates/storage-api`
  - Role: storage contracts and shared data plane interfaces.
  - Logging focus: contract mismatch and boundary diagnostics, usually low-volume.
 - `crates/checksums`
  - Role: checksum helpers and validation.
  - Logging focus: integrity failures and compatibility mismatches, not per-chunk success logs.
 - `crates/zip`
  - Role: ZIP handling and compression helpers.
  - Logging focus: parse/extract failures, archive path safety issues, avoid verbose file-by-file success logs.
-### Security, Identity, And Policy
+Reuse the module's constants and neighboring field names. Do not create aliases
 for the same concept.
- `crates/iam`
+## Patterns to Retire
  - Role: identity and access management.
  - Logging focus: authz decision boundaries, imported payload safety, do not leak principals, secrets, or claims.
 - `crates/policy`
  - Role: policy modeling and evaluation.
  - Logging focus: deny/allow decision context, parser/validation failures, no raw secret-bearing request dumps.
 - `crates/credentials`
  - Role: credential handling.
  - Logging focus: never log secrets or tokens; only safe identifiers and redacted states.
 - `crates/kms`
  - Role: key management service integration.
  - Logging focus: init/health/fallback, key-source availability, never log key material.
 - `crates/crypto`
  - Role: cryptographic helpers and security primitives.
  - Logging focus: only algorithm or mode state, not plaintext, ciphertext, or secret-derived material.
 - `crates/security-governance`
  - Role: security governance contracts.
  - Logging focus: policy/state transitions and enforcement diagnostics.
 - `crates/signer`
  - Role: request signing helpers.
  - Logging focus: signature validation failures without expected-signature leakage.
-### Notifications, Audit, And Targets
+- sentence-style lifecycle announcements;
 - startup banners and checklist lines;
 - repetitive success logs at `info`/`debug`;
 - raw inventories when an aggregate count is sufficient;
 - fallback prose with values embedded in the message;
 - `?value`/`Debug` output for credential-bearing or attacker-controlled data;
 - logging a parse input when the malformed input may itself be a secret.
- `crates/notify`
+## Guardrail Changes
  - Role: notification dispatch, runtime facade, notifier implementations.
  - Logging focus: target lifecycle, dispatch summaries, stream lag/backpressure, avoid per-event success spam.
 - `crates/audit`
  - Role: audit target fan-out and audit pipeline management.
  - Logging focus: pipeline lifecycle, target availability, batch dispatch summaries, avoid noisy "started successfully" prose.
 - `crates/targets`
  - Role: target-specific configuration and utilities used by fan-out style systems.
  - Logging focus: target selection, config validation, per-target degraded state.
 - `crates/s3-types`
  - Role: S3 event and type definitions.
  - Logging focus: usually minimal; keep logging at integration boundaries rather than low-level type crates.
 - `crates/s3-ops`
  - Role: S3 operation definitions and mapping.
  - Logging focus: mapping/contract failures, unsupported combinations, not normal-path request spam.
-### Concurrency, Locking, And Runtime Foundations
+When expanding `scripts/check_logging_guardrails.sh`:
- `crates/concurrency`
+1. Add only files/patterns intentionally migrated in the same change.
-  - Role: timeout, locking, backpressure, and I/O scheduling facade.
+2. Keep patterns concrete and grep-friendly.
-  - Logging focus: lifecycle transitions and degraded states, not high-frequency worker/permit churn at `info`.
+3. Do not encode a style that remains valid elsewhere as a global ban.
- `crates/lock`
+4. Run the guardrail script and the root validation tier.
-  - Role: distributed locking implementation.
+5. Treat the script as a floor; manually verify level, field shape, and privacy.
  - Logging focus: lock lifecycle, contention anomalies, lock ordering or timeout diagnostics.
 - `crates/tls-runtime`
  - Role: shared TLS runtime foundation.
  - Logging focus: certificate lifecycle, reload/fallback, validation failures without sensitive dumps.
 - `crates/obs`
  - Role: observability helpers.
  - Logging focus: this crate shapes other crates' telemetry conventions; avoid recursive or redundant summaries.
 - `crates/io-core`
  - Role: zero-copy I/O core primitives.
  - Logging focus: keep very sparse; prefer metrics unless failures are actionable.
 - `crates/io-metrics`
  - Role: I/O metrics collection.
  - Logging focus: typically minimal; metrics should carry the hot-path signal.
 - `crates/rio`
  - Role: Rust I/O utility layer.
  - Logging focus: compatibility or runtime boundary failures, not fast-path internals.
 - `crates/rio-v2`
  - Role: next-generation I/O compatibility layer.
  - Logging focus: migration/feature-mode differences and degraded fallback between I/O paths.
 - `crates/utils`
  - Role: shared helpers.
  - Logging focus: usually avoid direct logging in generic helpers unless the helper is itself an operational boundary.
 - `crates/common`
  - Role: shared data structures and helpers.
  - Logging focus: same principle as `utils`; prefer callers to log context-rich events.
 - `crates/config`
  - Role: configuration management.
  - Logging focus: config source, fallback, validation, and summary aggregation; avoid dumping merged configs.
 - `crates/data-usage`
  - Role: shared data usage models and algorithms.
  - Logging focus: refresh lifecycle, summary stats, and degraded reads.
-### Schema, Contracts, And API Support
+Useful search seeds for the changed surface:
 - `crates/protos`
  - Role: protobuf definitions.
  - Logging focus: usually none inside the crate; emit logs at decode/use boundaries.
 - `crates/extension-schema`
  - Role: extension schema contracts.
  - Logging focus: schema validation and compatibility mismatches.
 - `crates/s3select-api`
  - Role: S3 Select API interfaces.
  - Logging focus: request validation and unsupported feature boundaries.
 - `crates/s3select-query`
  - Role: S3 Select query engine.
  - Logging focus: query parse/planning/execution failures, avoid row-level spam.
 - `crates/protocols`
  - Role: non-S3 protocol support.
  - Logging focus: see core server section; keep per-request verbosity below `info`.
 ### Testing And Non-Production Crates
 - `crates/e2e_test`
  - Role: end-to-end tests.
  - Logging focus: test clarity matters more than production governance, but avoid copying test-only logging style into production crates.
 ## Current Guardrail Coverage Map
 `scripts/check_logging_guardrails.sh` currently enforces retired patterns in these high-signal areas:
 - `rustfs/src/main.rs`
 - `rustfs/src/startup_iam.rs`
 - `rustfs/src/auth.rs`
 - `rustfs/src/protocols/client.rs`
 - `crates/audit/src/pipeline.rs`
 - `crates/audit/src/system.rs`
 - `crates/audit/src/global.rs`
 - `crates/notify/src/config_manager.rs`
 - `crates/notify/src/runtime_facade.rs`
 - `crates/notify/src/notifier.rs`
 - `crates/ecstore/src/store/peer.rs`
 - `crates/ecstore/src/store/init.rs`
 - `crates/ecstore/src/tier/tier.rs`
 - `crates/concurrency/src/workers.rs`
 - `crates/concurrency/src/manager.rs`
 - `crates/concurrency/src/lock.rs`
 - `crates/concurrency/src/deadlock.rs`
 - `crates/trusted-proxies/src/global.rs`
 - `crates/trusted-proxies/src/config/loader.rs`
 - `crates/trusted-proxies/src/proxy/metrics.rs`
 - `crates/trusted-proxies/src/proxy/validator.rs`
 - `crates/trusted-proxies/src/proxy/chain.rs`
 - `crates/trusted-proxies/src/middleware/service.rs`
 - `crates/trusted-proxies/src/cloud/detector.rs`
 - `crates/trusted-proxies/src/cloud/ranges.rs`
 - `crates/trusted-proxies/src/cloud/metadata/aws.rs`
 - `crates/trusted-proxies/src/cloud/metadata/azure.rs`
 - `crates/trusted-proxies/src/cloud/metadata/gcp.rs`
 When expanding coverage, prefer crates with:
 - repeated sentence-style lifecycle logs
 - high-frequency success-path `info!`
 - startup/config checklist banners
 - security-sensitive fallback wording
 - external fetch/retry/fallback flows
 That typically means the next broad candidates are `rustfs`, `crates/notify`, `crates/audit`, `crates/targets`, `crates/heal`, and `crates/scanner`.
 ## Event Model
 Prefer this structure when the fields are available:
 - `event`
 - `component`
 - `subsystem`
 - `state` or `result`
 - stable context fields such as:
  - `enabled`
  - `implementation`
  - `validation_mode`
  - `peer_ip`
  - `client_ip`
  - `proxy_hops`
  - `duration_ms`
  - `fallback`
  - `reason`
  - `range_count`
  - `hold_time_ms`
  - `available_slots`
  - `total_slots`
  - `permits_in_use`
 ## Level Policy
 - `error`: the operation fails and callers or security guarantees are affected.
 - `warn`: a degraded path, fallback, suspicious request, or operator-actionable config issue occurs.
 - `info`: a low-frequency lifecycle or mode transition occurs.
 - `debug`: useful diagnostics exist but normal operators do not need them all the time.
 - `trace`: hot-path and repetitive success-path details occur.
 ## Preferred Patterns
 - Use a short message label:
  - `"trusted proxy validation failed"`
  - `"concurrency manager state changed"`
  - `"trusted proxy cloud metadata loaded"`
 - Put key meaning into fields, not only the message text.
 - Aggregate config or metrics summaries into one log event.
 ## Retired Patterns
 These should usually be removed or replaced:
 - Sentence-style lifecycle logs:
  - `info!("Concurrency manager stopped")`
  - `info!("Trusted Proxies module initialized")`
 - Checklist or banner logs:
  - `info!("=== Application Configuration ===")`
  - `info!("Available metrics:")`
 - Hot-path noise:
  - `info!("worker take, {}", *available)`
  - `debug!("Proxy validation successful in {:?}", duration)`
 - Legacy fallback prose:
  - `"Request from private network but not trusted: ..."`
  - `"Cloud metadata fetching is disabled"`
 ## Guardrail Update Checklist
 When extending `scripts/check_logging_guardrails.sh`:
 1. Add the touched files to `checked_files`.
 2. Add only legacy patterns that have been intentionally retired.
 3. Keep patterns literal and grep-friendly.
 4. Run the guardrail script after changes.
 5. Avoid adding patterns for logs that are still valid elsewhere in the repo.
 ## Validation Checklist
 For logging-only changes:
 ```bash
-cargo fmt --all --check
+rg -n 'error!|warn!|info!|debug!|trace!|#\[instrument' <changed-paths>
-./scripts/check_logging_guardrails.sh
+rg -n '\?[^,)]|secret|token|credential|authorization|merged_config' <changed-paths>
 cargo check -p <affected-crate>
 cargo test -p <affected-crate>
 ```
 For broader Rust changes:
 ```bash
 ./scripts/check_unsafe_code_allowances.sh
 ./scripts/check_architecture_migration_rules.sh
 cargo clippy -p <affected-crates> --all-targets -- -D warnings
 ```
@@ -1,6 +1,6 @@
 ---
 name: rustfs-release-publish
-description: "End-to-end RustFS release pipeline: first publish any merged-but-unreleased rustfs/console changes and wait for its latest Release asset, then bump RustFS version files on main directly to the final target, publish a visible GitHub prerelease from a preview tag without updating latest channels, validate it, and publish the final tag on the SAME commit. Use whenever the user wants to release/publish a RustFS version (发版/发布)."
+description: "Run the end-to-end RustFS console gate, version bump, preview validation, and final-tag publication pipeline. Use only when the user explicitly asks to release or publish a RustFS version (发版/发布)."
 ---
 # RustFS Release Publish (preview-validated pipeline)
@@ -1,6 +1,6 @@
 ---
 name: rustfs-release-version-bump
-description: "Publish a RustFS alpha/beta/stable release with an auditable flow: confirm target version and scope, update workspace and release assets (including strict rustfs.spec changelog identity/date/version format), run required verification, and finish with commit, push, and GitHub PR creation."
+description: "Prepare the version-file and release-asset bump for an exact RustFS alpha/beta/stable target, with verification and optional commit/push/PR delivery. Use for an explicit version bump or when invoked by the release-publish workflow."
 ---
 # RustFS Release Version Bump
@@ -81,10 +81,7 @@ Only drop a file when the current repository release process clearly no longer r
 4. Verify before shipping
 - Run:
 - `cargo fmt --all`
 - `cargo fmt --all --check`
 - `make pre-commit`
 - If verification passes, run `cargo clean`.
 - If `make pre-commit` fails, return `BLOCKED` with root cause and do not silently widen scope to fix unrelated issues unless user asks.
 5. Commit strategy
@@ -109,10 +106,7 @@ Only drop a file when the current repository release process clearly no longer r
 - `git diff --name-only origin/main...HEAD`
 - `git diff --stat origin/main...HEAD`
 - `rg -n "<old_version>|<new_version>" Cargo.toml Cargo.lock README.md README_ZH.md flake.nix helm/rustfs/Chart.yaml rustfs.spec`
 - `cargo fmt --all`
 - `cargo fmt --all --check`
 - `make pre-commit`
 - `cargo clean`
 ## Output contract
@@ -1,4 +1,4 @@
 interface:
  display_name: "RustFS Release Bump"
  short_description: "Prepare RustFS release branches like PR #2957."
-  default_prompt: "Use $rustfs-release-version-bump to prepare a RustFS release version, ask about any unclear version policy, and finish the commit/push/PR flow."
+  default_prompt: "Use $rustfs-release-version-bump to prepare and verify an exact RustFS release-version bump."
@@ -1,170 +1,40 @@
 ---
 name: security-advisory-lessons
-description: Apply RustFS security lessons distilled from repository GitHub Security Advisories. Use when making or reviewing RustFS code changes, doing security checks, handling PR review for auth/authz, IAM, storage, RPC, logging, CORS, console/browser, encryption, policy, or endpoint changes, and when deciding which security regression tests are required.
+description: Perform a dedicated RustFS security/advisory review for authn/authz, IAM, RPC trust, paths, secrets, browser isolation, encryption, Object Lock, or other security boundaries. Use only when the user requests a security/advisory review or an adversarial review explicitly escalates to the full advisory map; do not auto-load solely because code touches a sensitive path.
 ---
 # RustFS Security Advisory Lessons
-Use this skill as a RustFS-specific security lens before changing or approving code. For the distilled advisory lessons and review patterns, read [advisory-patterns.md](references/advisory-patterns.md).
+Use this skill as the deep security lens. For a normal adversarial review with a
 matched security surface, the concise security reference under
 `adversarial-validation` is sufficient.
-When currentness matters, fetch the live advisory inventory instead of relying on this skill as a status mirror:
+## Workflow
 1. Freeze the exact diff/head and identify the changed trust boundaries.
 2. Read [advisory-patterns.md](references/advisory-patterns.md), then apply only
   the matching sections. Useful headings are
   auth/admin, IAM/STS/OIDC, policy/plugins, S3/copy/multipart, protocols, paths,
   secrets/logging/RPC, browser/CORS/proxy, SSE, Object Lock, and serde.
 3. Trace unauthenticated, low-privilege, wrong-action/owner/bucket, malformed,
   and default-config cases. Security decisions must fail closed.
 4. Require a focused negative regression test for the bypass/exploit form, not
   only the intended success path. State residual risk when a test is impractical.
 5. Report proven vulnerabilities separately from defense-in-depth hardening.
 When advisory currentness matters, fetch the live inventory instead of treating
 the reference as a status mirror:
 ```bash
 gh api repos/rustfs/rustfs/security-advisories --paginate \
  --jq '.[] | {ghsa_id,state,severity,summary,updated_at}'
 ```
-Fetch full advisory details only when the live summary suggests a new or changed lesson:
+Fetch an individual advisory only when the live summary indicates a new or
 changed lesson.
-```bash
+## Finding Standard
 gh api repos/rustfs/rustfs/security-advisories/<GHSA_ID>
 ```
-For the full pattern map, read [advisory-patterns.md](references/advisory-patterns.md).
+Each finding includes severity, `file:line`, attacker prerequisites, concrete
-
+input/path, impact, smallest safe fix, and a regression check. Do not exaggerate
-## Workflow
+unauthenticated impact when the actual issue requires authenticated low privilege.
 ### 1. Scope the change
 - Identify touched routes, protocol frontends, handlers, storage paths, credentials, logs, browser surfaces, CI/release code, and policy checks.
 - Treat these paths as security-sensitive by default: `rustfs/src/admin/`, `rustfs/src/storage/`, `rustfs/src/auth.rs`, `rustfs/src/server/layer.rs`, `crates/iam/`, `crates/policy/`, `crates/credentials/`, `crates/ecstore/src/rpc/`, `crates/protocols/`, `crates/rio/`, OIDC/STS federation code, and console preview/auth code.
 ### 2. Map to advisory classes
 - Read [advisory-patterns.md](references/advisory-patterns.md) for matching GHSA lessons.
 - Do not rely on advisory titles alone. Confirm whether the issue is authentication, authorization, input validation, storage invariant, browser isolation, logging, or operational hardening.
 ### 3. Verify fail-closed behavior
 - Check that unauthenticated, wrong-permission, cross-user, cross-bucket, malformed-input, and default-config cases fail explicitly.
 - Prefer exact action/permission checks over broad helper calls or inferred ownership.
 - Confirm lower storage/RPC layers do not bypass checks done in upper layers.
 ### 4. Require regression evidence
 - For behavior changes, add focused negative tests that reproduce the advisory class.
 - For sensitive fixes, include tests for the bypass form, not only the happy path.
 - If a test is impractical, explain the residual risk and provide a manual verification command.
 ### 5. Report clearly
 - Lead with concrete findings and file/line evidence.
 - Separate proven vulnerabilities from hardening risks.
 - Avoid exaggerating unauthenticated impact when the code actually rejects unauthenticated requests but allows a low-privileged authenticated bypass.
 ## Advisory-Derived Guardrails
 ### Auth and admin authorization
 - Every admin or diagnostic route needs an explicit authn and authz story. Route registration, router whitelist, and handler-level authorization must agree.
 - Match the admin action to the operation exactly. Copy-paste action constants are a known RustFS vulnerability class.
 - Avoid authentication-only helpers for state-changing admin APIs; use `validate_admin_request` or the established equivalent with the right `AdminAction`.
 - Read-only admin APIs such as metrics, server info, and diagnostics still require admin authorization; checking only that credentials exist is not enough.
 - Replication admin reads can expose remote target credentials; list/get target endpoints require replication/admin authorization and must not return secrets to low-privilege callers.
 - Do not assume admin-action `Resource` scoping constrains blast radius unless the policy engine actually enforces resources for that action.
 ### IAM and service accounts
 - Treat imported IAM payload fields as attacker-controlled: `parent`, `claims`, `accessKey`, `secretKey`, status, policy names, and groups.
 - For service account create/update/import, prove parent ownership or root/admin authority before writing credentials or claims; an action permission alone must not allow choosing root or another user as `target_user`.
 - Treat IAM export packages as credential disclosure surfaces; never include plaintext user or service-account secret keys unless the caller is allowed to recover those secrets and the export format is intentionally sealed.
 - Do not let `deny_only` or "no explicit deny" become an allow decision that skips required allow checks.
 - Test cross-user list/update/import flows with wrong, correct, self, parent, and root identities.
 ### STS, OIDC, and federation flows
 - Every STS endpoint must have an explicit authentication story: SigV4 where required, OIDC token verification for web identity, and role/session policy validation before issuing credentials.
 - For web identity, the JWT is the credential; exemption from SigV4 is not itself an authentication bypass. Treat pre-verification claims only as untrusted routing hints, bound token size, normalize public failures, rate-limit discovery, and issue credentials only after signature, issuer, audience, and expiration checks.
 - JWT session tokens must be signed and verified by a trusted issuer/key path, not by service-account-controlled material or a reused root secret.
 - JWT verification must enforce required claims and expiration for every bearer token path; "allow missing exp" is never acceptable for user-presented credentials.
 - Public OIDC bootstrap and callback routes must treat `Host`, `X-Forwarded-Proto`, redirect targets, `state`, and callback parameters as untrusted; credential-bearing redirects require a configured, allowlisted origin.
 - OIDC discovery and validation URLs are SSRF sinks. Resolve and classify hostnames at connection time, reject rebinding to loopback/private/link-local ranges, and do not rely on literal string checks.
 ### IAM policy conditions and plugins
 - Treat request headers as attacker-controlled even after SigV4; callers sign their own spoofed headers. Do not merge them into server-derived condition keys such as identity, groups, version ID, signature version, JWT, or LDAP claims.
 - Keep the condition-key namespace explicit. Reserved server-derived keys must reject or ignore colliding headers, while intentional request-header keys such as `s3:x-amz-*` remain available.
 - Quantified IAM condition tests need partially overlapping multi-value sets. Fully contained and fully disjoint sets cannot distinguish `ForAllValues` from `ForAnyValue` bugs.
 - External policy plugins must receive the same security context as built-in policy evaluation. If OPA or another plugin depends on existing object tags, load and pass `ExistingObjectTag/*` before the plugin decision.
 ### S3 object actions, copy, multipart, and presigned POST
 - Version-aware object requests need version-aware actions. Explicit `versionId` reads and copy sources must authorize `s3:GetObjectVersion`, not only `s3:GetObject`.
 - Multipart copy must enforce source `GetObject` and destination `PutObject` semantics equivalent to `CopyObject`, including copy-source and policy conditions.
 - Do not let `CreateMultipartUpload`, `UploadPartCopy`, `CompleteMultipartUpload`, or `AbortMultipartUpload` return success without authorization.
 - Fallbacks from version actions to non-version actions must still pass the same public-access-block, anonymous-deny, and post-authorization gates as a direct allow.
 - Presigned POST policies are server-side contracts. Enforce `content-length-range`, key prefix, exact metadata/content-type, and all signed policy conditions.
 ### Protocol frontends and IAM parity
 - FTP/FTPS, SFTP, gateway, and other protocol drivers must enforce IAM per operation before calling storage backends; authentication to a protocol listener is not authorization.
 - Match protocol commands to the same S3 actions as HTTP, such as `RETR` to `GetObject`, `SIZE`/`MDTM` to `HeadObject`, `MKD` to `CreateBucket`, and bucket probes to `ListBucket` or `HeadBucket`.
 - Review every handler in a protocol driver, not only the changed handler, because RustFS advisories show mixed guarded and unguarded siblings in the same driver.
 - Regression tests for protocol frontends should deny the shared authorization hook and prove the backend is not reached for the denied command.
 - Compare protocol secrets in constant time, normalize invalid-user and invalid-secret failures where practical, and add rate limiting before exposing password-style protocol endpoints.
 ### Paths, object keys, and filesystem access
 - Never join untrusted bucket/object/RPC path strings onto filesystem roots without normalization and boundary checks.
 - Reject or safely handle `..`, absolute paths, URL-encoded traversal, platform separators, empty components, and paths that canonicalize outside the intended root.
 - Validate both S3 object-key paths and internode/RPC disk paths; storage helpers can bypass S3 authorization if they trust already-parsed paths.
 - Archive auto-extract paths are object keys too. Validate tar/zip entry names before IAM checks and before storage writes, and prove cleaned paths cannot cross bucket or prefix boundaries.
 ### Secrets, default credentials, and crypto
 - Do not ship hard-coded shared tokens, HMAC secrets, private keys, or production test keys.
 - Defaults for root credentials and internode/RPC auth must fail closed for network-reachable deployments or generate per-install random secrets; warnings alone are not a security boundary.
 - Keep cryptographic roles separated: root S3 credentials, RPC HMAC keys, and STS/JWT signing keys must not be reused or deterministically derived from each other.
 - License or token validation must use signatures with embedded public/verifying keys only; do not use private-key decryption as authenticity.
 - Plan key rotation and key IDs when removing exposed keys.
 ### Logging and debug output
 - Logs must never include access keys beyond safe identifiers, secret keys, session tokens, JWT claims, HMAC secrets, expected signatures, license secrets, or raw response bodies containing credentials.
 - Treat `Debug` implementations, `?value` tracing, merged config dumps, and dependency-level HTTP body logging as leak surfaces.
 - Error and panic messages are log content: they propagate through `?` and get printed by `error!`/startup logging far from where they were constructed. Never interpolate a raw config or credential value into an error string.
 - A value that fails secret-format parsing is usually the secret itself (e.g. a bare base64 key missing its `<name>:` prefix), so a parse-failure hint must name the env var or file and the expected format, never echo the input. Redacting `Debug` impls does not cover this channel.
 - Add log-capture tests or targeted unit tests for redaction wrappers when changing credential structs or response bodies.
 ### RPC, parsing, and panic safety
 - Treat all RPC payload bytes as attacker-controlled. Replace `unwrap`, `expect`, and panic-prone deserialization with typed errors.
 - Malformed request tests should cover empty bytes, truncated MessagePack/protobuf, invalid enum values, stale timestamps, and invalid signatures.
 - RPC authentication must be independently strong; do not depend on S3 admin credentials unless the fallback is explicit and safe.
 - RPC signatures must bind the exact generated gRPC method path, timestamp, and request method. Service-prefix signatures must not authorize a different concrete NodeService call.
 ### Browser, CORS, and console surfaces
 - Do not reflect arbitrary `Origin` while also allowing credentials. Default CORS should be no CORS unless explicitly configured.
 - Do not render user-controlled object content in a same-origin iframe with console credentials available to JavaScript.
 - Prefer origin separation for object preview/download, `nosniff`, CSP, strict content-type handling, and avoiding durable credentials in `localStorage`.
 - Preview safety must be based on trusted content type and sandboxing, not object names or extensions such as `.pdf`.
 - Console license/version-like metadata endpoints should expose only coarse public data unless authenticated, especially subject names and expiration timestamps.
 ### Profiling, debug, and health endpoints
 - Profiling and debug endpoints are not health checks. They require admin auth, opt-in enablement, rate limiting, and safe responses.
 - Do not return absolute filesystem paths or other deployment layout in unauthenticated or low-privilege responses.
 - Ensure health endpoint allowlists cannot accidentally include expensive diagnostics.
 ### Trusted proxy and network identity
 - Only honor `X-Forwarded-For` or `X-Real-IP` when the request came from a configured trusted proxy.
 - Apply the same trusted-proxy rule to scheme and host derivation; direct clients must not control security-sensitive redirects through `Host`, `X-Forwarded-Host`, or `X-Forwarded-Proto`.
 - Direct clients must use the socket peer address for `aws:SourceIp` and policy condition evaluation.
 - Add tests for direct spoofed headers and trusted-proxy headers.
 ### SSE and storage invariants
 - Encryption metadata is not proof that bytes were encrypted on disk.
 - When touching reader/writer wrappers such as hashing, encryption, compression, or warp readers, verify wrapper order and inspect stored bytes in regression tests.
 - Avoid helper shortcuts that unwrap nested readers and accidentally bypass encryption or integrity layers.
 ### Object Lock and retention invariants
 - Object Lock state must fail closed when bucket metadata is unreadable, fabricated, or unparsable. Only a confirmed absence of Object Lock configuration may permit unprotected deletes or writes.
 - Do not collapse metadata read faults, missing persisted metadata, parse failures, and genuinely absent Object Lock config into one "not configured" result.
 - Retention enforcement must cover foreground deletes, batch deletes, force-delete helpers, default-retention materialization on PUT, lifecycle expiry, scanner sweeps, and all-versions expiry.
 ## Review Prompts
 Use these prompts while reviewing a diff:
 - Could a low-privileged authenticated user reach this path with the wrong action, parent, bucket, or source object?
 - Does a non-HTTP protocol path call the same authorization boundary as the S3 API before touching storage?
 - Does a public/default/empty config change security behavior from fail-closed to fail-open?
 - Is any attacker-controlled value later used as a path, policy condition, credential identity, log field, URL, Origin, or response body?
 - Does this response contain stored replication, remote target, or service credentials that need redaction or stricter authorization?
 - Does any error constructor or `format!` interpolate a variable that can hold secret material, including a config parse error that echoes the raw input?
 - Does an IAM export/import path expose or trust plaintext credential secrets beyond the caller's intended authority?
 - Can this STS/OIDC path issue credentials without SigV4, trusted issuer validation, allowlisted redirects, or trusted-proxy host/scheme handling?
 - Can a service-account or STS token omit `exp`, forge `sessionPolicy`, or use a principal-controlled key as signing authority?
 - Does this outbound validation path resolve attacker-supplied hostnames and reject private, loopback, link-local, and rebound addresses at the actual connection boundary?
 - Is an archive entry, object key, or policy resource normalized differently between authorization and storage?
 - Is the same operation implemented in multiple paths, such as `CopyObject` vs `UploadPartCopy`, and do all paths enforce the same security contract?
 - Does an explicit object version, fallback action, or plugin authorization path pass through the same action and post-authorization gates as the direct S3 path?
 - Can a caller-controlled header populate a condition key that should be derived only by the server?
 - Do condition tests include partially overlapping multi-value inputs for quantified operators?
 - Does unreadable bucket metadata make Object Lock or retention enforcement fail closed rather than disappear?
 - Does a preview or browser-surface fix preserve the original security invariant when adding alternate viewers or file-type detection?
 - Does the test prove the exploit form is denied, or only that the intended form still works?
@@ -1,4 +1,4 @@
 interface:
  display_name: "Security Advisory Lessons"
  short_description: "Apply advisory lessons in reviews."
-  default_prompt: "Review code changes against past RustFS security advisory lessons and report concrete risks, missing tests, and recommended fixes."
+  default_prompt: "Use $security-advisory-lessons for a dedicated RustFS security review grounded in past advisories."
@@ -1,402 +1,255 @@
-# RustFS Agent Instructions (Global)
+# RustFS Agent Instructions
-This root file keeps repository-wide rules only.
+This file contains repository-wide rules. Use the nearest subdirectory
-Use the nearest subdirectory `AGENTS.md` for path-specific guidance.
+`AGENTS.md` for path-specific invariants.
-## Rule Precedence
+## Precedence
 1. System/developer instructions.
-2. Current user/task instructions.
+2. The current user request.
-3. The nearest `AGENTS.md` in the current path.
+3. The nearest `AGENTS.md`.
-4. This file (global defaults).
+4. This file.
-If repo-level instructions conflict, follow the nearest file and keep behavior aligned with CI.
+## Operating Model
-## Execution Discipline
+- Inquiry, diagnosis, review, and planning tasks are read-only unless the user
-
+  explicitly requests changes.
- Read the relevant existing code, tests, and local guidance before changing behavior. For new helpers or test setup, that read includes `crates/utils`, `crates/common`, and the touched crate's own `test_util`/fixtures (see Reuse Before You Write).
+- For implementation, read the relevant code, tests, and local guidance, then
- State assumptions when they affect the implementation or verification path.
+  make the smallest change that satisfies the request.
- If a task has multiple plausible interpretations, list the options briefly and choose the narrowest reasonable path; ask when the ambiguity would make the change risky.
+- State assumptions only when they affect behavior or verification. Ask only
- For multi-step work, keep the plan minimal and tied to verifiable outcomes.
+  when a wrong assumption would materially change the result.
- Avoid redundant file reads, repeated commands, and unnecessary exploratory work once enough context is available.
+- Do not load every skill or inspect unrelated modules preemptively. Select a
- A good result is a minimal diff with clear assumptions, no over-engineering, and independent verification that survives Adversarial Validation (below).
+  skill only when its description directly matches the request or changed
  surface.
 - Avoid repeated reads and equivalent verification commands once enough
  evidence exists.
 ## Worktree and Disk Hygiene
- Unless the requester explicitly says otherwise, treat every new implementation task as isolated work: fetch the latest `origin/main`, confirm the requested change is not already present there, and create a dedicated feature branch and worktree from that exact upstream commit before editing. Do not implement new work directly in the primary checkout or reuse a worktree from another task.
+- Start implementation from the latest `origin/main` and confirm the requested
- Check available disk space before creating the worktree or starting dependency downloads, builds, tests, coverage, or other artifact-heavy commands. For long-running or artifact-heavy work, re-check disk usage at natural phase boundaries and before broad validation; if remaining space may not safely accommodate the next command, stop and reclaim task-owned artifacts before continuing.
+  change is not already present.
- Keep cleanup scoped and safe: remove generated build/test/coverage artifacts and temporary files created by the task when they are no longer needed, and never delete another task's worktree or uncommitted files. Prefer shared dependency caches where supported instead of duplicating large artifacts across worktrees.
+- An existing clean, isolated task worktree is sufficient. Create another
- At handoff, report the disk-space checks, cleanup performed, and any retained worktree or artifacts with the reason they are still needed.
+  worktree only when the current checkout is shared, dirty with unrelated work,
  or belongs to another task.
 - Never commit from a shared checkout. Use an `overtrue/` feature branch unless
  the user requests another name.
 - Check free space before artifact-heavy builds, tests, coverage, or downloads.
  Re-check before a broad gate when space is tight.
 - Remove only task-owned temporary/build artifacts. Never delete another task's
  worktree or uncommitted data.
 - At handoff, mention disk or cleanup details only when they affected execution
  or artifacts/worktrees remain intentionally.
-## PR Lifecycle Monitoring
+## Change Style
- Creating or updating a PR is not the terminal state. Unless the requester explicitly limits the task to PR creation, monitor the PR through its terminal state: merged, closed, or explicitly handed off because progress requires user or maintainer action.
+- Preserve existing control flow unless changing it is required for correctness.
- While the task is active, monitor CI/check runs, review decisions and unresolved threads, mergeability and conflicts, and unexpected head/base changes. Prefer event-driven or bounded waits provided by the current environment over frequent polling; report only state changes, actionable failures, or meaningful prolonged delays.
+- Prefer a direct local edit over new files, wrappers, managers, or speculative
- Investigate every failing check and review comment before changing code. Fix failures attributable to the task, run the verification required for the new diff, push the update, respond to or resolve the corresponding review threads, and resume monitoring. Do not weaken checks, dismiss valid feedback, or retry flaky failures merely to obtain a green result.
+  abstractions.
- Treat opening, green CI, approval, and mergeability as intermediate states. Never merge without the required reviewer approval or explicit authority. If progress depends on credentials, infrastructure, a maintainer decision, or another external action, report the exact blocker and the evidence already collected.
+- Add a helper only when it removes current duplication, names a real domain
- If the current execution environment cannot remain active until the next PR event, use a supported automation, monitor, or thread wakeup when available and within scope. Otherwise leave an explicit handoff containing the PR, current state, next event to observe, and pending cleanup; do not imply that background monitoring exists when none is scheduled.
+  boundary, or isolates a non-trivial invariant.
- After observing a merge, verify the commits are preserved on the upstream base, ensure the worktree is clean, remove the dedicated worktree, prune stale worktree metadata, and delete the local task branch when it is no longer in use. For a closed or abandoned PR, preserve any unmerged work unless deletion was explicitly authorized. Do not delete remote branches unless explicitly requested or repository automation owns that cleanup.
+- Remove an in-scope path superseded by the change. If compatibility requires it,
  adapt at the boundary to one canonical core and use the repository's
  `RUSTFS_COMPAT_TODO` policy.
 - Comments explain non-obvious invariants or reasons. Do not narrate code or
  record change history.
 - Mention unrelated problems when useful; do not fix them in a narrow task.
-## Autonomy and Approval Boundaries
+## Reuse and Boundary Rules
- Inquiry tasks (answer, explain, review, diagnose, plan): report findings; do not change files unless a fix is explicitly requested.
+- Before adding helpers, constants, fixtures, or wrappers, search the touched
- Action tasks (change, build, fix): make in-scope local changes without asking for approval.
+  crate, the domain-owning crate, `crates/utils`, `crates/common`, and relevant
- Ask for confirmation before destructive or hard-to-reverse operations (force-pushes, history rewrites, deleting data or branches), merging a PR (reviewer approval required), or any material expansion of the requested scope.
+  direct dependencies.
-
+- Reuse requires matching semantics: normalization, error types, deadlines,
-## Communication and Language
+  durability, and compatibility must fit the call site. A narrowly named local
-
+  helper is better than forced reuse with different semantics.
- Respond in the same language used by the requester.
+- Validate untrusted input at its trust boundary, then trust the validated type.
- Keep source code, comments, commit messages, and PR title/body in English.
+  Values crossing disk, RPC, persistence, or version boundaries remain
- Be concise. Avoid sycophantic openers, closing fluff, and verbose status reporting.
+  untrusted at every consumer.
-
+- Re-check boundary values immediately before destructive actions such as
-## Change Style for Existing Logic
+  delete, overwrite, or quorum decisions.
-
+- Every new branch needs a concrete triggering input/state. For decoded or peer
- Start with the smallest direct, local edit. Add production files, types, traits, helpers, wrappers, or abstraction layers only when current behavior requires them. Extraction must remove present duplication, enforce a real boundary, or materially clarify a non-trivial flow; anticipated reuse is not enough.
+  data, corruption and mixed-version input are valid triggers.
- Use Rust's default module file layout (`mod foo;` with `foo.rs` or `foo/mod.rs`/`foo/*.rs`).
+- Required values must return a typed error when absent or corrupt; do not use a
-  Avoid `#[path = "..."]` for module inclusion; move files into the canonical module tree instead.
+  default that converts corruption into a plausible result.
-  If an unavoidable generated-code, FFI, or test-fixture exception remains, keep it local and document why the canonical layout cannot work.
+- Attach error context once where it is actionable. Do not erase typed errors
- Solve only the requested problem; do not add speculative features, configurability, or adjacent improvements.
+  below aggregation or quorum layers.
 - Prefer editing existing code over rewriting files or reshaping unrelated logic.
 - Modify only what is required. Remove any in-scope path or representation superseded by the change. If compatibility or rollback requires retention, adapt at the boundary to one canonical core and follow the repository's `RUSTFS_COMPAT_TODO` removal policy; never delete unrelated code merely to improve addition/deletion statistics.
 - Preserve the existing control-flow and logic shape when fixing bugs or addressing review comments, especially in init, distributed coordination, locking, metadata, and concurrency paths.
 - Do not refactor existing code only to make it easier to unit test.
 - Keep fixes narrowly aligned with the requested behavior; avoid semantic-adjacent rewrites while touching sensitive paths.
 - Keep code elegant, concise, and direct. Prefer the smallest readable design and existing abstractions over parallel managers, factories, adapters, or wrappers added only to make the design look extensible.
 - Comments state non-obvious reasons, assumptions, and invariants in the shortest complete form. Their length follows the invariant's complexity: `SAFETY`, lock ordering, durability, and compatibility contracts may need a short list of conditions. Never narrate the next line, restate a signature, or record change history; move durable design rationale to architecture or operations documentation.
 - Mention unrelated issues when useful, but do not fix them as part of a narrow task.
 ## Reuse Before You Write
 Search for an existing implementation before writing a new one; extend what exists instead of duplicating it:
 - **Helpers and utilities** (path/string handling, hashing, retry, env parsing, IO wrappers): check `crates/utils`, `crates/common`, the touched crate, the likely domain-owning crate, and relevant direct workspace dependencies from `Cargo.toml`. Search snake_case signatures with a focused term. Reimplementing an existing workspace helper — or hand-rolling what `std`, `tokio`, or an existing dependency already provides — is a review finding, not a style preference.
 - **Reuse requires matching semantics, not a matching name**: before adopting a helper, check its normalization (`clean` resolves `.`/`..` — never apply it to raw S3 object keys), error type, backoff/deadline behavior, and durability gating against the call site. When semantics differ, a new narrowly-named helper with a comment naming the rejected lookalike is the correct outcome. The inverse also holds: workspace wrappers exist because raw `std`/`tokio` semantics were insufficient (durability gates, retries) — prefer the wrapper over the raw call.
 - **Constants and fixed tokens** (protocol labels, error identifiers, header keys, event names, metric names, command tags): search for existing constants/enums that already represent the same semantic value and reuse them. If a value is truly new, define one local constant near related logic; never scatter the literal across sites. When changing existing behavior, align naming and format with the established constants.
 - **Test scaffolding**: reuse existing test utilities and fixtures (the touched crate's own `test_util` module and `tests/fixtures`, or `crates/test-utils`) instead of writing new setup code — run `rg -l '<fn-under-test>' <crate>/src <crate>/tests` before writing a test. A new test must pin a failure mode no existing test covers. Near-duplicate means same code path AND same poison-value class: this repo's boundary companions (n==max vs max+1, absent vs empty vs nil UUID bytes, MetaObject vs MetaDeleteMarker) are distinct by definition and must all be written.
 ## Necessary Code Only
 Net-new code — files, types, branches, comments — is cost to justify, not progress:
 - Inspect production-code additions separately. Tests, fixtures, generated code, and documentation do not count as production-code growth. Line counts are signals, not quotas: new production structures must map to a current requirement, and a blocker requires a concrete smaller design that preserves correctness, compatibility, readability, and real boundaries.
 - Validate at the trust boundary — untrusted client input, bytes read from disk, RPC payloads, config (see Serde Safety and Cross-Cutting Domain Invariants) — then trust the type: do not re-check what the type system or a validated upstream layer already guarantees, and cite the establishing check (`file:line`) when the guarantee is not obvious.
 - The exception is load-bearing: a value that crossed a persistence, RPC, or version boundary is never guaranteed by the code on the other side — a peer may be older or buggy, disk bytes may be corrupt — so the Cross-Cutting Domain Invariant patterns apply at every consumer, and re-checks immediately before a destructive action (delete, overwrite, quorum decision) stay. Deleting an existing guard is a behavior change requiring adversarial review, not cleanup.
 - Every new branch needs a nameable trigger: a concrete input, state, or failure that reaches it — for boundary-crossing values, corrupt or stale persisted/peer data is always nameable. If you cannot name one, do not write the branch. If the case is truly unreachable, encode the invariant in the type; where that is impossible, return a typed internal error (fail closed). `debug_assert!` is acceptable only for pure internal arithmetic on values that never crossed a disk/RPC/config boundary — never as the sole guard on decoded or peer-supplied data.
 - Never substitute a default where the value is required (e.g. `unwrap_or_default()` on metadata that must exist) — that converts corruption into a wrong answer. Return the typed error instead: explicit failure over implicit success.
 - Attach error context once, at the layer where it is actionable: re-wrapping equivalent context at every hop is noise, and expanding a fallible chain into nested `match` blocks where `?` or a combinator suffices is a finding. Never add context by converting a typed error into a generic variant below an error-aggregation or quorum layer (`reduce_errs` classifies by variant equality) — context there belongs in a `tracing` event, not the error value.
 ## Sources of Truth
- Workspace layout and crate membership: `Cargo.toml` (`[workspace].members`)
+- Workspace membership: `Cargo.toml`.
- Local quality commands: `Makefile` and `.config/make/`
+- Local gates: `Makefile` and `.config/make/`.
- CI quality gates: `.github/workflows/ci.yml`
+- CI gates: `.github/workflows/ci.yml`.
- PR template: `.github/pull_request_template.md`
+- PR format: `.github/pull_request_template.md`.
- High-level architecture and crate map: `ARCHITECTURE.md`
+- Architecture routing: `ARCHITECTURE.md` and `docs/architecture/README.md`.
- Migration guardrails, readiness contracts, support matrices:
+- Agent skills: `.agents/skills/*/SKILL.md`.
  `docs/architecture/README.md` (routes by audience)
 - Shared agent skills (all tools): `.agents/skills/` — each `SKILL.md` carries
  a frontmatter `description` stating when it applies. Scan the descriptions
  before starting a task and follow any skill that matches, even if your tool
  does not auto-load skills:
  `grep -m1 '^description:' .agents/skills/*/SKILL.md`
  Claude Code reads them through the `.claude/skills` symlink; add new skills
  to `.agents/skills/` only, never as separate copies per tool
-Avoid duplicating long crate lists or command matrices in instruction files.
+Do not commit one-shot plans, trackers, migration ledgers, benchmark snapshots,
-Reference the source files above instead.
+or agent scratch notes. Durable architecture belongs under `docs/architecture/`,
 operations under `docs/operations/`, and testing references under
 `docs/testing/`. `scripts/check_no_planning_docs.sh` enforces this boundary.
-Do not commit planning-type documents — one-shot implementation/optimization
+## Verification
 plans, task trackers, migration-progress ledgers, phase/PR templates,
 issue-scoped benchmark-result snapshots or optimization conclusions, or
 agent-generated working notes (e.g. anything a `superpowers`/scratch workflow
 produces). Keep that work in the issue tracker or your local worktree, not in
 the repository. Only durable reference — the architecture set under
 `docs/architecture/`, repeatable operational runbooks under `docs/operations/`,
 and the test-suite references under `docs/testing/` — belongs in version
 control; `.gitignore` ignores everything else under `docs/` by default, so a new
 plan file will not be tracked unless someone force-adds it — don't.
 `scripts/check_no_planning_docs.sh` (wired into `make pre-commit`/`pre-pr` and
 CI) fails the build if anything is committed under `docs/superpowers/`, even via
 `git add -f`.
-## Verification Before PR
+Select checks from the final task-owned diff. Scoped `AGENTS.md` files may add a
 concrete path-specific check, but must not replace this tiering with a generic
 full-workspace gate.
-Convert changes into independently verifiable outcomes. This section controls
+### Documentation and Instructions
 agent-run local validation; preparing a commit or PR does not by itself require
 the broadest gate. Inspect only the final task-owned diff, classify it by
 behavioral impact rather than line count or path alone, and run the smallest
 set of checks that provides meaningful coverage. Do not let unrelated
 worktree changes or a generic contributor checklist expand the scope.
 For non-exempt changes, complete the applicable multi-role adversarial review
 before running `make pre-pr` (or an equivalent full gate). Resolve or rebut
 every finding first, then run the gate against the reviewed final diff.
-### Validation floor
+For prose, comments, agent instructions, and skill metadata that cannot affect
 runtime/build output:
- Every change that is not documentation-only must finish with
+- Run `git diff --check`.
-  `cargo fmt --all --check` passing. An umbrella gate that runs this exact
+- Run the relevant documentation guard or skill validator when applicable.
-  check satisfies the requirement; do not run it twice. Use `cargo fmt --all`
+- Skip Cargo formatting, compilation, Clippy, tests, `make pre-commit`, and
-  only when formatting needs to be fixed. Run the configured formatter or
+  `make pre-pr`.
  validator for other changed languages when one exists.
 - Documentation-only or instruction-only means all task-owned changes are
  prose or documentation assets and cannot affect runtime, builds, CI,
  dependencies, generated code, or tests. Run `git diff --check` and any
  relevant documentation guard, but skip Cargo formatting, compilation,
  Clippy, tests, `make pre-commit`, and `make pre-pr`.
 - Behavior changes require relevant existing or new tests. Prefer the most
  focused test or affected package. A passing targeted test can also provide
  sufficient compilation coverage when it builds every changed target and
  feature involved; do not add a redundant `cargo check` in that case.
 - `cargo check` supplements compilation coverage; it never substitutes for a
  behavioral test. If a relevant test cannot reasonably be added or run, use
  the narrowest compilation check and report the reason and remaining risk.
-### Validation tiers
+### Non-Behavioral Source Changes
-1. **Documentation/instruction-only:** Apply the exemption above. Run a guard
+- Run the formatter/validator for the changed language.
-   such as `make doc-paths-check` only when it is relevant to the edited text.
+- Add compilation or doctests only when syntax or executable examples changed.
 2. **Non-behavioral source change:** For comments, formatting, or another
   demonstrably non-executable change, run the formatting floor. Compilation,
   Clippy, and tests may be skipped only when the edit cannot affect
   compilation or runtime behavior; run targeted doctests if executable
   documentation examples changed.
 3. **Localized or bounded behavior change:** Run the formatting floor and the
   narrowest relevant tests. Add package-scoped `cargo check` or Clippy only
   for changed targets, features, APIs, error handling, async behavior, or
   control flow not already covered. When several crates are affected but the
   dependency set is identifiable, validate those packages and known
   dependents instead of the whole workspace. Use `make pre-commit` only when
   a repository-wide fast gate adds useful confidence beyond those checks.
 4. **Broad or high-risk change:** After the applicable adversarial review has
   completed, run `make pre-pr` only when targeted coverage cannot bound the
   impact, including:
   - dependency, feature, build-script, procedural-macro, code-generation,
     toolchain, or CI changes that alter compilation or the test matrix;
   - cross-crate public APIs, shared foundational code, or broad refactors with
     an unbounded dependent set;
   - locking, storage durability or formats, erasure coding, replication,
     RPC/protocol compatibility, IAM/KMS/auth, cryptography, or other
     security-sensitive behavior;
   - a targeted check that reveals wider impact, an explicit user request, or
     a release policy that requires the full gate.
-Documentation-only and non-behavioral classifications take precedence over
+### Localized Behavior Changes
 path-based triggers. A small diff can still be high-risk, while a CI comment,
 manifest comment, or release-note edit does not require full validation.
-`make pre-pr` includes `make pre-commit` coverage. Never run both for the same
+- Run `cargo fmt --all --check` for Rust changes.
-unchanged diff, and do not repeat equivalent checks during PR preparation or
+- Run the narrowest test that exercises the changed behavior.
-because a local hook already ran them. Rerun only checks whose scope is affected
+- Add package-scoped `cargo check` or Clippy only for targets, features, public
-by later edits. Full workspace checks do not replace a relevant integration or
+  APIs, error handling, or control flow not compiled by the focused test.
-E2E test for changed behavior; run that focused test when required and
+- Use `make pre-commit` only when its repository-wide fast checks add confidence
-available, or report why it was not run and the remaining risk.
+  beyond the focused checks.
-If `make` is unavailable, run the equivalent checks defined under
+### Broad or High-Risk Changes
 `.config/make/`. At handoff, list the checks actually run, checks intentionally
 skipped, and the reason for the selected tier.
-After build-based verification completes, clean generated build artifacts before wrapping up to avoid unnecessary disk usage.
+After the required adversarial review, run `make pre-pr` when targeted coverage
-Do not open a PR with code changes when the required checks fail.
+cannot bound the impact, including dependency/toolchain/build-matrix changes,
-Make a failing check pass by fixing the cause, never by weakening the gate:
+unbounded cross-crate APIs, or locking, durability, erasure coding, replication,
-do not loosen or skip a guard script, add entries to a baseline or allowance
+RPC, IAM/KMS/auth, cryptography, on-disk/on-wire, and S3-visible behavior.
 list, suppress a lint with `#[allow]`, mark a failing test `#[ignore]`, or
 delete or relax a failing assertion to get green. If a check itself is wrong,
 change it deliberately and state the rationale in the PR.
-For flaky tests, do not paper over them with retries. Follow the flake policy
+`make pre-pr` includes `make pre-commit`; never run both for the same unchanged
-in [docs/testing/README.md](docs/testing/README.md) (open an issue within 24h,
+diff. Do not repeat a check already covered by a successful umbrella gate.
-quarantine with an issue link, fix or delete within 30 days); the local
+Rerun only checks affected by later edits.
 `default` nextest profile never retries.
-## Adversarial Validation (Default On)
+Never weaken a gate to get green: do not add baselines/allowances, suppress
 lints, ignore tests, or relax assertions unless changing that policy is itself
 the reviewed task. Follow `docs/testing/README.md` for flaky tests.
-Every non-exempt output (see Risk tiers) — code change, bug fix, or
+## Adversarial Validation
 design/solution proposal — passes multi-role adversarial review before it
 counts as done.
 Author confidence is not evidence: each role's job is to refute the change,
 not to bless it.
-### Risk tiers
+Adversarial validation applies to final implementation diffs, explicitly
 requested adversarial/design reviews, and agent-instruction changes that alter
 execution. Ordinary questions, diagnoses, status reports, non-adversarial code
 reviews, and low-risk planning do not trigger it.
-Pick the tier from the riskiest file touched; when in doubt, pick the higher.
+Risk and review shape:
- **Exempt:** docs/comments, formatting, and typos that cannot affect runtime,
+- **Exempt:** documentation, comments, formatting, or typos with no runtime,
-  builds, tests, or agent execution. Skip this section.
+  build, test, or agent-execution effect.
- **Mechanical:** pure renames, file moves, test-only or tooling changes, and
+- **Mechanical:** renames, moves, test/tooling-only changes, and agent-rule
-  agent-instruction changes that alter execution —
+  changes. Run correctness and simplicity lenses.
-  correctness and simplicity adversaries only.
+- **Standard:** localized behavior changes. Run one integrated final-diff pass
- **Standard (the default):** any change that affects behavior.
+  covering correctness, simplicity, and test coverage; add only domain lenses
- **High risk:** touches locking, erasure coding, quorum/heal, replication,
+  matched by the diff.
-  multipart, RPC, lifecycle/tiering, metadata formats (`xl.meta`),
+- **High risk / substantial PR review:** high risk includes locking,
-  persistence/fsync, IAM/KMS/auth, on-disk or on-wire formats, or
+  erasure/quorum/heal, replication, multipart, RPC, lifecycle/tiering,
-  S3 API-visible behavior.
+  persistence/fsync, IAM/KMS/auth, cryptography, on-disk/on-wire formats, and
  S3-visible semantics. Cover all applicable lenses using exactly two
  independent reviewers when delegation is explicitly authorized. Split the
  lenses between them. Otherwise perform two fresh sequential passes.
-### Roles
+Available domain lenses are security, concurrency/durability, compatibility,
 and performance. Select `.agents/skills/adversarial-validation/SKILL.md` for an
 explicit adversarial request, a high-risk change, or a substantial PR review;
 then read only its matching role references. A routine standard pass does not
 load the playbook unless the reviewer needs a RustFS-specific probe.
-Run each applicable role as an independent pass over the final diff (or
+A finding must name a concrete input/state/interleaving and wrong outcome, or a
-proposal text) — parallel reviewer agents where the tooling supports them,
+specific missing regression check, with `file:line`. Resolve it by fixing the
-otherwise sequential passes that each start fresh from the diff and the
+diff or rebutting it with code-path/test/invariant evidence. After a non-trivial
-nearest scoped `AGENTS.md`, discarding the writing session's assumptions.
+fix, rerun only affected lenses.
 Each role either produces findings or reports "attacked X, Y, Z — no break
 found"; a bare pass is not a result. Repo-specific attack probes for every
 role live in `.agents/skills/adversarial-validation/` — run them, they
 encode this repo's shipped bugs.
- **Correctness adversary** — construct a concrete input/state/interleaving
+For high-risk PRs, record one concise verdict per covered lens in the PR body.
  that yields wrong output, data loss, or a crash. Probe error paths and edge
  values (empty, nil UUID, zero-length, quorum−1, missing version).
 - **Simplicity adversary** — same behavior, less code. Hunt reimplemented helpers, rewrites where an in-place edit suffices, speculative abstractions, defensive branches with no nameable trigger, redundant error wrapping, near-duplicate tests, and narration comments. A one-caller helper is a finding only when it merely forwards or splits a short linear flow without adding domain naming, boundary isolation, an invariant, or useful error context. Report a concrete smaller replacement; fewer lines alone are not evidence.
 - **Security reviewer** — authn/authz bypass, injection, secret leakage,
  untrusted deserialization (see Serde Safety), path traversal, timing leaks.
 - **Concurrency/durability reviewer** — lock ordering, races, cancellation,
  partial failure, retry/idempotency, crash and power-loss ordering.
 - **Compatibility reviewer** — S3 API surface, MinIO interop, on-disk and
  on-wire formats, mixed-version upgrade/downgrade paths.
 - **Performance reviewer** — allocation and cloning on hot paths, lock hold
  time across IO, sync or CPU-heavy work on async runtime threads, added
  fsync/flush outside the durability gate, hot-path logging noise. A
  measurable regression on a per-request or per-object path is a finding.
 - **Test-coverage skeptic** — for each testable behavior claim, name the test
  or executable check that detects a revert; then name a changed line that
  could be wrong while all checks stay green. If a focused check is not
  reasonable, require the reason and residual risk from the validation floor.
  Test additions have no line-count or growth budget.
-Standard tier: correctness adversary + simplicity adversary + test-coverage
+## Pull Request Lifecycle
 skeptic, plus every role whose domain the diff touches (async or
 shared-state code → concurrency; parsing of untrusted input → security;
 public crate API shape → compatibility; per-request or per-object hot paths
 → performance).
 High risk: all seven roles.
-### Protocol
+- Creating or updating a PR includes one immediate snapshot of checks,
-
+  mergeability, reviews, and unresolved threads.
-1. A finding states a concrete failure scenario (input/state → wrong
+- Unless the user explicitly requests monitoring, a release workflow requires
-   outcome) or names a missing test, with severity and file:line. "Looks
+  it, or an automation already owns it, hand off after the PR is open with the
-   risky" is not a finding.
+  current state and next event to watch. Do not delay ordinary handoff with
-2. Resolve every finding: fix it, or rebut it with evidence — a test, a
+  fixed quiet-period sleeps.
-   traced code path, or a cited invariant. Restated intent and "unlikely"
+- For requested monitoring, use event-driven or bounded waits. Report only state
-   are not rebuttals.
+  changes, actionable failures, or a meaningful prolonged delay.
-3. After non-trivial fixes, re-run the roles whose domain the fix touched.
+- Investigate failures/comments before changing code. Fix task-attributable
-4. For proposals with no diff, roles attack assumptions, failure modes,
+  issues, rerun affected verification, push, reply or resolve the thread, then
-   migration/rollback, and testability instead — including the simplest
+  resume the requested monitor.
-   rejected alternative and the blast radius when the design fails.
+- Never merge without required reviewer approval or explicit authority.
-
+- After an observed merge, verify the commit reached the base, then clean the
-### Exit criteria
+  task worktree/branch when safe. Preserve unmerged work for closed PRs unless
-
+  deletion was explicitly authorized.
 - Every applicable role has run; every finding is fixed or rebutted with
  evidence.
 - Every testable behavior change has a focused regression check. Exceptions
  follow the validation floor and state why a check is impractical and what
  risk remains.
 - After the applicable adversarial review has completed, the Verification
  Before PR gates pass; adversarial review supplements those gates, never
  replaces them.
 - High risk only: record a one-line verdict per role in the PR description.
 ## Git and PR Baseline
- Use feature branches based on the latest `main`.
+- Follow Conventional Commits; keep the subject at most 72 characters.
- Assume other agent sessions work this repository concurrently. Never commit
+- Source comments, commits, PR titles, and PR bodies are in English.
-  in a shared checkout; do all work on a dedicated feature branch, preferably
+- Keep every heading from `.github/pull_request_template.md`; use `N/A` where
-  in a dedicated worktree.
+  needed and include commands actually run.
- Immediately before branching, fetch `origin/main` and branch from it;
+- Use `--body-file` for multiline `gh pr create`/`gh pr edit` content.
-  confirm the target issue is not already fixed there before writing code.
+- PR/issue/discussion content must not contain the literal sequence `\n` or
- Follow Conventional Commits, with subject length <= 72 characters.
+  hard-wrapped prose paragraphs.
- Keep PR title and description in English.
+- Do not include local absolute paths or tool-specific labels/prefixes in GitHub
- Use `.github/pull_request_template.md` and keep all section headings.
+  content.
- Use `N/A` for non-applicable template sections.
+- Resolve review threads after the underlying issue is fixed. If declining a
- Include verification commands in the PR description.
+  suggestion, reply with a short evidence-based reason.
 - When using `gh pr create`/`gh pr edit`, write the markdown body to a file
  and pass `--body-file`; multiline inline `--body` is unsafe — backticks and
  shell expansion can corrupt content or trigger unintended commands.
  Pattern: `cat > /tmp/pr_body.md <<'EOF' ... EOF`, then
  `--body-file /tmp/pr_body.md` (keep the file outside the checkout).
 - Do not include the literal sequence `\n` in any GitHub issue, pull request, or discussion comment.
 - Do not hard-wrap prose in PR/issue/discussion bodies; write each paragraph as a
  single line and let it reflow. GitHub renders single newlines inside a paragraph
  as line breaks, so mid-sentence wrapping shows up as ugly breaks. Only break lines
  for list items, code blocks, and deliberate separators.
 - After fixing code review comments or CI findings, always mark corresponding review
  comments/threads as resolved before returning to the user.
 - In handling review comments, confirm the underlying issue before changing code.
  If a suggested change is not appropriate for behavior or risk, reply with a
  concise rationale instead of blindly applying it.
 ## Security Baseline
 - Never commit secrets, credentials, or key material.
 - Use environment variables or vault tooling for sensitive configuration.
- For localhost-sensitive tests, verify proxy settings to avoid traffic leakage.
+- For localhost-sensitive tests, bypass proxies explicitly.
 - Untrusted S3 XML/JSON, lifecycle, policy, replication, and RPC structures use
  strict deserialization where compatibility permits. Security-critical
  defaults require explicit validation.
 ## Logging
-Applies to **every** `tracing` macro you add or edit, including a single line
+For every added or edited `tracing` call:
 added in passing while fixing something else — not only to log-focused changes.
- Fields first, message second: `event`, `component`, `subsystem`,
+- Reuse the module's `EVENT_*`, `LOG_COMPONENT_*`, and `LOG_SUBSYSTEM_*`
-  `result`/`state`, then key context. The message is a short label, not a
+  constants and field shape.
-  sentence with values interpolated into it.
+- Put fields first and a short label last.
- Reuse the existing `EVENT_*` / `LOG_COMPONENT_*` / `LOG_SUBSYSTEM_*`
+- Use `error` for behavior/security failure, `warn` for degradation/fallback,
-  constants of the module you are editing; match the shape of the log sites
+  `info` for low-frequency lifecycle, `debug` for diagnostics, and `trace` for
-  already in that file rather than introducing a second style next to them.
+  repetitive request/object success paths.
- Level policy: `error` for behavior/security-affecting failures, `warn` for
+- Never log secrets, credential payloads, or merged configs.
  degraded or fallback paths, `info` for low-frequency lifecycle, `debug` for
  targeted diagnostics, `trace` for hot paths. Per-object and per-request
  success paths are `trace`.
 - Never log secrets, tokens, credential payloads, or merged config dumps.
 - `scripts/check_logging_guardrails.sh` enforces a subset of this on the files
  it lists; passing it is a floor, not evidence the log matches the house style.
-See `.agents/skills/rustfs-logging-governance/SKILL.md` for the full event
+Use `.agents/skills/rustfs-logging-governance/SKILL.md` for logging changes.
 model, level policy, and guardrail-update checklist.
-## Tools
+## Cross-Cutting Storage Invariants
-### xl.meta decode tool Quick Use
+- Write internal object metadata under both `x-rustfs-internal-<suffix>` and
  `x-minio-internal-<suffix>` using
  `crates/utils/src/http/metadata_compat.rs` helpers.
 - Read binary UUID metadata with
  `.and_then(|v| Uuid::from_slice(&v).ok()).filter(|u| !u.is_nil())`; absent,
  empty, and nil all mean no value.
 - Remote-tier version `None` or `""` means an unversioned bucket; send no
  `versionId` on tier GET/DELETE.
 - `DataUsageCacheInfo` and `DataUsageEntry` keep their hand-written map
  serialization and new fields remain `#[serde(default)]` for older readers.
-```
+## Naming
 cargo run -p rustfs-filemeta --example dump_fileinfo -- "/path/to/file/xl.meta"
 ```
-## Serde Safety
+Use Rust API naming: `SCREAMING_SNAKE_CASE` constants/statics, `snake_case`
 functions/variables, and `PascalCase` types. Do not rename unrelated existing
 violations.
- Add `#[serde(deny_unknown_fields)]` to structs deserialized from untrusted input (S3 API XML/JSON, lifecycle rules, bucket policies, replication configs).
+## Scoped Guidance
 - When `deny_unknown_fields` is impractical (backward compatibility), at minimum log unknown fields at `warn` level.
 - Never use `#[serde(default)]` on security-critical fields without explicit validation of the resulting value.
-## Cross-Cutting Domain Invariants
+Before editing, locate the nearest instructions with:
 - Write internal object metadata under **both** `x-rustfs-internal-<suffix>`
  and `x-minio-internal-<suffix>` keys (MinIO interop). Use the helpers in
  `crates/utils/src/http/metadata_compat.rs` (`get_bytes` prefers the RustFS
  key); never write only one of the two.
 - Read binary UUID metadata defensively:
  `.and_then(|v| Uuid::from_slice(&v).ok()).filter(|u| !u.is_nil())` —
  absent, empty, and nil all mean "no value", never `Uuid::nil()`.
 - A remote-tier version of `None`/`""` means the tier bucket is unversioned:
  send **no** `versionId` on tier GET/DELETE.
 - Structs persisted in the scanner data-usage cache (`DataUsageCacheInfo`,
  `DataUsageEntry`) carry a hand-written map-encoded `Serialize`. MessagePack
  encodes derived structs as arrays, where an appended field makes the whole
  cache a decode error for older readers — keep new fields `#[serde(default)]`
  and keep the map encoding rather than reverting to `derive(Serialize)`.
 ## Naming Conventions
 - Follow Rust API Guidelines for naming: `SCREAMING_SNAKE_CASE` for statics and constants, `snake_case` for functions and variables, `PascalCase` for types.
 - Do not use camelCase or Hungarian notation (e.g., `globalDeploymentIDPtr` → `GLOBAL_DEPLOYMENT_ID`).
 - If existing code violates naming conventions, do not widen the violation in new code. Do not rename existing symbols as part of an unrelated task; mention the violation instead (see Change Style for Existing Logic).
 ## Scoped Guidance in This Repository
 Many crates and modules carry their own `AGENTS.md` with path-specific rules
 (security boundaries, lock ordering, domain invariants). Before editing a
 path, check for the nearest one:
 ```bash
 git ls-files '*AGENTS.md'
 ```
-The nearest file wins. Do not maintain a hand-written index of these files
+The nearest file wins for domain invariants. Keep generic workflow and
-here — it goes stale.
+validation policy in this root file.
@@ -19,7 +19,9 @@ Applies to all paths under `crates/`.
 - Document lock acquisition order when a module uses multiple locks. Never acquire the same set of locks in different orders across code paths.
 - Never hold a `tokio::sync::RwLock`/`Mutex` write guard across `.await` points unless the critical section is unavoidably async and the hold time is bounded.
- Prefer `compare_exchange` loops over load-then-store for concurrent counters (peak values, adaptive heuristics).
+- Prefer direct atomic `fetch_*` operations for unconditional updates and
  `compare_exchange` loops only for conditional updates such as peaks or
  adaptive state.
 - When resetting multi-field atomic statistics, use a version/sequence counter or accept that concurrent readers may see partial snapshots; document the tradeoff.
 - `std::sync::Mutex` is acceptable in async context only when held for a brief, non-`await`-containing critical section. If in doubt, use `tokio::sync::Mutex`.
@@ -40,7 +42,9 @@ Applies to all paths under `crates/`.
 - Keep unit tests close to the module they test.
 - Keep integration tests under each crate's `tests/` directory.
 - Add regression tests for bug fixes and behavior changes.
- Every test function must contain at least one `assert!`/`assert_eq!`/`assert_matches!`. A test that only calls code without asserting is not a test.
+- Every test needs an observable failure criterion. Direct assertions,
  delegated assertions, snapshots/properties, `#[should_panic]`, and meaningful
  `Result` failures are all valid; a call that can silently succeed is not.
 - In tests, prefer `.expect("context: what was being tested")` over bare `.unwrap()`. A test failure should tell you which operation failed and with what input.
 ## Async and Performance
@@ -50,4 +50,3 @@ crate.
  - `cargo test -p rustfs-audit`
  - Focused: `cargo test -p rustfs-audit --test pipeline_layer_test`
  - Focused: `cargo test -p rustfs-audit pipeline`
 - Full gate before commit: `make pre-commit`
@@ -28,4 +28,3 @@ follow.
 ## Suggested Validation
 - `cargo test --package e2e_test`
 - Full gate before commit: `make pre-commit`
@@ -49,4 +49,3 @@ Applies to `crates/ecstore/`.
 ## Suggested Validation
 - `cargo test -p rustfs-ecstore`
 - Full gate before commit: `make pre-commit`
@@ -24,4 +24,3 @@ Applies to `crates/iam/`.
 ## Suggested Validation
 - `cargo test -p rustfs-iam`
 - Full gate before commit: `make pre-commit`
@@ -55,4 +55,3 @@ shared plugin/runtime primitives from `rustfs-targets`.
  - Focused: `cargo test -p rustfs-notify runtime_facade`
  - Focused: `cargo test -p rustfs-notify runtime_view`
  - Focused: `cargo test -p rustfs-notify config_manager`
 - Full gate before commit: `make pre-commit`
@@ -23,4 +23,3 @@ Applies to `crates/policy/`.
 ## Suggested Validation
 - `cargo test -p rustfs-policy`
 - Full gate before commit: `make pre-commit`
@@ -75,4 +75,3 @@ run commands.
  - `cargo test -p rustfs-targets plugin`
  - `cargo test -p rustfs-targets runtime`
  - `cargo test -p rustfs-targets control_plane`
 - Full gate before commit: `make pre-commit`
@@ -25,4 +25,3 @@ Applies to `rustfs/src/admin/`.
 ## Suggested Validation
 - Admin handler and routing tests under `rustfs/src/admin/`
 - Full gate before commit: `make pre-commit`
@@ -25,4 +25,3 @@ Applies to `rustfs/src/storage/`.
 ## Suggested Validation
 - Targeted module tests in `rustfs/src/storage/*_test.rs`
 - Full gate before commit: `make pre-commit`