com.bloks.www.caa.login.login_homepage, the login home of a logged-out
Android process. It is reached as the logged-out launch's first screen: the
launch's burst is the recorded pre-login bootstrap (the client-data
redirect, USDID registration, the login-home screen fetch, the phone
prefill), and the launch returns this screen's handle. The
screen itself sends nothing on entry; it shows the state the burst issued,
as the Android 448 app's pre-login flow shows it: the login form with its
two text inputs, the account-access-context token and waterfall id every
later call chains, the login entry point, and the "Forgot password" entry the
login-home action graph issued (held as an opaque ticket).
Its actions:
logIn(credentials) sends the identified login:
oauth.token.fetch with the typed username, then send_login_request (the
recorded pre-login/017 → login@fresh/018 order). Its answer continues
the process into the feed, or opens a two-factor screen, or the
last-resort recovery code screen — each as a normal edge the login home
stays under. The post-login burst registers the device's FCM/FBNS push
token (AndroidApp({ pushToken })), which the launch reads from the device:
the feed — the session exists, so the action continues the process
through the platform's recorded launch, which sends the post-login burst
and opens the feed; the handle is the feed's, and its data and actions are
the launched process's;
LoginTwoFactorApproveFromAnotherDeviceScreen — the entrypoint scheduled
the trusted-notification poll, so the app waits for the login to be
approved on another device. The action opens that screen as a normal edge
and returns its handle; the entrypoint request was already sent by the
login, and the issued poll reaches the screen as a process handoff;
LoginTwoFactorChooseMethodScreen — the entrypoint scheduled no poll, so
the server's default is another method. The login already fetched the
picker; the action opens it with the issued rows and returns its handle;
AccountRecoveryEmailCodeScreen — the answer escalated to last-resort
recovery; the action opens the code-entry screen from its process
handoff.
A wrong password and the shared flow's other refusals stay failures, and a
failed attempt forgets the escalation an earlier answer issued. The login
home's issued state is spent once the login produced any of these answers:
the 2FA screens continue from their own issued tickets and the recovery
screen from its own, never from the form's state.
createNewAccount() opens the registration's first screen,
RegistrationPhoneNumberScreen ("What's your phone number?"). The
recorded "Create new account" answer — the sign-up session's start — is
that screen's enter burst, so the transition itself sends nothing and the
login home stays under it.
recoverPassword() opens AccountRecoverySearch with that ticket and the
login home's aac.
openApproveFromAnotherDevice(), openMethodPicker() and
openEmailCode() are the transitions logIn takes after its answer; they
are public names because the trail records them. Each target takes its
issued values from the process handoff the login left, so a direct call in
a fresh process requires that handoff as a precondition (the checkpoint
work, #314).
Registration is modelled from its first screen on: createNewAccount()
opens RegistrationPhoneNumberScreen, and the registration screens carry
their own steps to the account creation. The server-decided login outcomes
other than 2FA and the last-resort recovery are not modelled: no edge is
declared for them.
com.bloks.www.caa.login.login_homepage, the login home of a logged-out Android process. It is reached as the logged-out launch's first screen: the launch's burst is the recorded pre-login bootstrap (the client-data redirect, USDID registration, the login-home screen fetch, the phone prefill), and the launch returns this screen's handle. The screen itself sends nothing on entry; it shows the state the burst issued, as the Android 448 app's pre-login flow shows it: the login form with its two text inputs, the account-access-context token and waterfall id every later call chains, the login entry point, and the "Forgot password" entry the login-home action graph issued (held as an opaque ticket).Its actions:
logIn(credentials)sends the identified login:oauth.token.fetchwith the typed username, thensend_login_request(the recordedpre-login/017→login@fresh/018order). Its answer continues the process into the feed, or opens a two-factor screen, or the last-resort recovery code screen — each as a normal edge the login home stays under. The post-login burst registers the device's FCM/FBNS push token (AndroidApp({ pushToken })), which the launch reads from the device:LoginTwoFactorApproveFromAnotherDeviceScreen— the entrypoint scheduled the trusted-notification poll, so the app waits for the login to be approved on another device. The action opens that screen as a normal edge and returns its handle; the entrypoint request was already sent by the login, and the issued poll reaches the screen as a process handoff;LoginTwoFactorChooseMethodScreen— the entrypoint scheduled no poll, so the server's default is another method. The login already fetched the picker; the action opens it with the issued rows and returns its handle;AccountRecoveryEmailCodeScreen— the answer escalated to last-resort recovery; the action opens the code-entry screen from its process handoff.A wrong password and the shared flow's other refusals stay failures, and a failed attempt forgets the escalation an earlier answer issued. The login home's issued state is spent once the login produced any of these answers: the 2FA screens continue from their own issued tickets and the recovery screen from its own, never from the form's state.
createNewAccount()opens the registration's first screen,RegistrationPhoneNumberScreen("What's your phone number?"). The recorded "Create new account" answer — the sign-up session's start — is that screen's enter burst, so the transition itself sends nothing and the login home stays under it.recoverPassword()opensAccountRecoverySearchwith that ticket and the login home's aac.openApproveFromAnotherDevice(),openMethodPicker()andopenEmailCode()are the transitionslogIntakes after its answer; they are public names because the trail records them. Each target takes its issued values from the process handoff the login left, so a direct call in a fresh process requires that handoff as a precondition (the checkpoint work, #314).Registration is modelled from its first screen on:
createNewAccount()opensRegistrationPhoneNumberScreen, and the registration screens carry their own steps to the account creation. The server-decided login outcomes other than 2FA and the last-resort recovery are not modelled: no edge is declared for them.