Principles

Each principle below names when it applies and the rule it sets. Read a principle's file in full before you apply it: the entry here is the pointer, the file is the principle.

Core

• Laziness Protocol. Refactoring, sizing a diff, or tempted to add abstractions, layers, or signal threading. Bias to deletion and the smallest change that solves the problem.
• Foundational Thinking. Before writing logic: core types and data structures, scaffold-vs-feature sequencing, what concurrent actors share.
• Redesign from First Principles. Integrating a new requirement into an existing design. Redesign as if it had been foundational from day one.
• Attack the Premise. Two or more fixes that share one premise have failed the same gate. Take a census of which actors hold the imbalance before the next fix, then question the premise instead of writing another fix that assumes it.
• Subtract Before You Add. Sequencing an addition, refactor, or rewrite. Remove dead weight first, then build on the simpler base.
• Minimize Reader Load. Reviewing or shaping code that's hard to trace. Count layers and hidden state, collapse one-caller wrappers, shrink mutable scope.
• Outcome-Oriented Execution. Planned rewrites and migrations with explicit phase boundaries. Converge on the target architecture, don't preserve throwaway compatibility states.
• Experience First. Product, UX, or feature-scope tradeoffs. Choose user delight over implementation convenience.
• Exhaust the Design Space. A novel interaction or architectural decision with no precedent. Build 2-3 competing prototypes and compare before committing.
• Build the Lever. Any non-trivial work. Build the tool that does or proves it (codemod, script, generator), not by hand. The tool is the artifact a reviewer reruns.

Architecture