androidbroadcast · kirich1409 · Apr 3, 2026 · Apr 3, 2026 · Copilot · Apr 3, 2026
diff --git a/.gitignore b/.gitignore
@@ -20,5 +20,4 @@ captures
 .pipeline/
 *.preferences_pb
 /docs/superpowers/
-/docs/adr/
 /.claude/worktrees/
diff --git a/docs/adr/001-configvalues-multi-module.md b/docs/adr/001-configvalues-multi-module.md
@@ -0,0 +1,21 @@
+# ADR 001: ConfigValues in Multi-Module Projects
+
+**Status:** Accepted
+
+## Context
+
+In multi-module Android/KMP projects, each feature module may declare its own `ConfigParam` flags. The question is how to compose these into a single `ConfigValues` instance that is shared across the app.
+
+## Decision
+
+Each module declares its flags as top-level `ConfigParam` constants. A single `ConfigValues` instance is created at the app level (e.g., in the DI graph) by passing all params through the same providers.
+
+The Gradle plugin generates a `FlagRegistrar` per module. The app module aggregates them via the generated `GeneratedFlagRegistry`, which collects every module's registrar at compile time.
+
+Modules never create their own `ConfigValues`; they only declare params and read from the shared instance injected from the app layer.
+
+## Consequences
+
+- Flag namespacing is flat — param names must be unique across all modules.
+- There is one set of local/remote providers for the whole app; per-module providers are not supported.
+- The Gradle plugin enforces uniqueness and generates the aggregation boilerplate automatically.
-In multi-module Android/KMP projects, each feature module may declare its own `ConfigParam` flags. The question is how to compose these into a single `ConfigValues` instance that is shared across the app.
-
-## Decision
-
-Each module declares its flags as top-level `ConfigParam` constants. A single `ConfigValues` instance is created at the app level (e.g., in the DI graph) by passing all params through the same providers.
-
-The Gradle plugin generates a `FlagRegistrar` per module. The app module aggregates them via the generated `GeneratedFlagRegistry`, which collects every module's registrar at compile time.
-
-Modules never create their own `ConfigValues`; they only declare params and read from the shared instance injected from the app layer.
-
-## Consequences
-
- Flag namespacing is flat — param names must be unique across all modules.
- There is one set of local/remote providers for the whole app; per-module providers are not supported.
- The Gradle plugin enforces uniqueness and generates the aggregation boilerplate automatically.
+In multi-module Android/KMP projects, each feature module may declare its own flags via the `featured { }` Gradle DSL. The question is how to compose these generated flags into a single `ConfigValues` instance that is shared across the app.
+
+## Decision
+
+Each module declares its flags in the `featured { }` Gradle DSL. The Gradle plugin generates module-scoped accessors such as `GeneratedLocalFlags` and `GeneratedRemoteFlags`, along with a per-module `GeneratedFlagRegistrar`.
+
+A single `ConfigValues` instance is created at the app level (for example, in the DI graph) and is wired using the set of `GeneratedFlagRegistrar` instances from the modules that participate in the app. There is no app-level generated `GeneratedFlagRegistry`; multi-module apps must explicitly include each module's generated registrar in their app wiring.
+
+Modules never create their own `ConfigValues`; they declare flags through the plugin-generated model and read from the shared instance injected from the app layer.
+
+## Consequences
+
+- Flag namespacing is flat — flag names must be unique across all modules.
+- There is one set of local/remote providers for the whole app; per-module providers are not supported.
+- The Gradle plugin generates `GeneratedLocalFlags`, `GeneratedRemoteFlags`, and a `GeneratedFlagRegistrar` for each module, while the app is responsible for wiring the relevant registrars together.
- The Gradle plugin enforces uniqueness and generates the aggregation boilerplate automatically.
+- The Gradle plugin currently serializes each module's declared flags, but it does not enforce cross-module uniqueness or generate an app-level aggregation boilerplate automatically.
-In multi-module Android/KMP projects, each feature module may declare its own `ConfigParam` flags. The question is how to compose these into a single `ConfigValues` instance that is shared across the app.
-
-## Decision
-
-Each module declares its flags as top-level `ConfigParam` constants. A single `ConfigValues` instance is created at the app level (e.g., in the DI graph) by passing all params through the same providers.
-
-The Gradle plugin generates a `FlagRegistrar` per module. The app module aggregates them via the generated `GeneratedFlagRegistry`, which collects every module's registrar at compile time.
-
-Modules never create their own `ConfigValues`; they only declare params and read from the shared instance injected from the app layer.
-
-## Consequences
-
- Flag namespacing is flat — param names must be unique across all modules.
- There is one set of local/remote providers for the whole app; per-module providers are not supported.
- The Gradle plugin enforces uniqueness and generates the aggregation boilerplate automatically.
+In multi-module Android/KMP projects, each feature module may declare its own flags via the `featured { }` Gradle DSL. The question is how to compose these generated flags into a single `ConfigValues` instance that is shared across the app.
+
+## Decision
+
+Each module declares its flags in the `featured { }` Gradle DSL. The Gradle plugin generates module-scoped accessors such as `GeneratedLocalFlags` and `GeneratedRemoteFlags`, along with a per-module `GeneratedFlagRegistrar`.
+
+A single `ConfigValues` instance is created at the app level (for example, in the DI graph) and is wired using the set of `GeneratedFlagRegistrar` instances from the modules that participate in the app. There is no app-level generated `GeneratedFlagRegistry`; multi-module apps must explicitly include each module's generated registrar in their app wiring.
+
+Modules never create their own `ConfigValues`; they declare flags through the plugin-generated model and read from the shared instance injected from the app layer.
+
+## Consequences
+
+- Flag namespacing is flat — flag names must be unique across all modules.
+- There is one set of local/remote providers for the whole app; per-module providers are not supported.
+- The Gradle plugin generates `GeneratedLocalFlags`, `GeneratedRemoteFlags`, and a `GeneratedFlagRegistrar` for each module, while the app is responsible for wiring the relevant registrars together.
- The Gradle plugin enforces uniqueness and generates the aggregation boilerplate automatically.
+- The Gradle plugin currently serializes each module's declared flags, but it does not enforce cross-module uniqueness or generate an app-level aggregation boilerplate automatically.
diff --git a/...ase/src/main/kotlin/dev/androidbroadcast/featured/firebase/FirebaseConfigValueProvider.kt b/...ase/src/main/kotlin/dev/androidbroadcast/featured/firebase/FirebaseConfigValueProvider.kt
@@ -5,6 +5,7 @@ import com.google.firebase.remoteconfig.FirebaseRemoteConfigValue
 import dev.androidbroadcast.featured.ConfigParam
 import dev.androidbroadcast.featured.ConfigValue
 import dev.androidbroadcast.featured.RemoteConfigValueProvider
+import kotlinx.coroutines.CancellationException
 import kotlinx.coroutines.tasks.await
 import kotlin.reflect.KClass
 
@@ -98,7 +99,7 @@ public class FirebaseConfigValueProvider(
 
         try {
             task.await()
-        } catch (e: RuntimeException) {
+        } catch (e: CancellationException) {
             throw e
         } catch (e: Exception) {
             throw FetchException("Firebase Remote Config fetch failed", e)