laulauland/dotfiles/engineering-principles

Engineering Principles

These are execution principles: how to drive a piece of work from request to verified result. They are orthogonal to code-design taste. When a decision is about naming, types, modules, parsing, errors, or tests, that is the apply-coding-standards skill, and these files defer to it rather than restating it.

Each principle is one file with one idea. Read the leaf in full when it applies; this index is only the router. They are referenced by name, not invoked as commands, and they apply the same whichever harness is driving (Claude, Pi, Codex, Cursor).

How this relates to apply-coding-standards

apply-coding-standards answers "is this code well-designed?" These principles answer "am I working on it the right way?" Where they touch the same ground, the principle points at the standard:

• Verification of a finished task lives here (PROVE_IT_WORKS.md); what a good test looks like lives in ../apply-coding-standards/TESTING_AND_VERIFICATION.md.
• Diff size and deletion bias live here; module and interface design lives in ../apply-coding-standards/DESIGNING_MODULES.md.
• Target-state-not-migration sequencing lives here; the no-backwards-compat design rule lives in apply-coding-standards's non-negotiables.

If a leaf ever duplicates a standard, cut the leaf down to the part the standard does not own.

Principles

Read the matching leaf before applying it.

Every principle in the table has its leaf file.