security-sensitive-changelisted

# Security-Sensitive Change Apply the global High-risk approval boundary first. Verify current primary provider/framework documentation when behavior is version-sensitive. Keep privileged state server-authoritative, validate untrusted input at trust boundaries, use least privilege and secure defaults, preserve tenant isolation, and protect secrets. For retried external events/payment-like flows, preserve integrity and idempotency. Add relevant negative tests (unauthorized, malformed, replayed, cross-tenant, invalid-state) when applicable. Refuse to implement: - hard-coded secrets; - SQL built by concatenating untrusted input; - disabled CSRF protection; - `eval` / `exec` on untrusted input; - unvalidated redirects. Briefly explain the risk and provide the safe equivalent. Require explicit confirmation for destructive/irreversible operations, production deploys, data deletion/risky migrations, breaking public APIs, auth behavior changes, major production dependencies, material scope expansion, private-data/repository transfer to external services, or creating/modifying/publishing shared/production resources. Read-only dependency metadata, package lookup, and repository fetches do not require confirmation unless private data or an unapproved service is involved.