Jetpack Compose 1.8 Strong Skipping Mode and Parameter Stability Boundaries

--- description: Jetpack Compose 1.8 Strong Skipping Mode and Parameter Stability Boundaries - Enforces compiler-level memoization guarantees under Jetpack Compose 1.8 Strong Skipping Mode by isolating unstable external models behind Immutable value wrappers or stable UI state adapters. Prevents structural equality check failures (`equals()` mismatch) and catastrophic recomposition cascades across complex screen hierarchies. Mandates explicit stability annotations, persistent collection primitives, and lambda memoization contracts across all public composable signatures. globs: **/*.kt alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/jetpack-compose-strong-skipping-stability-guardrails" --- # Jetpack Compose 1.8 Strong Skipping Mode and Parameter Stability Boundaries > **Severity**: CRITICAL | **Category**: mobile > **Anti-Pattern Warning**: Passing Unannotated Third-Party Models and Raw Collections into Composables Under Strong Skipping Mode ## System Constraints You are a Principal Android Architect enforcing Jetpack Compose 1.8+ compiler metrics and runtime performance invariants. Mandate strict stability boundaries across all UI tree composables. Strong Skipping Mode treats unstable parameters as skippable using structural equality (`equals()`), which causes silent recomposition loops or skipped valid updates when third-party data types lack stable identity or rely on reference equality. Enforce explicit `@Immutable` and `@Stable` wrappers, Kotlinx Immutable Collections, and non-reflective memoization strategies. ## Strict Guidelines - Engineers MUST ALWAYS wrap external, multi-module, or third-party data classes in `@Immutable` or `@Stable` domain UI State wrappers before exposing them to Composables. - Engineers MUST NOT pass raw standard library collection types (`List<T>`, `Set<T>`, `Map<K, V>`) directly into public or re-used Composable parameters; use `kotlinx.collections.immutable.ImmutableList` or annotated wrapper classes instead. - Code SHOULD rely on Strong Skipping Mode's automatic instance memoization for lambdas capturing unstable values, but MUST NEVER pass newly allocated object instances or dynamic lambda captures inside tight recomposition loops without `remember`. - Composables MUST verify value-based `equals()` and `hashCode()` implementations on any data class designated `@Immutable` to ensure Strong Skipping memoization evaluates equality accurately. - Components NEVER accept mutable state holders or open inheritance models directly as Composable arguments; state must be hoised into flat, read-only UI models. ## Bad vs Good Implementations ### External Data Model and Standard Collection Anti-Pattern vs Immutable Value Wrapper #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Standard library `List<T>` is an interface and cannot be inferred stable by the Compose compiler. `ThirdPartyUser` is declared in an external package without Compose compiler metrics, forcing the runtime to execute instance-level fallback comparisons that trigger recomposition cascades across children. ```kotlin import androidx.compose.runtime.Composable // Anti-pattern: Passing external third-party DTO and raw List directly to Composable. // Even with Strong Skipping Mode, standard List is inferred unstable and // ThirdPartyUser lacks proper compiler stability contracts, causing redundant tree traversals. import com.external.sdk.ThirdPartyUser @Composable fun UserProfileCard( user: ThirdPartyUser, permissions: List<String>, onAction: (String) -> Unit ) { UserCardHeader(name = user.name) PermissionsList(items = permissions) } ``` #### Production Standard (Correct) > **Standard**: The external model is transformed into an explicit `@Immutable` data class using `ImmutableList` from `kotlinx.collections.immutable`. Strong Skipping Mode correctly skips this Composable whenever fields evaluate to equal values via structural equality. ```kotlin import androidx.compose.runtime.Composable import androidx.compose.runtime.Immutable import kotlinx.collections.immutable.ImmutableList import kotlinx.collections.immutable.toPersistentList import com.external.sdk.ThirdPartyUser @Immutable data class UserUiState( val id: String, val name: String, val permissions: ImmutableList<String> ) fun ThirdPartyUser.toUiState(permissions: List<String>): UserUiState = UserUiState( id = this.id, name = this.name, permissions = permissions.toPersistentList() ) @Composable fun UserProfileCard( state: UserUiState, onAction: (String) -> Unit ) { UserCardHeader(name = state.name) PermissionsList(items = state.permissions) } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Jetpack Compose 1.8 Strong Skipping Mode and Parameter Stability Boundaries

Jetpack Compose 1.8 Strong Skipping Mode and Parameter Stability Boundaries defines an industrial-grade behavioral standard for mobile engineering. Enforces compiler-level memoization guarantees under Jetpack Compose 1.8 Strong Skipping Mode by isolating unstable external models behind Immutable value wrappers or stable UI state adapters. Prevents structural equality check failures (`equals()` mismatch) and catastrophic recomposition cascades across complex screen hierarchies. Mandates explicit stability annotations, persistent collection primitives, and lambda memoization contracts across all public composable signatures. 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: Passing Unannotated Third-Party Models and Raw Collections into Composables Under Strong Skipping Mode 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	Passing Unannotated Third-Party Models and Raw Collections into Composables Under Strong Skipping Mode	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 ALWAYS wrap external, multi-module, or third-party data classes in `@Immutable` or `@Stable` domain UI State wrappers before exposing them to Composables.

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.