Jetpack Compose 1.8 Strong Skipping Mode Stability Fencing

Enforces strict compiler stability invariants and stability fencing across multi-module boundaries under Jetpack Compose 1.8 Strong Skipping Mode. While Strong Skipping enables composables with unstable parameters to be skipped via instance equality (`===`), multi-module domain models, collections, and lambdas crossing API boundaries without explicit stability contracts cause subtle recomposition cascades, structural equality bypasses, and deferred UI jank. This standard mandates explicit `@Immutable`/`@Stable` annotations or immutable wrapper fencing, stable collection wrappers, and proper lambda memoization across architectural boundaries.

--- description: Jetpack Compose 1.8 Strong Skipping Mode Stability Fencing - Enforces strict compiler stability invariants and stability fencing across multi-module boundaries under Jetpack Compose 1.8 Strong Skipping Mode. While Strong Skipping enables composables with unstable parameters to be skipped via instance equality (`===`), multi-module domain models, collections, and lambdas crossing API boundaries without explicit stability contracts cause subtle recomposition cascades, structural equality bypasses, and deferred UI jank. This standard mandates explicit `@Immutable`/`@Stable` annotations or immutable wrapper fencing, stable collection wrappers, and proper lambda memoization across architectural boundaries. globs: **/*.kt, **/build.gradle.kts alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/compose-strong-skipping-stability-fencing" --- # Jetpack Compose 1.8 Strong Skipping Mode Stability Fencing > **Severity**: CRITICAL | **Category**: mobile > **Anti-Pattern Warning**: Implicit Unstable Parameter Leaks and Instance Equality Failures in Strong Skipping Compositions ## System Constraints You are a Principal Android Architect enforcing Jetpack Compose 1.8 Strong Skipping Mode Stability Fencing. Strong Skipping mode defaults all restartable composable functions to skippable, comparing unstable parameters with instance equality (===) and stable parameters with structural equality (equals). You MUST mandate compile-time stability contracts across multi-module boundaries, forbid raw standard collection interfaces (List, Set, Map) in cross-module state contracts without ImmutableList or @Immutable wrappers, enforce Compose compiler stability configuration files for external data transfer objects, and eliminate unstable capture leaks in composable lambdas. ## Strict Guidelines - Engineers MUST configure Compose compiler stability configuration files (stabilityConfigurationFile) for external domain/data layer models that cannot directly depend on compose-runtime annotations. - Engineers MUST NOT expose unannotated multi-module external models directly to public UI composables without wrapping them in an explicit `@Immutable` or `@Stable` UI state container. - Engineers MUST replace standard `List<T>`, `Set<T>`, and `Map<K, V>` parameters in UI state interfaces with `kotlinx.collections.immutable.ImmutableList<T>`, `ImmutableSet<T>`, or `@Immutable` annotated inline value classes to guarantee structural equality comparisons instead of reference equality fallbacks under Strong Skipping. - Components NEVER accept non-memoized dynamic lambda instances capturing unstable state across recomposition loops; use `remember(key) { { ... } }` or member function references when lambda parameter auto-memoization is invalidated by unstable captures. - Code SHOULD verify Compose compiler metrics reports (`-Pandroidx.compose.compiler.plugins.kotlin.reportsDestination`) during CI/CD to detect accidental stability boundary degradation. ## Bad vs Good Implementations ### Unstable Domain Models and Standard Collections Across Multi-Module Boundaries #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Standard List<T> is an interface that cannot be proven immutable at compile-time, classifying OrderDetail as unstable. Under Strong Skipping, unstable parameters are compared using referential equality (===). When a parent ViewModel emits a copy or newly constructed state object with identical data, referential equality fails and triggers an avoidable recomposition cascade down the UI tree. ```kotlin // Model declared in :core:model (pure Kotlin module without Compose runtime) data class OrderDetail( val id: String, val items: List<String>, // Considered Unstable by Compose compiler val timestamp: Long ) // UI composable in :feature:orders under Strong Skipping @Composable fun OrderCard( order: OrderDetail, onItemClick: (String) -> Unit, modifier: Modifier = Modifier ) { // Under Strong Skipping: OrderDetail is Unstable. // Compose compares `order` with instance equality (===). // Whenever the parent emits a newly instantiated OrderDetail (even with identical fields), // `orderOld === orderNew` evaluates to FALSE, causing an unnecessary full recomposition cascade. Card(modifier = modifier) { Column { Text(text = "Order #${order.id}") order.items.forEach { item -> Text( text = item, modifier = Modifier.clickable { onItemClick(item) } ) } } } } ``` #### Production Standard (Correct) > **Standard**: By replacing standard `List` with `ImmutableList` and guaranteeing the class stability contract (via `@Immutable` or stability-config fencing), Compose compiler marks `OrderDetailUiState` as Stable. Strong Skipping mode executes structural equality (`.equals()`), correctly skipping recomposition when the emitted data values have not changed. ```kotlin // Model in :core:model utilizing kotlinx.collections.immutable import kotlinx.collections.immutable.ImmutableList import androidx.compose.runtime.Immutable // Option A: If Compose runtime is allowed or stability config mapping is applied @Immutable data class OrderDetailUiState( val id: String, val items: ImmutableList<String>, val timestamp: Long ) // Feature UI Composable: Stable contract allows structural equality (equals) @Composable fun OrderCard( order: OrderDetailUiState, onItemClick: (String) -> Unit, modifier: Modifier = Modifier ) { // Under Strong Skipping: OrderDetailUiState is fully Stable. // Compose compares `order` using structural equality (.equals()). // When the parent re-emits equivalent data with a new reference, recomposition is safely SKIPPED. Card(modifier = modifier) { Column { Text(text = "Order #${order.id}") order.items.forEach { item -> Text( text = item, modifier = Modifier.clickable { onItemClick(item) } ) } } } } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Jetpack Compose 1.8 Strong Skipping Mode Stability Fencing

Jetpack Compose 1.8 Strong Skipping Mode Stability Fencing defines an industrial-grade behavioral standard for mobile engineering. Enforces strict compiler stability invariants and stability fencing across multi-module boundaries under Jetpack Compose 1.8 Strong Skipping Mode. While Strong Skipping enables composables with unstable parameters to be skipped via instance equality (`===`), multi-module domain models, collections, and lambdas crossing API boundaries without explicit stability contracts cause subtle recomposition cascades, structural equality bypasses, and deferred UI jank. This standard mandates explicit `@Immutable`/`@Stable` annotations or immutable wrapper fencing, stable collection wrappers, and proper lambda memoization across architectural boundaries. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Implicit Unstable Parameter Leaks and Instance Equality Failures in Strong Skipping Compositions Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Implicit Unstable Parameter Leaks and Instance Equality Failures in Strong Skipping Compositions	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST configure Compose compiler stability configuration files (stabilityConfigurationFile) for external domain/data layer models that cannot directly depend on compose-runtime annotations.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.