Dialogs

A dialog interrupts, so it is the last resort, not the default container. It is right for three things only: confirming an action that cannot be undone, a short focused task the person must finish or cancel (creating a hub), and a decision the app cannot proceed without (a new version is ready). Settings, filters and anything adjusted while looking at the content open inline, in a popover or in a side panel with a live preview — never a modal.

• Undo before confirm. A destructive action that can be reversed (a soft delete) runs at once and offers Undo for 30 seconds. A confirm dialog is reserved for what cannot be taken back: a payment, a permanent deletion, a message sent to other people.
• Say what happens. The title names the action ("Delete this hub?"); the body is one or two sentences on what will happen and what cannot be recovered. No "Are you sure?" with nothing else.
• The confirm button carries the verb ("Delete hub", "Send"), never "OK" or "Confirm". A destructive confirm is btn-danger; cancel is a quiet button beside it.
• Button order: from sm up the actions sit right-aligned with the primary last; on phones they stack full width with the primary on top, next to the thumb.

Behavior — every dialog, every platform:

1. It is announced as a dialog and labelled by its title (role="dialog", aria-modal, aria-labelledby on the web).
2. Focus moves into the dialog when it opens and stays inside it while it is open.
3. Escape closes it, as Cancel does; so does a tap on the backdrop, except while a submit is in flight.
4. Focus returns to the control that opened it when it closes.
5. The page behind does not scroll.

The browser's window.confirm is never used: it cannot be styled, translated or tested, and it blocks the page.