What problem does it solve? Maintainers reviewing changes to the Sonder Runtime need to know which security boundaries and privacy gates must never be weakened, and which code mechanism enforces each one, so a seemingly harmless diff does not silently open a consent gate, widen a file root, or turn a fail-closed check into fail-open. ## Core Features & Use Cases - Boundary catalog with enforcing mechanisms: Documents the network posture ladder, consent gates (SONDER_ALLOW_CLOUD, SONDER_WEB_TOOLS, and others), guarded file/execution tool ceilings, and privacy classifier rules, each mapped to the exact source file and constant that enforces it. - Diff review checklist: Provides nine blocking questions for any change touching security surfaces, covering root widening, redaction silencing, fail-open conversions, and capability-boolean leaks into request contexts. - Operational security guidance: Covers key rotation, unsafe-lab activation gating, TUF-signed update trust, and the never-share list for memory stores and personal training data. - Use Case: A maintainer receives a pull request that lets an adapter read SONDER_WEB_TOOLS before bootstrap; the skill flags it as the known web_tools.py fallback trap that silently flips the default open. ## Quick Start Ask whether a proposed diff that exposes the runtime on a non-loopback address weakens the Sonder security posture.
