sharp-edges

# Sharp Edges Analysis Evaluates whether APIs, configurations, and interfaces are resistant to developer misuse. Identifies designs where the "easy path" leads to insecurity. ## When to Use - Reviewing API or library design decisions - Auditing configuration schemas for dangerous options - Evaluating cryptographic API ergonomics - Assessing authentication/authorization interfaces - Reviewing any code that exposes security-relevant choices to developers ## When NOT to Use - Implementation bugs (use standard code review) - Business logic flaws (use domain-specific analysis) - Performance optimization (different concern) ## Core Principle **The pit of success**: Secure usage should be the path of least resistance. If developers must understand cryptography, read documentation carefully, or remember special rules to avoid vulnerabilities, the API has failed. ## Rationalizations to Reject | Rationalization | Why It's Wrong | Required Action | |-----------------|----------------|-----------------| | "It's documented" | Developers don't read docs under deadline pressure | Make the secure choice the default or only option | | "Advanced users need flexibility" | Flexibility creates footguns; most "advanced" usage is copy-paste | Provide safe high-level APIs; hide primitives | | "It's the developer's responsibility" | Blame-shifting; you designed the footgun | Remove the footgun or make it impossible to misuse | | "Nobody would actually do that" | Developers do everything imag...