docs(expo): name clerk-ios 1.6.2 as the release the Expo verify skill describes

The podspec pins clerk-ios 1.6.2 since #10457, but the feature map still
named 1.6.1 in three places.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WtSUsr2bQHRBPVkDbpNPnm

Author: claude

.changeset/verify-expo-clerk-ios-pin.md

@@ -0,0 +1,2 @@
+---
+---

.claude/skills/verify-clerk-expo/features/README.md

@@ -32,7 +32,7 @@ This directory is the maintained source for verifying the user-facing behavior o
 | Sign-up code field                          | `clerk.auth.signUp.code`                                        | `verify.customSignUp.code`, then `verify.customSignUp.verifyCode`      |
 | Close AuthView                              | `clerk.dismissButton`                                           | none                                                                   |
 
-The iOS identifiers come from `Sources/ClerkKitUI/Components/Auth/ClerkAccessibilityIdentifiers.swift` in the clerk-ios release that `packages/expo-native-components/ios/ClerkExpo.podspec` pins, which is 1.6.1. The Android names are the same, from `ClerkTestTags` in the clerk-android release that `packages/expo-native-components/android/build.gradle` pins, which is 1.3.0. That release sets them as resource ids on AuthView and UserProfileView. Android specs still find native views by their text. The custom-flow testIDs live in `integration/templates/expo-native/screens/`.
+The iOS identifiers come from `Sources/ClerkKitUI/Components/Auth/ClerkAccessibilityIdentifiers.swift` in the clerk-ios release that `packages/expo-native-components/ios/ClerkExpo.podspec` pins, which is 1.6.2. The Android names are the same, from `ClerkTestTags` in the clerk-android release that `packages/expo-native-components/android/build.gradle` pins, which is 1.3.0. That release sets them as resource ids on AuthView and UserProfileView. Android specs still find native views by their text. The custom-flow testIDs live in `integration/templates/expo-native/screens/`.
 
 ## Driving conventions
 
@@ -61,4 +61,4 @@ Each feature file starts with an H1 title and one paragraph describing the user-
 
 Not mapped yet: SSO through `useSSO` (no real OAuth on simulators), a Google or Apple native sign-in with a real account, passkeys, enrolling or using a biometric (no associated domains or Secure Enclave on the simulator), and session tasks in the native views.
 
-Organizations have no page, because a user of the test app has no way to reach organization UI. This holds for the native components only. `@clerk/expo/web` exports the clerk-js OrganizationProfile, OrganizationSwitcher, OrganizationList, and CreateOrganization for Expo web, but the test app runs native only. `@clerk/expo-native-components` exports AuthView, UserButton, and UserProfileView and no OrganizationSwitcher or OrganizationProfileView. The profile that the UserButton opens lists `Manage account`, `Security`, `Add account`, and `Sign out`, with `Switch account` once a second session exists, and no organization row, in clerk-ios 1.6.1 and clerk-android 1.3.0, though the standard settings turn organizations on. The one organization screen that a native view shows is a session task in AuthView, choose or create an organization, which needs `force_organization_selection` on. The harness seeds users, sign-in tickets, and, through `host.seedOrganization`, organizations whose members hold one of the harness roles. It cannot seed invitations, so no spec can reach a choose-organization task that lists an invitation. Today such a state can be shown only with a local patch that is not committed, and the description of the pull request that shows it says so.
+Organizations have no page, because a user of the test app has no way to reach organization UI. This holds for the native components only. `@clerk/expo/web` exports the clerk-js OrganizationProfile, OrganizationSwitcher, OrganizationList, and CreateOrganization for Expo web, but the test app runs native only. `@clerk/expo-native-components` exports AuthView, UserButton, and UserProfileView and no OrganizationSwitcher or OrganizationProfileView. The profile that the UserButton opens lists `Manage account`, `Security`, `Add account`, and `Sign out`, with `Switch account` once a second session exists, and no organization row, in clerk-ios 1.6.2 and clerk-android 1.3.0, though the standard settings turn organizations on. The one organization screen that a native view shows is a session task in AuthView, choose or create an organization, which needs `force_organization_selection` on. The harness seeds users, sign-in tickets, and, through `host.seedOrganization`, organizations whose members hold one of the harness roles. It cannot seed invitations, so no spec can reach a choose-organization task that lists an invitation. Today such a state can be shown only with a local patch that is not committed, and the description of the pull request that shows it says so.

.claude/skills/verify-clerk-expo/features/native-auth-view.md

@@ -36,7 +36,7 @@ Preconditions:
 
 - On iOS AuthView renders inline, where SwiftUI's `dismiss` has no effect, so `@clerk/expo-native-components` calls `onDismiss` from the close button itself. That holds for the full-screen AuthView and for the one in the home's modal, which the home closes from that `onDismiss`. The modal's `onRequestClose` handles only the Android back button and an iOS swipe down. The `dismiss` test covers the full-screen close button, and `close-modal` covers the modal's.
 - clerk-ios AuthView remembers the last identifier in UserDefaults. The test app clears it on every new storage scope, so the field starts empty. A prefilled field shows as two `clerk.auth.start.identifier` nodes (label and textbox) and fails a locator with `LOCATOR_AMBIGUOUS`. If that happens, the test app's scope clearing regressed.
-- `@clerk/expo-native-components` ships the clerk-ios release pinned in `packages/expo-native-components/ios/ClerkExpo.podspec` (1.6.1), so iOS has the `clerk.auth.*` identifiers. It ships clerk-android 1.3.0, pinned in `packages/expo-native-components/android/build.gradle`. That release sets the same `clerk.*` names as resource ids on AuthView. Android specs still find AuthView by its text (`Enter your email or username`, `Continue`), in `specs/native.ts`. Switch those locators to `getByTestId` once a run shows the resource ids in the screen tree.
+- `@clerk/expo-native-components` ships the clerk-ios release pinned in `packages/expo-native-components/ios/ClerkExpo.podspec` (1.6.2), so iOS has the `clerk.auth.*` identifiers. It ships clerk-android 1.3.0, pinned in `packages/expo-native-components/android/build.gradle`. That release sets the same `clerk.*` names as resource ids on AuthView. Android specs still find AuthView by its text (`Enter your email or username`, `Continue`), in `specs/native.ts`. Switch those locators to `getByTestId` once a run shows the resource ids in the screen tree.
 - The test app puts nothing above, below, or over AuthView. On iOS the screen tree leaves out what a modal covers, so the home's nodes are not in the tree while the modal AuthView is up.
 - On Android, an AuthView that can be dismissed shows a close button with the label `Close`, and `Sign in full screen` shows none. No spec taps that button. The back button closes the AuthView that the home opened.
 - The standard settings have the email link off, because a test address gets no mail, so a run has no link to follow. With the link on, AuthView opens the email link screen first (`Open email app`), which has no code field, and a spec that expects `clerk.auth.signIn.code` right after Continue times out. A spec that needs the link declares `auth_email.sign_in_strategies` in a settings file.