self-consistencylisted

> **AI-consumed reference.** Optimized for Claude to read during execution. > Human-readable explanation: see [docs/architecture/HIERARCHICAL_PLANNING.md](../../../docs/architecture/HIERARCHICAL_PLANNING.md) > or [docs/getting-started/](../../../docs/getting-started/) depending on topic. # Self-Consistency For ambiguous design decisions with multiple plausible answers. Generate multiple independent paths, take the majority. **Governed by:** `rules/workflow/self-consistency.md` (when / why) --- ## When NOT to Use - Single-answer tasks (file rename, typo) - Quick/Standard complexity — cost doesn't pay back - User said `must do:` / `just do:` / `no discussion` - Budget already >85% of session limit --- ## The Protocol ### Step 1 — Frame the decision Write the decision as a question with ≥2 possible answers: > "Should the API use REST or GraphQL?" > "Monolith, modular monolith, or microservices?" > "Redis for cache vs in-memory LRU?" If the question has only one sensible answer, skip SC. ### Step 2 — Generate N = 3 paths For each path, reason from scratch in an isolated context: ``` Path 1: - Consider user scale (est. 10K DAU for this product) - Consider team size (2 backend devs) - Consider infra (already on Fly.io, no k8s expertise) → Answer: Modular monolith Path 2: - Consider dev velocity (team ships weekly) - Consider deploy complexity (monorepo, single deploy) - Consider failure domains (single point of failure OK at this scale) → Answer: Mo