User guide

This guide describes the Fortuna interface (Fortuna UI) screen by screen. It is organized by the interface’s use cases, the numbered UC-xx items in the Use Case Specification. Every use case appears exactly once, under the heading “UC-xx: name”, on the page for its area. Button names, dialog titles and messages are quoted from the application’s code, not from the specification, so they are what you will see.

Where the specification and the code disagree, this guide describes what the code does. Where a screen is not built yet, the guide says so in plain words instead of describing it as if it worked. For the rules behind the screens (what a transfer is, how installments are split, what consent covers) see Concepts. For how the interface reaches the API or the native core, see Architecture.

There is no menu

The interface has no navigation menu and no home dashboard. This is how the code stands, not a design choice the guide is working around.

• The home screen, at the address /, is a placeholder. It shows a screen titled “Overview” with the text “/ is routed and guarded. Its screen is UC-38.” and a sign-out button. The net position, projections and obligations that UC-38 describes live on their own screen, covered in Projections.
• The code contains no navigation rail, drawer or bar. Screens link to a few of their neighbours: the transactions grid opens a transaction and the record form, a credit card opens its statements, an import job opens its records, and the “set up X first” notices link to accounts, cards or categories.
• Most screens have no link pointing to them from any other screen. On the web you open them by typing their address after the instance’s address. The code contains no control that opens them on Windows, Linux or Android. This is a gap in the application as built.

Each page in this guide therefore names the address of every screen it describes, for example /accounts. Treat the address as the screen’s name.

Who can reach what

One guard decides this for every address, however it was reached: a typed web address, a link, or a session restored at start (UC-46 below). Hiding a control is never the protection: the guard and the API both refuse.

This table was checked against the application’s route table and route guard. The details:

• Until an instance address has been chosen, every address sends you to /setup, even the sign-in screen. A build made for desktop offline mode counts as chosen from the start and starts past setup, and so does a build with an instance address built in. A signed-out user can still open /setup by its address on any build.
• A signed-out request for a protected address goes to /sign-in, and the address you wanted is remembered. After you sign in you are taken there if your role may reach it.
• A pending two-factor challenge counts as signed out.
• A signed-in user who opens one of the signed-out screens is sent to the remembered destination if there is one. The destination is checked again for the role, so one the role may not reach is ignored. Otherwise the user goes home: / for an account owner, /admin for an administrator.
• An address that matches no screen shows “No screen at” followed by the address, with a “Go to the overview” button. This applies to account owners; a signed-in administrator is redirected to /admin instead, and a signed-out user to sign-in.
• /settings and /privacy are the two screens both roles share. An administrator has no way into any financial screen.

flowchart TD
    A["An address is opened"] --> B{"Instance chosen?"}
    B -- "No" --> S["/setup"]
    B -- "Yes" --> C{"Signed in?"}
    C -- "No" --> D{"Signed-out screen?"}
    D -- "Yes" --> OK["The screen opens"]
    D -- "No" --> L["/sign-in, destination remembered"]
    C -- "Yes" --> Q{"Signed-out screen?"}
    Q -- "Yes" --> M{"Remembered destination the role may reach?"}
    M -- "Yes" --> W["Sent to the remembered destination"]
    M -- "No or none" --> HM["Sent home: / or /admin"]
    Q -- "No" --> R{"Role"}
    R -- "Account owner" --> O{"Administrative address?"}
    O -- "Yes" --> H1["Sent to /"]
    O -- "No" --> OK
    R -- "Administrator" --> P{"/admin, /settings or /privacy?"}
    P -- "Yes" --> OK
    P -- "No" --> H2["Sent to /admin"]

UC-46: Guard a Route by Session and Role

This is a mechanism, not a screen: it is the guard described above. Its main flow is that a route is requested, the single central guard checks it against the current session and role, and either the screen opens or the guard redirects. Its alternatives, as built:

• An account owner who asks for /admin is sent to / and is not told the address exists.
• A request with no session goes to sign-in with the destination remembered.
• A pending two-factor challenge is treated as no session.
• The guard re-evaluates on every navigation, not only at sign-in, so a change of role takes effect on the next move.
• Manipulating the client to reveal a hidden control achieves nothing, because the guard and the API refuse the action independently.

Pages in this guide

The 47 use cases are all placed: 46 on the pages above and UC-46 on this page.

What is not built or not released

The UI README names UC-04, UC-23 and UC-35 as the use cases that remain, and GitHub agrees: their issues are open. Reading the code turned up more. This table is the whole list, and each item is explained on the page named.

Sources

This guide is written from the interface’s Use Case Specification and its code on the develop branch (the route table, the router and the feature folders under lib/features), checked on 2026-10-13. The code wins where the two differ.