Reviewing shared profile code in two React applications
Should the profile-update code in Bulletproof React's Next Pages and React/Vite applications move into a shared package? SAGE found matching schema, mutation hook and component records. Its focused tools located the consumer and exposed the available source context. Reviewing that source produces a practical sharing checklist, not an automatic approval to merge.
This case combines clone discovery, symbol search, source-bound inspection and
focused State Flow orientation. It uses SAGE v1.4.0 and Bulletproof React commit
9506629.
The selected evidence
records the exact analyzer, target, snapshot, source hashes and limits.
From matching code to a review checklist
The preserved Clone Detector output contains these pairs in the two acquired applications. Manual source comparison confirms that both the API file and the component file are byte-identical across this pair.
| Recorded pair | Source range in each application | Question before sharing |
|---|---|---|
updateProfileInputSchema, cluster 118 |
API file, lines 8–13 | Will both callers keep the same input validation? |
useUpdateProfile, cluster 52 |
API file, lines 25–40 | Will refreshing user data and forwarding the caller's success callback both remain? |
UpdateProfile, cluster 3 |
Component file, lines 13–91 | Will notification, submit-pending and drawer-completion bindings remain? |
The pinned sources are the Next Pages API and component, with their React/Vite API and component counterparts. Matching records suggest a sharing candidate; they do not establish that extracting it is appropriate or behavior-preserving.
What the focused tools add
Symbol search returned two hook definitions and two consumer import-binding
candidates, not four implementations. Focused State Flow orientation selected
useUpdateProfile with matching snapshot/live source identity. It recorded
references and import-bound call syntax, but could not resolve the useUser
export or the external useMutation target. A complete upstream/downstream
state trace was unavailable. File-level mutation context was not promoted to a
symbol-level or executed relationship.
inspect_file grounded the Next Pages component in Atlas and returned lines
13–52, explicitly marking lines 53–91 as omitted. It supplied a precise
follow-up range and kept safe_to_edit_from_inspection false. The compact
packet supports orientation without pretending that partial source is sufficient
to edit the whole component. Full source was then reviewed separately for the
checklist below.
Contracts the source review identifies
The API patches /users/profile. Its success handler calls the useUser
refetch result before forwarding the caller's optional success callback. That
call order is visible in source; completion ordering or cache correctness was
not tested. The component provides a success notification, binds isPending
to its submit indicator and isSuccess to drawer completion, supplies existing
user fields as defaults and uses the shared input schema.
Sharing those files also requires preserving their surrounding integration.
Both apps obtain useUser through configureAuth, but their route handling is
different. The Next Pages API client has a browser guard and a server-cookie
helper that the Vite client does not contain. These distinctions come from
manual source review, not resolved State Flow callees. Compare the
Next Pages auth,
Vite auth,
Next Pages API client
and Vite API client.
The resulting decision is to review a shared profile contract with explicit auth/API integration boundaries, then verify it in each app's native test environment. No extraction or target-code mutation was performed here.
Run scope and unresolved results
The analysis process completed: 56 steps completed, none failed. Acquisition
was narrower than configured: NEXTJS_PAGES indexed 149 files and REACT_VITE
143; configured MAIN indexed zero. A generic ownership-remap defect in SAGE
was subsequently repaired in development, but no second run was performed.
This remains a two-application case, not a successful three-project comparison.
The same run's quality gate was FAIL: proof-obligation verification was 0.9 against a 0.95 threshold, and one required proof failed against an allowance of zero. A manual-review-count check also failed but was not enforced in the non-comparative workspace. These are retained governance results, not adjudicated Bulletproof React defects.
Merge reported zero candidates and Nanometric Diff was not applicable; this is not a non-empty Merge demonstration. Test Impact returned no tests in the selected scope, which does not prove that relevant tests do not exist. No target tests, components or runtime probes were executed. There is no measured accuracy, time saving or verified behavior-preservation claim.
Bulletproof React is an independent MIT-licensed project. This case links to pinned source rather than redistributing its implementation and does not imply maintainer endorsement. See the wider claims/evidence matrix for the distinction between current product capabilities and roadmap work.