The account-recovery authentication-confirmation screen of the Android
"Forgot password" flow — the Bloks app
com.bloks.www.caa.ar.authentication_confirmation, which the search answer
pushes after the identifier is submitted (Android 448). It is
reached by AccountRecoverySearch.findAccount(identifier).
The app never moves the client endpoint on this screen: the
submit_code call still reports the search screen
(com.bloks.www.caa.ar.search as both class and module), so its endpoint
module and Android class are the search screen's and the screen changes no
endpoint the app does not report. Its enter is the search submission:
search.async with the typed identifier and the Android platform overlay
androidRecoverySearchClientInputParams; the answer's submit_code action
and context token become this screen's opaque ticket. The screen shows the
code field the answer issued; its action logInWithCode(code) submits the
received code, applies the session the accepted answer carries and continues
the process into the logged-in launch — whose 451 build ends on the
location-permission splash after an account recovery, so the action's result
is the feed or that splash. The code
input itself is not modelled beyond that: the request the app sends from it
is not known, and so is a successful submit answer (the test pins a synthetic
one).
The account-recovery authentication-confirmation screen of the Android "Forgot password" flow — the Bloks app
com.bloks.www.caa.ar.authentication_confirmation, which the search answer pushes after the identifier is submitted (Android 448). It is reached byAccountRecoverySearch.findAccount(identifier).The app never moves the client endpoint on this screen: the
submit_codecall still reports the search screen (com.bloks.www.caa.ar.searchas both class and module), so its endpoint module and Android class are the search screen's and the screen changes no endpoint the app does not report. Its enter is the search submission:search.asyncwith the typed identifier and the Android platform overlayandroidRecoverySearchClientInputParams; the answer'ssubmit_codeaction and context token become this screen's opaque ticket. The screen shows the code field the answer issued; its actionlogInWithCode(code)submits the received code, applies the session the accepted answer carries and continues the process into the logged-in launch — whose 451 build ends on the location-permission splash after an account recovery, so the action's result is the feed or that splash. The code input itself is not modelled beyond that: the request the app sends from it is not known, and so is a successful submit answer (the test pins a synthetic one).Guide: Account recovery