Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/javascript/src/api/__tests__/getScim2Me.test.ts`:
- Around line 24-37: The test fixture for getScim2Me uses a broad Record<string,
unknown> shape, which leaves mockUserResponse.attributes typed as unknown and
triggers the unsafe spread in mockUser. Update the mock definitions in
getScim2Me.test.ts so mockUserResponse has an explicit attributes type (or use
satisfies with a precise interface), and keep mockUser built from that strongly
typed attributes object to satisfy the lint rule.

In `@packages/javascript/src/api/__tests__/updateMeProfile.test.ts`:
- Around line 54-62: The test assertions are reading mocked fetch calls through
an untyped/any path, which is triggering ESLint. In the updateMeProfile test
cases, cast the first entry from Mock.mock.calls to a typed tuple like [string,
RequestInit] before destructuring, and use the typed RequestInit/body access for
JSON.parse instead of going through any. Apply the same cleanup in the other
affected assertions as well, using the existing fetch mock and RequestInit
references to keep the types explicit.

In `@packages/javascript/src/api/getScim2Me.ts`:
- Around line 137-142: The normalization block in getScim2Me currently spreads
user['attributes'] directly, which lets the index signature collapse
processedUser and the return value to any. Narrow or cast attributes to a
concrete object type before flattening inside getScim2Me, then build
processedUser from that typed value and pass the typed result into
processUserUsername so the new path stays lint-clean.

In `@packages/javascript/src/api/updateMeProfile.ts`:
- Around line 144-149: The update path in updateMeProfile currently spreads
user['attributes'] directly, which leaves the merged result unsafe and triggers
no-unsafe-assignment/no-unsafe-return. Narrow or type attributes as an object
before constructing processedUser, then return the typed flattened user through
processUserUsername so the helper stays type-safe like the read path.
- Around line 113-116: The request setup in updateMeProfile should not allow
callers to override the new PUT contract. In the requestInit object used by
updateMeProfile, ensure the spread of requestConfig happens before the method
assignment, or explicitly reassign method after spreading, so a caller cannot
pass a different HTTP verb and bypass the /users/me PUT migration.

In `@packages/react/package.json`:
- Around line 54-58: The devDependencies block in package.json has a duplicated
`@vitest/browser-playwright` entry, which creates an invalid/ambiguous manifest.
Remove one of the duplicate entries from the package manifest and keep only a
single `@vitest/browser-playwright` key alongside the other devDependencies.

In `@packages/react/src/components/presentation/UserProfile/BaseUserProfile.tsx`:
- Around line 145-147: The useEffect in BaseUserProfile is overwriting the
entire editedUser state whenever flattenedProfile or profile changes, which
clobbers other in-flight edits tracked by editingFields. Update this sync logic
so it only merges in refreshed values for fields that are not currently being
edited, or skip resetting editedUser while any field is dirty. Keep the fix
localized to the BaseUserProfile state synchronization path around setEditedUser
and editingFields.

In `@packages/react/src/components/presentation/UserProfile/UserProfile.tsx`:
- Around line 78-87: The `updatedAttributes` merge in `UserProfile` is shallow,
so nested patches from `BaseUserProfile` (for example `name.givenName`)
overwrite sibling fields in `attributes`. Update the merge logic to deep-merge
`payload` into the existing `profile['attributes']` document instead of using a
top-level spread, and keep the existing cleanup that removes `undefined`/`null`
values before the `PUT`.

In `@packages/react/src/contexts/ThunderID/ThunderIDProvider.tsx`:
- Around line 21-29: The ThunderIDProvider import list includes an unused
HttpResponse symbol, which keeps the lint error active. Remove HttpResponse from
the imports in ThunderIDProvider so the remaining symbols like
ThunderIDRuntimeError, generateFlattenedUserProfile, and UserProfile are the
only referenced imports.
- Around line 59-109: The hardcoded DEFAULT_USER_PROFILE_SCHEMAS in
ThunderIDProvider is causing BaseUserProfile to render only the six built-in
fields and hide any custom or extension profile attributes. Update the schemas
flow so it comes from the authoritative profile metadata when available, or keep
schemas empty when using the flattened object from
generateFlattenedUserProfile(), ensuring BaseUserProfile can still surface all
non-default fields.
- Around line 214-227: In ThunderIDProvider’s user-profile load flow, the
/users/me failure path is leaving profileData populated from claims only, which
makes the profile editable without a full attributes snapshot. Update the logic
around getScim2Me and the subsequent setUser/setUserProfile so that, when the
fetch fails, you either keep the previously fetched profile.attributes state or
mark the profile as read-only instead of falling back to a claims-only editable
profile. Make sure the downstream PUT /users/me merge path still has a complete
attributes object, using the existing profileData, generateFlattenedUserProfile,
and DEFAULT_USER_PROFILE_SCHEMAS flow as the key points to adjust.

---

Outside diff comments:
In
`@packages/react/src/components/auth/Callback/__tests__/TokenCallback.test.tsx`:
- Around line 23-47: The TokenCallback test fixture is using an unsafe any-typed
context object, which causes type-checking issues in the assertions and render
setup. Update the thunderIDContext declaration to use ThunderIDContext (or a
compatible typed shape) and keep the existing mocked methods like
getStorageManager, signIn, and signUp typed accordingly so the test exercises
the real context contract without unsafe assignments.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/react/src/contexts/ThunderID/ThunderIDProvider.tsx`:
- Around line 59-107: The default user profile schema in ThunderIDProvider is
still using snake_case keys, which no longer match the /users/me contract.
Update DEFAULT_USER_PROFILE_SCHEMAS to use the camelCase attribute names
expected by the read/write flow and tests, and make sure the corresponding
schema entries in ThunderIDProvider stay consistent with the values used when
hydrating and saving the profile.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/javascript/src/api/updateMeProfile.ts`:
- Around line 106-108: The updateMeProfile helper is still wrapping any runtime
payload directly into attributes, so non-object values can slip through. Add a
guard in updateMeProfile before building the data object to reject null, arrays,
and primitives, and only proceed when payload is a plain object. Use the
updateMeProfile payload handling around the attributes assignment to locate the
change and make the validation happen before the request body is constructed.
- Around line 113-120: The updateMeProfile request setup is merging
requestConfig.headers with object spread, which loses values when headers is a
Headers instance or header tuples. In updateMeProfile, normalize
requestConfig.headers with new Headers(...) before adding Accept and
Content-Type so existing auth/routing headers are preserved in the RequestInit
headers.

In
`@packages/react/src/components/auth/Callback/__tests__/TokenCallback.test.tsx`:
- Around line 73-77: The shared test fixtures in TokenCallback.test.tsx are
still typed as any, which keeps the unsafe-assignment warnings around the render
setup. Update the reusable ThunderIDContext fixture and the onNavigate/onError
callback mocks to use real types inferred from TokenCallback and
ThunderIDContext, then reuse those typed fixtures across all test cases so the
render calls no longer rely on any.

In `@packages/react/src/components/presentation/UserProfile/BaseUserProfile.tsx`:
- Around line 145-159: The sync logic in BaseUserProfile’s useEffect and
setEditedUser currently starts from prev, so keys that disappear from nextUser
remain in editedUser. Update the merge in this effect to rebuild the edited
state from the refreshed profile and remove any non-editing fields that are no
longer present in nextUser, while still preserving fields currently being edited
via editingFields.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/react/src/components/presentation/UserProfile/BaseUserProfile.tsx`:
- Around line 660-669: The profile entry rendering in BaseUserProfile is forcing
every synthesized field schema to READ_WRITE, which makes immutable attributes
appear editable. Update the profileEntries map logic to preserve each field’s
original mutability from the source schema (or explicitly mark non-editable
attributes as read-only) before passing schemaWithValue to renderUserInfo, and
align the readonlyFields/fieldsToSkip handling so IDs, timestamps, and other
immutable fields are not exposed as editable.

