@@ -221,7 +221,7 @@ Every matrix uses `fail-fast: false`, so a Windows failure never hides the macOS
 - **`npm test` is separated from the end-to-end suite by filename, not by directory.** `node --test` is run with no path at all, so it walks the whole repository and collects by name: `*.test.cjs` and four other shapes Node treats as test files — `*-test.cjs`, `*_test.cjs`, `test-*.cjs`, `test.cjs`. The journeys are `*.spec.js`, which matches none of them. Now that both suites live under `tests/`, that naming is the only thing keeping them apart, and a file under `tests/e2e/` named any of the five would silently join the fast suite and cost it an app launch. **End-to-end files are `.spec.js`.** The separation is worth defending: the fast suite has to stay something you run without thinking.
 - End-to-end selectors read the text and roles already on screen. No `data-testid` — the visible copy is the contract, and renaming a button is a change worth noticing.
 - Journeys run in the `en-US` locale, the source language, so no translation catalog loads and they read English text as written. The exception is `tests/e2e/journeys/i18n.spec.js`, which launches with `lang: 'en-XA'` (Chromium's pseudo-locale) and fails on any visible text that did not go through `__()`. See [Translatable strings](CONTRIBUTING.md#translatable-strings).
-- What is on screen is named once, in `tests/e2e/helpers/ui.cjs`, for the journeys, the other end-to-end specs and `scripts/screenshots/` alike, so renaming a button or rebuilding a card is one change. It holds every control that more than one of those files reaches, and the locators that find a part of the screen rather than something to press: the rendered app, an entry of the sites list, what a window with no site says, the open site's heading, a card, the work-item card with its heading and its ticket's number, and a ticket's row. A sentence one journey asserts, a button only one journey presses, and a selector only one file needs stay in that file: they are what it is about.
+- What is on screen is named once, in `tests/e2e/helpers/ui.cjs`, for the journeys, the other end-to-end specs and `scripts/screenshots/` alike, so renaming a button or rebuilding a card is one change. It holds every control that more than one of those files reaches, and the locators that find a part of the screen rather than something to press: the rendered app, an entry of the sites list, what a window with no site says, the open site's heading, a card, the work-item card with its heading and its ticket's number, a ticket's row, the question asked before a deletion, and the window's confirmations. A sentence one journey asserts, a button only one journey presses, and a selector only one file needs stay in that file: they are what it is about.
 - No test reads a component's source, the `.jsx` under `src/renderer/`, as text. A test that greps the component for a call, a literal or the order of two strings pins the file rather than the screen: it goes red when the code moves and stays green when the screen is wrong. What is on the page and where, a journey asserts, with order read as document order rather than from bounding boxes (the page scrolls as cards appear). How a component is allowed to be written, a lint rule asserts: `react-hooks/refs` is on for the renderer for that reason.
 - Journeys mark each assertion as an **invariant** (must hold under any model of how work is stored) or a **characterisation** (true because of how the app stores things today). A red invariant is a bug; a red characterisation is a prompt to read it and update it deliberately.
 - A journey that needs something only a running process would say, a mail caught or a server's address, says it itself: `webContents.send` from `app.evaluate`, on the channel and in the shape the real sender uses. Check the payload against both ends, the handler in `src/preload.js` and the place `src/main.js` sends it, and say in the test what the stand-in leaves out, such as the store write the real sender makes first. To assert that the page did *not* react, wait until it has heard: after the telling, ask the main process one more question from the page (`window.api.getSitesWithMeta()` is a plain read) and assert once that answer is back. An absence read before then passes whatever the app does.
 
@@ -28,7 +28,7 @@ While the clone runs, the site view shows a **Setting up new site…** card with
 
 The clone is the first step of the [initial setup checklist](./setup-wizard); the remaining steps stay locked until it finishes. Then the app carries on by itself — installing the dependencies and running the first build without waiting for you — so the only step left to click is starting the dev server.
 
-If setup fails, the half-created site is removed from the list — the row simply disappears. The reason goes to the application log rather than to a dialog, so **Help → Open App Log** is where to look when a site never finishes.
+If setup fails, the half-created site is removed from the list — the row simply disappears. The reason is said in a red notice in the bottom corner of the window. Unlike a green one, it does not go away after a few seconds: it waits to be dismissed. The setup's own output is in the application log: **Help → Open App Log** is where to look for the detail.
 
 ## Where sites live on disk
 
 
@@ -51,7 +51,9 @@ function FolderField({ value, disabled, onChoose, onFiles }) {
 // the dialog's popup, which is there while the dialog is open, and for the
 // moment it takes to fade once it is closed, and not otherwise. So the
 // answers are empty every time, on Core, however the last ones were left.
-function CreateSiteForm({ formId, submitting, error, onError, onCreate }) {
+function CreateSiteForm({ formId, submitting, onCreate }) {
+  // Which answer is missing, said under the form.
+  const [error, setError] = useState('');
   const [name, setName] = useState('');
   const [dir, setDir] = useState('');
   const [type, setType] = useState(DEFAULT_PROJECT_TYPE);
@@ -62,10 +64,10 @@ function CreateSiteForm({ formId, submitting, error, onError, onCreate }) {
       const chosen = await window.api.chooseDirectory();
       if (chosen) {
         setDir(chosen);
-        onError('');
+        setError('');
       }
     } catch {}
-  }, [onError]);
+  }, []);
 
   // Not reached by the intended route, which is the system's dialog above:
   // a folder dropped on the input arrives here.
