additive-default-off-feature-flagslisted

# Add Capabilities Behind Default-Off Seams When you introduce a new capability to a system that already works, gate it behind a switch whose default reproduces the existing behavior exactly. The proven path stays untouched; the new path is opt-in, reversible, and carries no standing cost until someone deliberately turns it on. ## When to use Apply this whenever you add a feature to code, infrastructure, or a pipeline that real users or other systems already depend on: - A new collaborator (cache, verifier, retriever, telemetry sink) wired into an existing flow. - A new infrastructure component (a managed database, a queue, an extra service) added to a running deployment. - A behavior change you believe is an improvement but have not yet proven against the baseline. Red-flag thoughts that mean STOP and apply this skill: - "It's the plan, so I'll just turn it on." (Being planned is not the same as being proven.) - "I'll update the existing tests to match the new behavior." (You're about to erase the baseline's safety net.) - "It's obviously better, no need to keep the old path." (Then it survives a default-off rollout trivially — do that.) - "I'll rewrite the call sites to use the new thing." (That's a forced migration, not an additive seam.) ## The rule 1. **Add a seam, not a rewrite.** Introduce the feature as an optional parameter, an injected collaborator, or an environment / infrastructure selector — never by editing existing call sites to force the new path. 2. *