Story: Make the shell speak to people plainly
Table of Contents
This page documents a story in Sprint 26. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
A person sees the work they can do, in their own words. The home screen shows areas and actions, never journeys; system administration is tenant management, a list with add and remove; and a tenant's details open in place, with the session that reads them held for the screen and never offered as a step.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 26 |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-04 |
3. Acceptance
- A new home screen prototype is accepted, and its record says what changed from the application shell prototype and why.
- No screen names a journey, and none asks the person to enter or leave a tenant.
- Tenants is a list with an add button and a remove button; opening a tenant shows its details, read inside the tenant for the life of the screen.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Scaffold story: Make the shell speak to people plainly | DONE | 2026-10-04 | 2026-10-04 | Story scaffolding rides this task: documents, sprint wiring, and the scaffold PR. Close it before merging that PR. |
| Prototype the home screen | DONE | 2026-10-04 | Prototype the home screen and tenant management in a person's own words, and record the accepted design. | |
| Speak plainly on home and in the shell | DONE | 2026-10-04 | 2026-10-04 | No screen says journey. The system administrator's home shows system health, what needs attention, recent setup activity and a short tenant list; status badges carry colour; the tenant administrator's and party user's homes follow the prototype. |
| Manage tenants as a list and open one in place | DONE | 2026-10-04 | 2026-10-04 | Tenants is one list with add and remove buttons. Opening a tenant shows its overview, parties and people, with the tenant session started and ended by the screen; nothing offers entering or leaving a tenant. |
| Remove a tenant | DONE | 2026-10-04 | 2026-10-04 | A system administrator removes a tenant from the list or its screen, confirming with its code. The operation terminates the tenant over the bus, and the confirmation says exactly what removal does to sign-in and to sessions already open. |
| Show faces and flags in a tenant | DONE | 2026-10-04 | 2026-10-04 | Show each person's picture on a tenant's People tab and each party's business centre flag on its Parties tab. |
| Show the system tenant | DONE | 2026-10-04 | 2026-10-04 | List the system tenant on the Tenants roster and open it like any other tenant, reading its parties and people as the session's own tenant. |
5. Decisions
- The words come from the person, not the design. No screen says journey, and no screen asks anyone to enter or leave a tenant. A tenant opens like any record.
- A tenant is read inside it for one read. The BFF enters the tenant, reads and leaves for each tab read; the tenant token never reaches the browser's session. The session's own tenant, the system tenant for a system administrator, is read as the session.
- Images ride the page's visit. A page reads the pictures and flags it names in the same visit and the BFF keeps them, so a page costs one entry.
- The system tenant is shown but never removed. The roster lists it; the web does not offer its removal and the table's check refuses it.
- Removal is the generic delete. It closes the row and keeps the data; sign-in and token refresh then refuse the tenant, so access ends within one access lifetime.
6. Out of scope
7. Result
Done: every task is merged or in its final PR.