principle-build-the-abstraction
Develop Complete Capabilities
When a feature needs a mechanism, implement the current functionality through a somewhat-general capability whose interface reflects the underlying responsibility, not incidental details of the immediate UI or workflow.
An abstraction is a simpler mental model with useful behavior behind it. A new class, wrapper, extracted function, shared branch, or small method set is not automatically an abstraction.
Decision rule
Make the development increment a coherent capability for the current need: keep its common use convenient, place specialization with its proper owner, and reduce the total understanding and change burden across callers and implementation.
This rule applies on the first use of a mechanism as well as when extending an existing abstraction. “Complete” means complete current semantics, including the lifecycle, ranges, ordering, errors, and performance constraints the capability must own. It does not mean predicting every future use or building a configurable framework.