loom-feature-flags

# Feature Flags ## Overview Runtime control over feature availability without redeploying. The hard parts are not the `if` check — they are: **bucketing correctness** (stickiness, monotonicity, cross-service consistency), **fail-safe evaluation** (an outage of the flag service must not take down the app), **experiment validity** (exposure logging), and **lifecycle/technical-debt** (stale flags are the #1 real-world feature-flag problem). Optimize for those. ## Flag Taxonomy — Type Drives Lifetime and Ownership The single most useful classification (from Pete Hodgson / Martin Fowler). Type determines expected lifetime, who owns it, and dynamism. Mixing types under one abstraction is a common mistake. | Type | Purpose | Lifetime | Changes at runtime? | Owner | | ------------------- | ----------------------------------------- | ----------------- | ------------------- | ------------------ | | **Release toggle** | Ship incomplete/unproven code dark, ramp | Days–weeks (SHORT)| Per deploy/ramp | Dev team | | **Experiment** | A/B/multivariate measurement | Length of test | Sticky per user | PM / data science | | **Ops / kill-switch**| Disable a subsystem under load/incident | Long-lived | On demand (fast) | Ops / SRE | | **Permission** | Entitlements: plan tier, beta cohort | Very long / permanent | Per user/segment | Product / billing |...