jetpack-compose-m3

What this skill does

## Prerequisites and compatibility

1. **Wear OS Compose Material3 version:** If an internal tool is available to establish the **latest stable version** `{VERSION}` of `androidx.wear.compose:compose-material3`, use that tool.
   - Otherwise, fetch the [official Maven metadata XML](https://dl.google.com/dl/android/maven2/androidx/wear/compose/compose-material3/maven-metadata.xml) to identify `{VERSION}` (highest number, ignoring `-alpha`, `-beta`, or `-rc`).
2. **Strict compliance:** If a version is listed as stable, you MUST use it, unless overridden by the user. Do not downgrade based on initial "Unresolved reference" errors in the editor or outdated web search results.
3. **Kotlin version:** For Wear Compose Material3, use Kotlin **2.0.0 or
   higher**.
4. **Compose compiler:**
   - If Kotlin version is **2.0.0+** , the project must use the `org.jetbrains.kotlin.plugin.compose` Gradle plugin.
   - If Kotlin version is **\< 2.0.0** , the project must use `kotlinCompilerExtensionVersion` in `composeOptions`, matching the [Compose to Kotlin Compatibility Map](https://developer.android.com/jetpack/androidx/releases/compose-kotlin).
5. **Min SDK:** Ensure `minSdk` is at least **25** (Wear OS 2.0).
6. **Sample extraction mandate**: Wear Compose libraries ship with an additional JAR file which contains individual samples for each and every component. You MUST NOT propose code changes until the samples in Capability 2 are extracted to the local cache. Library source files are incomplete and NOT a substitute for these samples; bypassing extraction is an environment setup failure.

## Gotchas

1. **Mandatory sync and validation:** After updating versions in `libs.versions.toml` or `build.gradle.kts`, you **must** perform a Gradle sync before refactoring any code. This ensures the environment has resolved the libraries correctly.
2. **Prohibition of guessing (error protocol):** If you encounter an 'Unresolved Reference' or API mismatch after a successful sync, do not attempt to 'fix' it by downgrading the library version.

## Capabilities and tools

### Capability 1: Migration

Use this guidance when migrating from an older version of Wear OS Compose or
Horologist.

1. Unless otherwise indicated by the developer, use the latest stable version of Wear Compose Material3 from `{VERSION}`.
2. Read the [migration guide](references/android/training/wearables/compose/migrate-to-material3.md).
3. Use the official component mappings from the migration guide.
4. Before refactoring any component (for example, `Chip` -\> `Button`), check the parameter names, slot types, and "Expressive" design tokens.
5. Do not use the Horologist Composables, Compose Layout, or Compose Material libraries.
6. **Always** check against the component guidance in Capability 3.
7. Expect screenshot tests to fail when a migration has been performed: Even when migrating to very similar components, expected defaults for padding and positioning will have changed. Do not seek to artificially match the pre-migration screenshot, but give preference to the Material3 defaults.

### Capability 2: Component samples

Wear Compose includes individual component samples for each and every component,
within the `<artifact>-<version>-samples-sources.jar` file. Gradle automatically
downloads these JAR files along with the main library JAR when using any of
`compose-material3`, `compose-foundation` or `compose-navigation3`.

Use the canonical component samples whenever adding or adjusting a Wear Compose
Material3 component.

STRICT COMPLIANCE: Extraction is NOT optional. You are FORBIDDEN from
implementing any code until samples are extracted and read. Bypassing this step
with alternative search tools or by assuming library documentation is sufficient
is a protocol breach. You MUST verify the local cache by reading a sample file
before proceeding.

#### Step 1: Prepare

1. Check the `build.gradle.kts` or `libs.versions.toml` to ensure the Wear Compose version matches `{VERSION}`.
2. Ensure that the necessary dependencies are downloaded by doing a Gradle sync.

#### Step 2: Check the local cache

1. Define the cache directory path: `<SKILL_ROOT>/samples/{VERSION}/`. Do NOT choose your own different location.
2. Check if this directory exists and contains subdirectories with `.kt` files.
   - **IF YES (cache hit):** Proceed to **Step 4**.
   - **IF NO (cache miss):** Proceed to **Step 3**.

#### Step 3: Check the Gradle cache

1. Sample sources are stored in the Gradle cache. To avoid slow, brute-force searches:
   - Determine the Gradle user home (usually `~/.gradle`, or check `$GRADLE_USER_HOME`).
   - The cache root is `<GRADLE_USER_HOME>/caches`. Call this `<CACHE_ROOT>`.
2. Define `{ARTIFACT}` as the items in the list `["material3", "foundation"]`. Also include "navigation3" in the list if the `androidx.wear.compose.navigation3` library is being used.
3. For each `{ARTIFACT}` in the list:

   - Construct the expected relative path segment for the library: `androidx.wear.compose/compose-{ARTIFACT}/{VERSION}`.
   - Run a targeted `find` command. Here is an example which is constructed
     for efficiency:

         find <CACHE_ROOT>/modules-2/files-2.1/androidx.wear.compose/compose-{ARTIFACT}/{VERSION}/ \
           -name "*samples-sources.jar"

4. Use this JAR as the official sample sources.

5. Extract the contents of each JAR to
   `<SKILL_ROOT>/samples/{VERSION}/{ARTIFACT}/` using `unzip -j` to flatten the
   structure.

6. Proceed **directly to step 4**.

#### Step 4: Read samples and implement

1. Read the relevant `.kt` sample files.
2. Use these official, version-matched samples as the for:
   - Required parameters and slot names.
   - Default styling and typography tokens.
   - Interactive behaviors (for example: `onClick`, `onLongClick`).
   - Component nesting (for example: `AppScaffold` -\> `ScreenScaffold`).

### Capability 3: Component guidance

**Mandatory**: Use this capability as a checklist against any component use. It
provides more holistic guidance on how to use each component in practice, beyond
the component syntax.

1. `AppScaffold` and `ScreenScaffold`
   - \[ \] Use `AppScaffold` as the outer container, with `ScreenScaffold` children.
   - \[ \] Use only **ONE** `AppScaffold` and any number of `ScreenScaffold`.
2. `ScalingLazyColumn` - Use `TransformingLazyColumn` instead.
3. `TransformingLazyColumn` - You will need the following imports:


   ```kotlin
   import androidx.wear.compose.foundation.lazy.TransformingLazyColumn
   import androidx.wear.compose.foundation.lazy.TransformingLazyColumnDefaults
   import androidx.wear.compose.foundation.lazy.rememberTransformingLazyColumnState
   // ...
   import androidx.wear.compose.material3.lazy.rememberTransformationSpec
   import androidx.wear.compose.material3.lazy.transformedHeight
   ```

   <br />

   **Canonical example**:


   ```kotlin
   val columnState = rememberTransformingLazyColumnState()
   val transformationSpec = rememberTransformationSpec()
   ScreenScaffold(
       scrollState = columnState
   ) { contentPadding ->
       TransformingLazyColumn(
           state = columnState,
           contentPadding = contentPadding
       ) {
           item {
               ListHeader(
                   modifier = Modifier
                       .fillMaxWidth()
                       .transformedHeight(this, transformationSpec)
                       .minimumVerticalContentPadding(ListHeaderDefaults.minimumTopListContentPadding),
                   transformation = SurfaceTransformation(transformationSpec)
               ) {
                   Text(text = "Header")
               }
           }
           // ... other items
           item {
               Button(
                   modifier = Modifier
                       .fillMaxWidth()
                       .transformedHeight(this, transformationSpec)
                       .minimumVerticalContentPadding(ButtonDefaults.minimumVerticalListContentPadding),
                   t