You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We keep accumulating places where UI/behavior should be conditional on what the thing is: harnesses (#29 — what does this agent support?), directories (does this project have git?), and in the future per-MCP, per-user, per-build-mode, etc.
Build a single feature-flag/capability registry with scoped sources so every call site asks the same question:
features.is_enabled("pull_requests", &scope)
…where scope is composed of contributors (directory detectors, harness capability bits, user prefs, experimental toggles). Contributors resolve in a defined order; the resolved value is cached and invalidated when its sources change (e.g. .git appears or disappears). Flags carry metadata (label, description, default, requires) so a debug/developer panel can list what's active and why.
We keep accumulating places where UI/behavior should be conditional on what the thing is: harnesses (#29 — what does this agent support?), directories (does this project have git?), and in the future per-MCP, per-user, per-build-mode, etc.
Build a single feature-flag/capability registry with scoped sources so every call site asks the same question:
features.is_enabled("pull_requests", &scope)
…where
scopeis composed of contributors (directory detectors, harness capability bits, user prefs, experimental toggles). Contributors resolve in a defined order; the resolved value is cached and invalidated when its sources change (e.g..gitappears or disappears). Flags carry metadata (label, description, default, requires) so a debug/developer panel can list what's active and why.Payoff:
Out of scope here: the exact API shape — design TBD.