extension-points-and-seamslisted

# Extension Points and Seams This skill scopes itself by **project fit**: it answers *when* a capability warrants a seam and *how* to build one. It applies to **swappable** capabilities. A capability with a single fixed implementation and a single consumer is outside its scope — for those a seam is needless indirection, and the honest design choice is to keep it a single unit. **The defining constraint:** a **seam** is the place where a *swappable* capability lives — the contract, the implementation, and the consumer are separated so they can vary independently. If nothing can plausibly vary, there is no seam to build. ## Decide: does this capability warrant a seam? Build a seam only when at least one of these is true: - **Multiple implementations are real or imminent** — a second backend, provider, or adapter is already planned or shipped (local vs remote, mock vs real, one vendor vs another). - **Multiple consumers exist** — more than one caller uses the capability, and they must not each couple to one implementation. If there is one conceivable implementation and one consumer, keep it a single unit. Split **only when a second implementation or consumer appears** — never preemptively. The seam's whole value is independent variation; without variation there is nothing to buy. ## The three roles A seam has three distinct concerns that change at different rates: 1. **Contract** — the interface that names the capability: the operations, the vocabulary types, the guaran