Const InternalThe login home's "Create new account": the registration's first screen,
"What's your phone number?". The recorded button answer
(aymh_create_account_button.async) is the target screen's enter, so the
transition itself sends nothing; the login home stays under it.
The identified login: oauth token fetch with the typed username, then
send_login_request. Its answer continues the process into the feed, or
opens the two-factor approval screen or the method picker, or the
last-resort recovery code-entry screen — each as a normal edge the login home
stays under. The handle it takes its edges from is the login home's own frame
(LoginHomepageFrame), so each edge returns a handle back()-typed to that
frame without an assertion.
One login runs at a time: a second call while this attempt is still deciding is refused with LoginPendingError before anything is sent.
The transition into the two-factor approval screen when the login answer's
entrypoint schedules the trusted-notification poll. A normal screen edge from
the login home: the login home stays under the approval screen, back()
returns to it and a trail records the step. The edge takes no input: the
challenge and the entrypoint's issued poll reach the target as a process
handoff (TwoFactorTickets.handOffApproval), never as an edge argument a
trail would carry. logIn is the transition's normal caller; taking it
directly in a fresh process requires that handoff as a precondition (the
checkpoint work, #314, is what carries a pending challenge between
processes). The target is the catalog's 2FA entrypoint screen
(com.bloks.www.two_step_verification.entrypoint, shown in the CDS
container).
The transition the login takes into the last-resort-recovery code-entry
screen. logIn takes it when the answer escalates, after handing the issued
entrypoint values to the screen through the process registry — the ticket is
client state, never an edge argument, so the trail step carries nothing and a
retrace in a fresh process is given the handoff as a precondition, like the
two-factor chain (#314 carries both across processes).
The transition into the method picker when the login answer's entrypoint
schedules no approval poll — the server's default is another method (the
authenticator app, WhatsApp, SMS or a backup code), so the app goes straight
to "Choose a way to confirm it’s you". The login answer already fetched the
picker's rows and its selection QPL; they reach the screen as a process
handoff (TwoFactorTickets.handOffPicker), never as an edge argument, and
the trail step carries nothing. The target is the catalog's method-picker
screen (com.bloks.www.two_step_verification.method_picker).
The login home's "Forgot password": the account-recovery search screen, with the opaque ticket of the action the launch issued and the aac its process state holds. The screen refuses with the recovery step's own error when the action graph issued no entry.
The login home's actions, keyed exactly as the frame carries them.