StellarHyperion / stellarhyperion-frontend

# Hyperion app
The front end for a router that moves money between Stellar and the EVM chains.
The product's claim is narrow and specific: Hyperion never decides for itself that a cross-chain
message is real. It prices four rails that already made that decision and were audited for it,
takes the one that lands the most money, and tells you what the other three would have cost. The
whole design of this app exists to make that claim checkable rather than just stated, which is why
the centrepiece is a diagram of four rails with the losers still drawn and their reasons attached.
## The design is a set of decisions, not a theme
Five axes were rolled once, before any code, and locked. The plan lives at
`.planning/DESIGN-TOKENS.md` in the project directory, outside this repository, and it is not
re-rolled. What follows is each roll and why it survived contact with the subject matter.
**Two hues, and they mean something.** Deep ink, copper, and a cold instrument blue. A bridge has
exactly two halves. Copper is the leg you control: Stellar, where a ledger closes every five
seconds and finality means finality. Instrument blue is the leg you wait on. The copper to blue
gradient on the winning track in the switchyard is the transfer, and the crossing point is where
custody stops being yours. The palette encodes the product rather than decorating it.
**One column, read top to bottom.** A transfer is a linear journey across a boundary, so the page's
vertical axis is the journey: origin leg, switchyard, destination leg. The coloured rule down the
left of each leg is that leg's own hue, and the yard in between is where one becomes the other, so
scrolling the page is following the money. Nothing is in a sidebar, because nothing about a
transfer happens beside it. This is also the roll that rejects the dashboard reflex, which is the
default shape for anything with numbers in it and the wrong shape for this.
**Monospace is the working face, not code decoration.** Archivo for display and prose, IBM Plex
Mono for every amount, address, nonce, chain id, ledger sequence, status word and label. Almost
every fact in a bridge interface is a number or an identifier, so making mono the label and data
face gives the whole thing instrument panel character with no illustration budget at all.
**Motion only ever means a state changed.** The switchyard's winning track draws itself when a
quote resolves. That is close to all of it. No scroll reveals, no fade and slide on every section,
no ambient pulse, no lift on hover. In a product where money moves, motion that does not mean
"something changed" is a lie about whether anything did. `prefers-reduced-motion` collapses every
duration to zero, so a transition becomes an instant state swap rather than a fast one, which is
the right collapse: a faster version of a thing somebody asked not to see is not a compromise.
**One structural device: the switchyard.** A live SVG interchange. Four tracks fan out of an origin
node, run parallel,