rustfs-logging-governancelisted

# RustFS Logging Governance Apply this skill only to changed logging sites; do not turn a local log edit into a broad logging cleanup. ## Workflow 1. Read the changed function/module context and classify the site as lifecycle, request/hot path, fallback, external fetch, or summary. 2. Match neighboring structured events and reuse existing `EVENT_*`, `LOG_COMPONENT_*`, and `LOG_SUBSYSTEM_*` constants. 3. Put stable fields first (`event`, `component`, `subsystem`, `state`/`result`, then context) and a short label last. 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`. Read [logging-governance.md](references/logging-governance.md) only for a broad logging audit, event-model migration, or guardrail expansion. Ordinary single- site edits do not require the full workspace scope map.