Engineering principles

If a trigger matches, apply the rule. Name principles that changed a decision.

Design

Subtract, then add little. Remove dead code and stale checks first, then make the shortest diff that works. No abstraction with one user. Apply when sizing a diff or tempted to add a layer.
Data shape first. Choose the core types and structures before logic. Apply before writing new logic.
Model the domain. Put states in one structure, such as a typed union, state machine, or lookup table, not scattered conditionals. Apply when code branches a lot or repeats a shape across files.
Redesign for the new need. Fit a new requirement as if it existed from day one. Apply when an addition strains the design.
Low reader load. Inline one-caller wrappers and shrink mutable scope. Apply when code is hard to trace.
Guards at boundaries. Validate where input enters: CLI, config, network, files, external APIs. Trust types inside and keep core logic pure. Apply when adding validation or error handling.
Idempotent steps. Rerunning a step, even after a crash, reaches the same state. Apply to commands, setup, and retries.
No shared writers. Give each concurrent actor its own file, branch, or key before using locks. Apply when parallel work touches shared state.
Migrate, then delete. Move every caller and delete the old API in one change. No shims. Apply when replacing an API or rewriting in phases.
Compare options. For an unprecedented design, sketch two or three. Prefer fewer, polished features. Apply to novel architecture, UX, or scope choices.