docs(expo): correct drift in the verify-clerk-expo skill and feature map

.changeset/verify-expo-map-drift.md

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

.claude/skills/verify-clerk-expo/SKILL.md

@@ -138,7 +138,7 @@ test('the home UserButton opens the profile of the signed-in user', async ({ hos
 ```
 
 - `host.seedUser({ phone?, password? })` creates a `+clerk_test` user in the worktree's application. With `password: true` the user also has a password that the run generated for that user, and `user.password` holds it. Pass it to `host.fill`, as `host.fill(field, user.password!)`, and to nothing else. It prints as `<secret:password>`, `run` redacts its value from the logs it writes, and `attach` refuses a run whose files hold it. For a sign-up through the form, `host.newEmail()` returns a new address of this run, and `host.newPhone()` returns a 555-01xx number that no user holds. `host.newEmail()` claims a first name for the run on this machine, as `[email protected]`, and calls nothing. After the tests, `run` finds the user by the run tag, the last four characters of the run id, in the address.
-- `host.launch({ signedInAs?, authMode?, keepStorage?, landsOn? })` relaunches the test app and waits up to 60 seconds for its home. Every launch opens on the home, and a spec taps from there to the screen it needs, as a user does. `authMode` is the mode of every AuthView the home opens: `signIn`, `signUp`, or `signInOrUp`. A launch starts with fresh storage unless `keepStorage` is true, so a launch with no `signedInAs` is signed out and lands on the home's `Sign in` button. `host.launch()` with no argument is that launch. A launch with `signedInAs` lands on the home, which must show that user's email and user ID. When the home should show anything else, pass its locator as `landsOn`. A launch that keeps storage and has no `signedInAs` needs it. `host.launch` fails at once when the test app shows its error screen, and the error has the message on that screen.
+- `host.launch({ signedInAs?, authMode?, keepStorage?, landsOn? })` relaunches the test app and waits up to 60 seconds for its home. Every launch opens on the home, and a spec taps from there to the screen it needs, as a user does. `authMode` is the mode of every AuthView the home opens: `signIn`, `signUp`, or `signInOrUp`. A launch starts with fresh storage unless `keepStorage` is true, so a launch with no `signedInAs` is signed out and lands on the home's `Sign in` button. `host.launch()` with no argument is that launch. A launch with `signedInAs` lands on the home, which must show that user's email, user ID, and a session ID. When the home should show anything else, pass its locator as `landsOn`. A launch that keeps storage and has no `signedInAs` needs it. `host.launch` fails at once when the test app shows its error screen, and the error has the message on that screen.
 - The home lists a link to each of the test app's other screens. Signed out, it has `Sign in` (`host.app.signIn`, AuthView in a modal), `Sign in with a logo` (the same modal with a React Native logo), `Sign in full screen` (`host.app.signInFullScreen`, AuthView with no close button), `Sign in full screen with a close button`, `Custom sign-in`, `Custom sign-up`, and `Native modules`. Signed in, it has `Embedded profile` (UserProfileView inline). `Token cache` shows in both states. `homeLinks(screen)` in `specs/native.ts` has the locator of each link that `host.app` does not hold. A new screen goes in `screens/destinations.ts` and `verify/VerifyHost.tsx` of the test app and in `homeLinks`.
 - `host.expectSignedInAs(user, timeoutMs?)` waits for the home to show `Signed in as <email>`, the user's ID, and a session ID. Pass the email alone for a user that the sign-up form created. `host.expectSignedOut(timeoutMs?)` waits for the home to show `Signed out` with no user ID and no session ID. Use them for the outcome of a flow that returns to the home. `host.expectVisible(locator, what, timeoutMs?)` is the same wait for an element of an SDK view, and its message names the element with `what`. On iOS, use it for the first element a spec waits for after it submits a password, because iOS may cover the app with its `Save Password?` sheet then. When one of these waits or the wait of `host.launch` runs out, its message says what the home showed at the last reading, how many passes and screen reads the wait made, how long the slowest read took, and the error of a read that failed.
 - `host.app` has the locators of the home: `signIn`, `signInFullScreen`, `signedOut`, `signedIn`, `userId`, `sessionId`, `signOut`, and `error` for the error screen. `host.runId` is the id of the run. For a sign-up password, fill the field with `runPassword(host.runId)` from `@clerk/internal-mobile-e2e/specs/support/clerk`, two words and four digits such as `Otter-Lamp-3917`, the same in every test of the run. For an organization name that a spec types into a form, use `host.newOrganizationName()`, a word and the run tag that no other test of the run gets, as `Maple 7c1e`.
@@ -153,7 +153,7 @@ The test app shows the home again when a full-screen AuthView or a custom form c
 
 The test app has a screen or a small flow of its own only where the native views cannot prove a thing. The custom sign-in and sign-up forms drive `useSignIn` and `useSignUp`. The test app reads the `@clerk/expo` token cache once, as the app starts and before Clerk has loaded, and the `Token cache` screen says whether a client token was kept from the last launch. `Sign in with a logo` opens the home's modal AuthView with a React Native view as its `logo`. The `Embedded profile` screen is UserProfileView inline with one custom page, `isDismissible={false}`, and `onHostBack`. The `Native modules` screen has one button for `useSignInWithGoogle` and one for `useBiometricCredentials`, each with its result as text. The test app looks and behaves as an app does for a real user. When a change needs a flow that no native view covers, add a screen that a real app would have, and assert on the outcome as a user sees it.
 
-On iOS, locate nodes of the native views with the SDK's identifiers, such as `screen.getByTestId('clerk.auth.start.identifier')`. The clerk-android release that `@clerk/expo-native-components` pins has no test tags, so `specs/native.ts` finds the Android native views by text. The home has `e2e.*` testIDs, which `host.app` holds, and the test app's other screens have `verify.*` testIDs, on both platforms. All of these identifiers are internal test hooks, not public API, and they can change. Every spec keeps at least one exact assertion on an identifier or on visible text. To assert on the text of a node, use `await expect(locator).toHaveText('...')`.
+On iOS, locate nodes of the native views with the SDK's identifiers, such as `screen.getByTestId('clerk.auth.start.identifier')`. The clerk-android release that `@clerk/expo-native-components` pins, 1.3.0, sets the same `clerk.*` names as resource ids, but `specs/native.ts` still finds the Android native views by text. The home has `e2e.*` testIDs, which `host.app` holds, and the test app's other screens have `verify.*` testIDs, on both platforms. All of these identifiers are internal test hooks, not public API, and they can change. Every spec keeps at least one exact assertion on an identifier or on visible text. To assert on the text of a node, use `await expect(locator).toHaveText('...')`.
 
 A spec file that needs other settings than the standard ones has a settings file beside it, with the same name and `.settings.json` in place of `.e2e.ts`. `run` puts the application on those settings before the tests in that spec file start. Any other JSON file under `specs/` stops every run. [Test instances](references/instances.md) has the rules for a declaration.
 

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

@@ -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 and sign-in tickets only. It cannot seed organizations, roles, memberships, or invitations, so no spec can reach a choose-organization task that lists an existing membership or 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.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.

.claude/skills/verify-clerk-expo/features/native-js-sync.md

@@ -23,7 +23,7 @@ Preconditions:
 
 - **Native sign-out.** Run `integration/expo-native/bin/control-clerk-expo run native-js-sync/sign-out-from-native --platform ios`, and again with `--platform android`. The spec launches signed in, taps the UserButton, taps `Sign out` in the profile, and calls `host.expectSignedOut`. That waits for the home to show `Signed out` (from `useAuth`), with no `Signed in as` text and no user ID (from `useUser`) and no session ID (from `useSession`). Screenshots `before-sign-out` and `signed-out-from-native`.
 - **Native sign-in.** Run `integration/expo-native/bin/control-clerk-expo run native-js-sync/sign-in-from-native --platform ios`, and again with `--platform android`. Both tests seed a user with `host.seedUser({ password: true })`, tap `Sign in` on the home, and sign in with `signInWithPassword` from `specs/native.ts`. The first test expects the home to show the user and a session ID, relaunches with `keepStorage`, and expects the same user and the same session ID. Screenshots `signed-in-from-native` and `restored-home`. The second test signs out with the profile's `Sign out` row, signs in again, and expects the home to show the user. Screenshot `signed-in-again`.
-- **JS sign-in and sign-out.** `user-button-and-profile/profile` proves both. Run `integration/expo-native/bin/control-clerk-expo run user-button-and-profile/profile --platform ios`, and again with `--platform android`. The first test signs in with a ticket through `useSignIn` and expects the native profile's Manage account screen to show the user's email. The second test signs out with the home's `Sign out` button, which calls `useAuth().signOut()`, and `host.expectSignedOut` waits until the home shows no user and no session. Screenshots `profile` and `signed-out`.
+- **JS sign-in and sign-out.** `user-button-and-profile/profile` proves both. Run `integration/expo-native/bin/control-clerk-expo run user-button-and-profile/profile --platform ios`, and again with `--platform android`. The first test signs in with a ticket through `useSignIn` and expects the native profile's Manage account screen to show the user's email. The second test signs out with the home's `Sign out` button, which calls `useAuth().signOut()`, and `host.expectSignedOut` waits until the home shows no user and no session. Screenshots `user-button-profile`, `profile`, and `signed-out`.
 - **Proof.** `screenshots/signed-out-from-native.png` shows the home with `Signed out` and the `Sign in` button. The native profile closes by itself when the native user goes away. On iOS the native UserButton closes the profile it presented. On Android the UserProfileView dismisses itself, and the UserButton then hides it.
 
 ## Gotchas

.claude/skills/verify-clerk-expo/features/token-cache-persistence.md

@@ -26,7 +26,7 @@ Preconditions:
 ## Gotchas
 
 - `keepStorage: true` reuses the previous launch's `verifyStorageScope`. Without it, the test app clears Clerk's stored client on launch, so the relaunch would start signed out.
-- When the scope changes, the test app clears more than Clerk's own storage. On iOS it clears every generic-password keychain item the test app owns. On Android it deletes the `clerk_preferences` and `SecureStore` SharedPreferences files, so every `expo-secure-store` item goes.
+- When the scope changes, the test app clears more than Clerk's own storage. On iOS it clears every generic-password keychain item the test app owns, and the UserDefaults keys in which clerk-ios remembers the last identifier the start screen used. On Android it deletes the `clerk_preferences` and `SecureStore` SharedPreferences files, so every `expo-secure-store` item goes.
 - The home alone does not prove the JS token cache. Native storage could restore the session and sync it to JS, and the home would look the same. The `Token cache` screen shows what the JS cache itself held.
 - The test app reads the cache once, when the app starts and before Clerk has loaded, and the `Token cache` screen shows that answer whenever the home opens it. Do not read the cache again after Clerk loads. A signed-out client stores a client token of its own by then, so the text would say `yes` on a new scope.
 - A launch with no `signedInAs` that keeps storage needs `landsOn`, because only the spec knows that it expects a signed-in home.