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 (the 448 recovery recording). It is
reached by AccountRecoverySearch.findAccount(identifier).
The recording 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: no capture shows a request from it,
and no capture has 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 (the 448 recovery recording). It is reached byAccountRecoverySearch.findAccount(identifier).The recording 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: no capture shows a request from it, and no capture has a successful submit answer (the test pins a synthetic one).