In `@packages/react/src/components/presentation/UserProfile/UserProfile.tsx`:
- Line 24: The UserProfile component has an unused getUsersMe import that
triggers lint failures; remove the getUsersMe import from UserProfile.tsx and
keep the rest of the component unchanged. Use the UserProfile component and the
getUsersMe import statement as the symbols to locate the unused reference.

---

Outside diff comments:
In `@packages/vue/src/ThunderIDVueClient.ts`:
- Around line 98-113: The getUser flow in ThunderIDVueClient currently calls
getUsersMe with only baseUrl, so it falls back to instanceId = 0 and can use the
wrong HTTP client. Update the getUser method to forward this.getInstanceId() to
getUsersMe, matching the behavior used by getUserProfile and preserving the
correct client context for non-zero Vue instances.

---

Nitpick comments:
In `@packages/javascript/src/api/getUsersMe.ts`:
- Around line 93-107: The `getUsersMe` validation catch block uses an
implicitly-typed `error` and unsafe `error?.toString()`, so update the
`try/catch` in `getUsersMe` to type the catch binding properly and safely derive
the message before constructing `ThunderIDAPIError`. Also change the `fetchFn`
assignment in `getUsersMe` to use `fetcher ?? fetch` instead of `fetcher ||
fetch`, since `fetcher` is a function reference and should only fall back when
it is nullish.

In `@packages/react/src/api/getUsersMe.ts`:
- Around line 80-102: The getUsersMe helper is using an unnecessary async
wrapper and a fallback check that should preserve valid falsy values. Update
getUsersMe and its defaultFetcher so the outer function is no longer marked
async if it only returns baseGetUsersMe, and replace fetcher || defaultFetcher
with fetcher ?? defaultFetcher. Keep the FetchHttpClient.getInstance and
baseGetUsersMe wiring intact while adjusting only the async handling and nullish
fallback.

In `@packages/vue/src/ThunderIDVueClient.ts`:
- Around line 141-146: The error fallback in ThunderIDVueClient.getProfile is
decoding the ID token twice by calling getDecodedIdToken() separately for
flattenedProfile and profile. Update the catch block to await
getDecodedIdToken() once, store the decoded token in a local variable, and reuse
that value for both extractUserClaimsFromIdToken calls so the fallback builds
identical claims from a single decode.