@@ -77,16 +79,16 @@ function CreateSiteForm({ formId, submitting, error, onError, onCreate }) {
       setDir(resolved);
       // Clearing the error only when there is a directory: a selection that
       // resolved to nothing has not fixed anything the message was about.
-      if (resolved) onError('');
+      if (resolved) setError('');
     }
     input.value = '';
-  }, [onError]);
+  }, []);
 
   const submit = (event) => {
     event.preventDefault();
     const problem = createSiteProblem({ name, dir });
     if (problem) {
-      onError(problem);
+      setError(problem);
       return;
     }
     onCreate({ name: name.trim(), dir, projectType: type });
@@ -145,22 +147,18 @@ function CreateSiteForm({ formId, submitting, error, onError, onCreate }) {
  * one, from the notice on a site the old engine made, and is then inert and
  * stays until the setup has ended, as it did before it was redrawn.
  *
- * The one message under the form is the caller's, not the dialog's: `error`
- * is shown and `onError` sets it. The dialog's complaint about a missing
- * answer and the reason a setup failed are the same line, and the second can
- * arrive while the dialog is open, or after it has closed and before it
- * opens again. Two copies of it, one here and one there, lose one or the
- * other.
+ * The message under the form is the dialog's own complaint about a missing
+ * answer. Why a setup failed is not said here: the dialog that asked for it
+ * closed as it began, and the window says it in its corner (#557), whether
+ * or not a dialog happens to be open by then.
  *
  * @param {Object}   props
  * @param {boolean}  props.open       Whether the dialog is open.
  * @param {boolean}  props.submitting A setup is running.
- * @param {string}   props.error      The message under the form, or ''.
- * @param {Function} props.onError    Sets that message.
  * @param {Function} props.onCreate   Given `{ name, dir, projectType }` once every answer is there.
  * @param {Function} props.onClose    Asked for by the close button, Escape, or a press outside.
  */
-export function CreateSiteDialog({ open, submitting, error, onError, onCreate, onClose }) {
+export function CreateSiteDialog({ open, submitting, onCreate, onClose }) {
   const formId = useId();
   return (
     <Dialog.Root
@@ -181,7 +179,7 @@ export function CreateSiteDialog({ open, submitting, error, onError, onCreate, o
           <Dialog.Title>{__('Create site')}</Dialog.Title>
           {submitting ? null : <Dialog.CloseIcon />}
         </Dialog.Header>
-        <CreateSiteForm formId={formId} submitting={submitting} error={error} onError={onError} onCreate={onCreate} />
+        <CreateSiteForm formId={formId} submitting={submitting} onCreate={onCreate} />
       </Dialog.Popup>
     </Dialog.Root>
   );
 
@@ -0,0 +1,51 @@
+import { useCallback, useEffect, useRef } from 'react';
+import { __ } from '@wordpress/i18n';
+import { Notice } from '@wordpress/ui';
+import { toastView } from '../confirmations.cjs';
+
+// One confirmation. It says itself as it appears, politely or at once as the
+// queue decided, and one that clears itself does so when its time is up. Any
+// of them can be dismissed before that.
+function Toast({ notice, onRemove, onDismiss }) {
+  const { intent, lifetime } = toastView(notice);
+  useEffect(() => {
+    if (!lifetime) return undefined;
+    const timer = setTimeout(() => onRemove(notice.id), lifetime);
+    return () => clearTimeout(timer);
+  }, [lifetime, notice.id, onRemove]);
+  return (
+    <Notice.Root intent={intent} politeness={notice.politeness} spokenMessage={notice.content}>
+      <Notice.Title>{notice.content}</Notice.Title>
+      <Notice.CloseIcon onClick={() => onDismiss(notice.id)} />
+    </Notice.Root>
+  );
+}
+
+/**
+ * The window's confirmations (#253, #557), stacked in its corner: that an
+ * action worked, or that one the contributor is no longer looking at did
+ * not. The newest is the nearest to the corner.
+ *
+ * It draws the queue it is given. Which messages are in it, how each speaks
+ * and whether it stays are decided in confirmations.cjs.
+ *
+ * @param {Object}   props
+ * @param {Array}    props.notices  The queue's notices, oldest first.
+ * @param {Function} props.onRemove Takes a notice out of the queue, by its id.
+ */
+export function ToastStack({ notices, onRemove }) {
+  const stack = useRef(null);
+  // The button that dismisses a notice goes with it, and the focus would go
+  // to the top of the document. It is put on the stack, which is where the
+  // next notice's button is. A notice that runs out of time takes no focus
+  // from anywhere but itself, and moves none.
+  const dismiss = useCallback((id) => {
+    if (stack.current) stack.current.focus();
+    onRemove(id);
+  }, [onRemove]);
+  return (
+    <section ref={stack} tabIndex={-1} className="toast-stack" aria-label={__('Notifications')}>
+      {notices.map((notice) => <Toast key={notice.id} notice={notice} onRemove={onRemove} onDismiss={dismiss} />)}
+    </section>
+  );
+}
@@ -6,13 +6,14 @@
  * Actions used to complete silently, or leave an inline sentence the
  * contributor may not be looking at, and none of the success notices reached a
  * screen reader. This is the one place a completed action is confirmed: a
- * transient message that `SnackbarList` renders and speaks. The reducer holds
- * the list; the renderer only dispatches and paints.
+ * transient message that the toast stack renders and speaks (#557). The
+ * reducer holds the list; the renderer only dispatches and paints. What the
+ * messages say is here too, where a branch or a value chooses it.
  *
- * Kept as a pure, dependency-free module so it can be unit tested without a
- * DOM: the renderer bundle imports it, `node --test` requires it directly. The
- * `id` comes from a running counter rather than a timestamp or random value so
- * the reducer stays deterministic under test.
+ * Kept as a pure module so it can be unit tested without a DOM: the renderer
+ * bundle imports it, `node --test` requires it directly. The `id` comes from a
+ * running counter rather than a timestamp or random value so the reducer
+ * stays deterministic under test.
  *
  * Tone drives accessibility, not just colour:
  *   - `success` speaks politely and clears itself on a timer — a confirmation
@@ -23,6 +24,8 @@
  *     that half-happened (#381).
  */
 
+const { __, sprintf } = require('@wordpress/i18n');
+
 // At most this many confirmations are kept on screen at once. A burst — a
 // double-click, a chain of steps finishing together — collapses to the most
 // recent few rather than stacking into a wall.
@@ -86,13 +89,16 @@ function confirmationReducer(state = initialConfirmations, action = {}) {
  * @param {{ ok?: boolean, dryRun?: boolean, number?: number, url?: string }} res The main process's result.
  */
 function prConfirmationMessage(res = {}) {
-	if (res.dryRun) return 'Dry run — branch created, no pull request opened';
+	if (res.dryRun) return __('Dry run — branch created, no pull request opened');
 	// Named because two repositories are possible now (#251): a number alone
 	// does not say whether it landed on wordpress-develop or gutenberg. Read
 	// from the pull request's own URL, not from the site's type: with the
 	// sandbox override set the two differ, and the URL is where it went.
 	const match = /^https:\/\/github\.com\/([^/]+\/[^/]+)\/pull\/\d+/.exec(String(res.url || ''));
-	return `Opened pull request #${res.number}${match ? ` on ${match[1]}` : ''}`;
+	// translators: 1: the number of a pull request. 2: the repository it was opened on, such as WordPress/gutenberg.
+	if (match) return sprintf(__('Opened pull request #%1$s on %2$s'), res.number, match[1]);
+	// translators: %s: the number of a pull request.
+	return sprintf(__('Opened pull request #%s'), res.number);
 }
 
 /**
@@ -108,8 +114,88 @@ function prConfirmationMessage(res = {}) {
  */
 function deleteFailureMessage(res = {}) {
 	if (res.ok !== false || res.reason !== 'remove-failed') return null;
-	const code = res.code ? ` (${res.code})` : '';
-	return `The site is still listed because its folder could not be deleted${code}. Close anything using it, then try again. Folder: ${res.path}`;
+	if (res.code) {
+		// translators: 1: an error code of the system, such as EBUSY. 2: the path of a folder.
+		return sprintf(__('The site is still listed because its folder could not be deleted (%1$s). Close anything using it, then try again. Folder: %2$s'), res.code, res.path);
+	}
+	// translators: %s: the path of a folder.
+	return sprintf(__('The site is still listed because its folder could not be deleted. Close anything using it, then try again. Folder: %s'), res.path);
+}
+
+/**
+ * The notice for a site that could not be set up (#557): that it could not,
+ * and what went wrong, as it was reported. The setup runs for minutes after
+ * the dialog that asked for it has closed, so this is the one place its
+ * failure is said.
+ *
+ * @param {*} error What the setup was rejected with.
+ * @return {string} The sentence.
+ */
+function setupFailureMessage(error) {
+	// translators: %s: what went wrong, as the system reported it.
+	return sprintf(__('The site could not be created. %s'), String(error));
+}
+
+/**
+ * The confirmation for a patch or a pull request that is in the checkout and
+ * built, or taken back out. The apply flow names what it did with a verb and
+ * a noun, which it also prints in the terminal; here each pair it has is a
+ * sentence of its own, so that it can be translated whole.
+ *
+ * @param {string} verb 'Applied', 'Reverted', 'Checked out' or 'Restored'.
+ * @param {string} noun 'patch', 'pull request', 'previous branch' or 'saved work'.
+ * @return {string} The sentence.
+ */
+function applyDoneMessage(verb, noun) {
+	const sentences = {
+		'Applied patch': __('Applied the patch'),
+		'Reverted patch': __('Reverted the patch'),
+		'Checked out pull request': __('Checked out the pull request'),
+		'Restored previous branch': __('Restored the previous branch'),
+		'Restored saved work': __('Restored the saved work')
+	};
+	return sentences[`${verb} ${noun}`] || `${verb} the ${noun}`;
+}
+
+/**
+ * The confirmation for a patch saved to a file.
+ *
+ * @param {string} fileName The file's name, without its folder.
+ * @return {string} The sentence.
+ */
+function patchSavedMessage(fileName) {
+	// translators: %s: the name of a file.
+	return sprintf(__('Patch saved to %s'), fileName);
+}
+
+/**
+ * The confirmation for edits saved to a file before trunk was updated over
+ * them.
+ *
+ * @param {string} fileName The file's name, without its folder.
+ * @return {string} The sentence.
+ */
+function savedAndResetMessage(fileName) {
+	// translators: %s: the name of a file.
+	return sprintf(__('Saved your changes to %s and reset the working tree'), fileName);
+}
+
+// How long a confirmation that clears itself is on screen: what the
+// snackbars before it had (#253).
+const TOAST_LIFETIME_MS = 6000;
+
+/**
+ * How a confirmation is drawn as a toast: the notice's colour, and how long
+ * it stays. One that has to be dismissed stays until it is.
+ *
+ * @param {Object} notice A notice of the queue: `{ tone, explicitDismiss }`.
+ * @return {{intent: string, lifetime: ?number}} The notice's intent, and its lifetime in milliseconds or null.
+ */
+function toastView(notice = {}) {
+	return {
+		intent: notice.tone === 'error' ? 'error' : 'success',
+		lifetime: notice.explicitDismiss ? null : TOAST_LIFETIME_MS
+	};
 }
 
-module.exports = { initialConfirmations, confirmationReducer, prConfirmationMessage, deleteFailureMessage, MAX_NOTICES };
+module.exports = { initialConfirmations, confirmationReducer, prConfirmationMessage, deleteFailureMessage, setupFailureMessage, applyDoneMessage, patchSavedMessage, savedAndResetMessage, toastView, MAX_NOTICES, TOAST_LIFETIME_MS };