Skip to content

ADR-0077: Chrome is three parts, and the alarm colour stays spent on escalation

Status: Accepted Date: 2026-09-20

Decisions

D-156 Every Handler surface renders inside three chrome parts, in a fixed order

Topmost, unchanged and full width: the Escalation strip that carries ฉุกเฉิน · โทร 1669. Beneath it an appbar: a back control where there is somewhere to go back to, the surface's own title, and the Corpus freshness indicator. Beneath the page, a navigation bar.

The Escalation strip is never folded into the appbar, never reduced to an icon, and never scrolls away. It is the one control a Handler has to find without reading (D-100), and an appbar is where controls go to become equal to each other.

D-157 The navigation bar carries only destinations that need no Chemical Record

Home, Search, Recently viewed, Settings. PPE, First Aid and Spill Response are surfaces of a record — each route requires a :chemicalRecordId — so from an arbitrary screen they can only bounce to search, and a persistent control that bounces is a control that lies about where it goes.

Nothing in the navigation bar uses the alarm colour. bg-alarm is spent on the Escalation strip and on the First Run Notice's bar (D-139), and a red control anywhere else makes that one ordinary.

Context

The application had no chrome at all: DefaultLayout was the Escalation strip and a router-view. Every surface therefore carried its own title, its own way back, and no shared sense of place, and Home was the only index of anything. A Handler testing the prototype asked for the Home menu to be somewhere they could reach without going back to Home first.

Two standing rulings constrain any answer. Escalation is reachable from every surface in one action (D-100), which is why it lives in the layout rather than on pages. And the alarm colour is reserved, because the reservation is what makes the escalation path findable without reading (D-142's palette consequence).

Decision

Three chrome parts, in that order, for every Handler surface. The navigation bar takes the two destinations Home shed under D-154 and adds Home and Search, and it is drawn in neutral palette tokens only.

Rejected options

  • Put the six Home actions in the navigation bar — rejected: three of the six need a record id, so from anywhere but a record they would navigate to search while claiming to be PPE, First Aid and Spill Response; and six targets on a phone's bottom bar is a row nobody hits with a glove on.
  • An appbar with a drawer, no bottom bar — rejected: it scales to any number of destinations and makes every navigation two taps, with the destinations invisible until the first one. This product is used in a hurry.
  • Fold escalation into the appbar as a red icon — rejected: the strip is the path the Escalation Trigger accelerates, and an icon among other icons is not a path that can be found without reading.

This ruling may not be re-decided

If your change contradicts an Accepted ADR: stop and raise it. Do not implement over it. Superseding requires a new ADR that says so; never edit an Accepted one.

Consequences

Surfaces stop carrying their own titles and back controls; the appbar carries them from the route. Recently viewed and Settings become reachable from everywhere, which is what lets Home shrink to six cards (D-154).

What becomes hard: every surface now renders below two bars and above one, so the usable height drops on a phone. The Escalation strip was already spending some of it, and this adds the rest knowingly.

Coverage

No upstream finding lands here. The ruling came from a Handler's prototype test on 2026-09-20, bounded by D-100 and by the alarm-colour reservation (D-104).