cadrumo.entrypoints.tui.installed_session module

Production composition for one installed aeat app tui workbench session.

This is the seam the installed process actually starts through. It owns the order of the session rather than any behaviour of its own: bind the adapter inventory once, read which profiles can be signed into, hand that target to the shared admission door with this surface’s credential screens as the journey, and only then bind the authenticated generation provider the root shell consumes.

Four boundaries are deliberate.

Admission is the APPLICATION’s, not this module’s. Whether a profile is unlocked – reused, resumed from its receipt, or freshly authenticated – is decided by admit_profile_session(), the same door the CLI calls. This surface once carried its own copy of that sequence, which is how the two entry points came to disagree about what being logged in means; the copy is gone and must not return.

The credential journeys are the EXISTING screens. Registration, login and passphrase rotation are composed from their owning packages through their published doors; nothing here re-implements a credential surface, retains a passphrase, or holds recovery material.

Authentication happens OUTSIDE the root application. A credential screen is a whole Textual session, so it cannot run inside the root’s event loop; the loop below therefore alternates credential sessions and workbench sessions in this synchronous frame, which is also what makes sign-out, handover, rotation and expiry return to a genuinely fresh inventory read rather than reusing the former profile-bound composition. The session those screens establish is published process-wide by the login services, so it survives the Textual worker and event loop that produced it and is the same session a later CLI invocation in the same process would see.

Availability stays truthful. A degraded or concurrently-changing profile inventory is reported as such and refuses the session; it never renders as an empty workbench, and an abandoned credential screen is an ordinary outcome rather than an error.

SESSION_COMPLETED

The session ran to a clean end, including an operator who declined it.

SESSION_INVENTORY_UNAVAILABLE

The profile inventory could not be read truthfully, so nothing was served.

compose_authenticated_account_inputs(*, profile_id, profile_label, login_choices, operation)[source]

Bind the account doors of one already-authenticated profile.

Every door here is the canonical application or credential-screen owner. Composing them performs no write and acquires no credential: the profile record read below is the projection the Profile destination renders, and the remaining doors run only when the operator invokes them.

Return type:

InstalledWorkbenchAccountInputsV1

Parameters:
compose_authenticated_root_inputs_provider(*, profile_id, profile_label, login_choices)[source]

Compose the installed root provider for one authenticated profile.

Return type:

TypeAliasType

Parameters:
run_installed_workbench_session(*, headless=False, auto_pilot=None)[source]

Run installed workbench sessions until the operator ends the process.

Each pass reads the profile inventory afresh and re-admits through the shared door. That is what makes sign-out, user handover, password rotation and session expiry return the operator to a real credential decision instead of a stale profile-bound composition – and what makes a registration, which already unlocks what it created, continue straight into the workbench.

Return type:

int

Parameters:

  • headless (bool)

  • auto_pilot (AutopilotCallbackType | None)