Task: Implement the super administrator sign-in

The super administrator signs in and the application knows which mode the session runs in. The shell states that mode and draws the system administration landing, and the tenant management journeys are reached from it.

One thing the mode is not: a menu item. First run belongs to a plain installation, where there is no account to sign in with and no menu to draw. It is the door of that state, not a place inside the application, so nothing offers it from a menu.

• The session view and the login answer carry the mode.
• The mode is stated by the server and delivered with the session. The browser reads the field and never derives it, so a change to how the mode is decided moves no client code.
• A session in the system tenant's context reads system administration. Every other session reads application until the tenant-scoped context exists.
• The shell states the mode of the open session.
• The system administration landing lists its areas, and its Tenants area holds New tenant and Retire or reset a tenant.
• No area holds First run, and no menu offers it.
• The tenant management journeys are reachable from the landing, and the one that is built opens the screen that exists.
• A journey the catalogue holds but the tree has not built yet is drawn as not built rather than hidden, and a journey nothing may run is not drawn at all.
• Every new behaviour is proved by a test, and the tests run head-less.

Four units, in this order, because each one is what the next one reads.

1. The mode rides the session. Add it to the session view in the wire contract, and have the BFF state it when the session is created so every later read carries it. The BFF is the server from the browser's side, and it already holds the tenant the login answered with; the rule stays out of the browser. When ores.iam states the mode on login_response the BFF passes that answer through instead of computing it, and no client changes.

   The mode names a context, so the field carries the three contexts the contract lists. Only two can be decided today: the system tenant's context is system administration, and every other tenant is the application. A tenant-scoped session does not exist, so tenant administration is declared and not yet produced.

2. The menu is data, not markup. The areas each mode shows and the journeys each area holds live in one module the shell reads, so a later group adds a journey by adding a row. The journeys the catalogue holds but the tree has not built are rows too, and the screen states that they are not built rather than pretending they are.
3. The landing draws it. The home page becomes the mode's landing: the mode, the areas, and each area's journeys as cards. A journey the session may not run is absent.
4. Bootstrap leaves the menu. First run keeps the route it has, and the route table keeps sending a plain installation to it. It stops being an area.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

The super administrator signs in and the session states the context it opened in. The session view and the login answer gained mode, and the BFF decides it from the tenant the login answered with: the system tenant is system-administration and every other tenant is application. The browser reads the field and never derives it, so the rule moves to ores.iam without a client changing.

The shell states the mode, offers the areas that mode shows, and the home page is the mode's landing. System administration lands on the Tenants area, which offers New tenant — a link to the journey that is built — and Retire or reset a tenant, drawn as not built because the tree has not built it. The areas and their journeys are client data in one module, so a later group adds a journey by adding a row.

First run left the menu, and the prototype was corrected with it. It belongs to a plain installation, where nobody can be signed in, so it is the door of that state rather than a destination. The system administration menu is therefore the Tenants area alone.

What is deliberately not done, and where it goes next:

• Tenant administration is declared and not produced. The mode names a context, and a tenant-scoped session — one acting as the tenant rather than as one of its parties — does not exist. Until it does, a tenant administrator's session reads application, which is the context it is in. The application mode therefore shows no areas yet, and the home page keeps the session card it had. This is the honest half of the contract, not an omission.
• The menu does not yet take its authority from permissions. A journey's rank within a mode — a regular party user against a privileged one — needs the permission codes the session holds, and the BFF exposes none yet. Rather than guess, the application mode declares no areas. The permission read is the next unit this contract names.
• The person's own journeys are still not under their name. The avatar menu is the Profile group's work, and the shell keeps its session line and sign out until that group draws it.

Proved live, not only in tests: the harness photographs the landing the browser draws after a real sign-in against the running BFF.