Software Engineering

This is the baseline discipline for changing software. It does not replace language, framework, testing, security, observability, Git, or domain skills. Load those when the task needs them.

Core rules

• Correctness first. Clever code that is wrong has no value. Verify the defining behavior, important edge cases, failure paths, and compatibility obligations that actually apply.
• Prefer the smallest complete solution. Solve the accepted problem fully with the least new mechanism. Do not add speculative abstractions, extensibility, compatibility layers, feature flags, scaffolding, or TODO architecture for imagined future work.
• Deletion beats coexistence. When a replacement makes implementation obsolete, remove the obsolete path once its remaining uses are checked. Do not keep dead code "for later."
• Make intent explicit. Names, interfaces, state transitions, errors, and important decisions should reveal what the code means without requiring archaeology.
• Fail visibly. Surface and preserve actionable errors. Do not silently swallow failures, convert them into success, or hide partial failure behind fallback behavior unless accepted semantics explicitly require that behavior.
• Respect accepted authority. Implementation realizes accepted product, design, specification, security, lifecycle, and architecture meaning. It does not invent missing meaning.

Deep modules and information locality

Prefer deep modules: substantial behavior behind a small, stable interface.

The interface is everything a caller must know to use the module correctly. This includes not only functions and parameters, but also required ordering, invariants, state transitions, error modes, configuration, and other protocol knowledge.