engineering-standardslisted

# Engineering Standards Team engineering standards for code design, commits, pull requests, testing, and deployment. RFC 2119 keywords (MUST, SHOULD, etc.) carry their standard meanings. ## Code Design ### Principles - Every change applies SOLID, DRY, KISS, and YAGNI. One responsibility per function, class, or module. - Build only what the change requires now. No speculative hooks, flags, config, or generality. - Factor out duplication once it genuinely recurs. Never couple unrelated code that only looks alike. - Prefer composition over inheritance. Inherit only for a real is-a relationship, kept shallow. - Depend on an existing service interface rather than a concretion where one already covers the capability. - Names state what a thing is or does, not how or when. Match the conventions of the surrounding code over a personal preference. ### Boundaries and interfaces - A module's dependencies MUST point one way. No import cycles between modules. - Untrusted or untyped input MUST be validated at the boundary where it enters, before any use. Boundaries include HTTP requests, environment variables and config, external API responses, queue and event payloads, and anything parsed off disk. For JS/TS, `playbook:engineering-standards-javascript` names the schema-validator pattern. - A change to a published interface (an API response, a database schema, an event payload, an exported function) MUST be additive first: add the new shape, migrate the readers, remove the old shape