stabilizing-compose-types

Follow a three-tier order: first restructure the type so every property is a val of an already-stable type, then annotate owned source with @Immutable or @Stable, and finally whitelist third-party or Java types in stabilityConfigurationFiles. Never invert this order, since annotations are a contract, not a magic fix.

@Immutable requires every property to be a val of an immutable type with structural equals, and enables static expression promotion where constant-argument constructions are hoisted to singletons. @Stable suits types whose values can change but notify Compose through Snapshot, such as holders of MutableState.

Replace kotlin.collections.List with kotlinx.collections.immutable.ImmutableList, which the Compose compiler recognizes with a known-stable bitmask. Build values with persistentListOf() or .toImmutableList(). This is preferred over whitelisting kotlin.collections.List in stability_config.conf because the type system enforces immutability.

Yes, use stabilityConfigurationFiles with a stability_config.conf entry listing java.time.LocalDateTime, since the JDK source is not owned and cannot be annotated. Do not wrap it in a @Stable class with a var field, which breaks the stability contract and silently misses recompositions.

Flow has no observable identity, so the composable can never skip on it, and collecting inside the composable detaches from the lifecycle. Instead, collect upstream in a ViewModel or with collectAsStateWithLifecycle and pass the resolved value as a stable parameter.

Do not annotate when the unstable types are not yet diagnosed, when the symptom is a wrong-phase state read or a derivedStateOf problem, or when the type contains a var or unstable nested type. Annotating a type that violates the contract causes silently missed recompositions with no warning.