cupertino-integratelisted

Evaluate exactly one named seam per invocation. This technique never produces a blanket "always integrate" or "always delegate" default — if asked to apply it system-wide, ask which seam to start with and evaluate that one first. ## Steps 1. **Name the seam** precisely: which two layers, APIs, or ownership boundaries meet here, stated concretely enough that someone else could point at the exact boundary in the codebase. 2. **Friction analysis**: is there friction today (bugs, workarounds, slow iteration at this boundary), or is the friction anticipated (a foreseeable future need this seam will have to absorb)? Be specific — vague friction is not evidence. 3. **Apply the diagnostic heuristic, don't default**: it is tempting to assume customer-facing seams always favor tight integration ("this is what the user touches, so we must own it"). That is not automatically true — a customer-facing seam with low differentiation value and a mature vendor option can still favor delegation; conversely, an internal seam that is genuinely core to the product's advantage can favor tight ownership even though no customer ever sees it directly. Judge this seam on its own friction evidence, not on its visibility. 4. **Verdict**: integrate or delegate, with the trade named explicitly — not "it depends" but the actual thing being traded away by choosing this path. 5. **What changes as a result**: - If integrate: name what becomes harder to swap out later — the lock-in cost of ownership. -