Draw the create-site dialog with the design system, as the prototype has it - #600

…ion in the app's own dialog (#601)

## Why

Part of the redesign in #542, item 7 of #557: the rename and delete
dialogs. Renaming a site was the older component library's modal.
Deleting a site, and deleting a ticket's work, asked through the
system's own confirm box, which says one sentence, cannot say what goes,
and has two buttons called OK and Cancel.

## What changes

**The rename dialog** is the design system's, as the prototype has it: a
small dialog with the name and one button.

- The button says **Rename** (it said Save). There is no Cancel: the
close button, Escape and a press outside leave it.
- It still opens on the name the site has, selected; refuses an empty
name; and cannot be left while the name is being written.
- A name that could not be written is said in the dialog, as an alert,
with the focus back on the name. Before, it was a system alert box,
after which the dialog closed as if the rename had worked.

**Deleting asks in a dialog of the app's own**, as the prototype has it
for a site:

- It is titled with what would go: "Delete *site name*?", or "Delete all
work on ticket #60001?".
- It says what that means and that it cannot be undone.
- It opens on **Cancel**. The other button is red and says what it does:
**Delete site**, **Delete this ticket's work**.
- A press outside is not an answer. Cancel and Escape are a no.

The same dialog asks before a ticket's work is deleted, which #599 left
to this pull request. On a Gutenberg site it says "issue".

The questions' words are in `site-dialogs.cjs` and
`ticket-branch-list.cjs`, with unit tests.

Not in this pull request:

- **The three discards** (loose edits on trunk, "discard all changes",
and the discard before a trunk update) still ask through the system's
box. Each is asked from, or over, a modal of the older library, and two
libraries' dialogs on top of one another is a risk better taken when
those modals are redrawn.
- **A default for an empty name.** The prototype keeps the old name when
the field is emptied. An empty name is still refused, as decided for the
create-site dialog.

## How to test this

Platforms: any. The change is in the renderer only.

The journeys walk all three on both platforms. From the repository's
root:

```bash
npm run build:once && npx playwright test --project=journeys rename-site.spec delete-site.spec ticket-list.spec ticket-branches.spec i18n.spec
```

`delete-site.spec.js` is new: the question names the site, nothing but a
yes deletes it, and a yes removes the folder. `rename-site.spec.js`
gains a journey for a rename that is pending and one that fails.
`ticket-list.spec.js` asks its question through the new dialog. Each
claim was checked by breaking it: 37 breaks, all red.

By hand, on the current head, on either platform:

**Starting state:** a Core site that is set up, with one ticket parked
(link a ticket, then **Unlink**).

1. Open the site's menu (⋮, top right) and choose **Rename…**.
- A small dialog titled **Rename site** opens with the site's name
selected in the field.
2. Empty the field and click **Rename**.
- A red notice says "Site name cannot be empty." and the cursor is in
the field.
3. Type a new name and press Enter.
- The dialog closes; the heading and the sites list show the new name.
4. Open the menu and choose **Delete site**.
- A dialog asks "Delete *the new name*?", says the site and all its
files will be permanently deleted, and has **Cancel** focused beside a
red **Delete site**.
5. Click outside the dialog, then press Escape.
- The click does nothing. Escape closes the dialog. The site is still
there.
6. In **Your tickets on this site**, click **Delete this ticket's
work**.
- A dialog asks "Delete all work on ticket #…?" with a red **Delete this
ticket's work**.
7. Click **Cancel**, then ask again and click the red button.
   - Cancel leaves the row. The red button removes it.

**What must not have happened:**

- Step 5 deleted nothing: the site's folder is still on disk.
- Step 7's Cancel deleted nothing: the ticket's branch is still in the
site.
- Step 7's yes deleted that ticket's work only, and the site is still on
trunk.

## Risks and limitations

- **Review:** two passes by a separate context. No defects on either. 3
follow-ups on the first, one taken here; 1 on the second, taken here.
Details below.
- **Checked on macOS only**, at the default size, in a 1024×728 window,
and with the site's status read slowed by a second. Windows is CI's.
- **The manual steps above were not run by a person.** I looked at
screenshots of the three dialogs.
- **A question can now stay open while the app goes on.** The system's
box froze the window; this one does not. Nothing that holds the delete
buttons can start behind an open question, since the question is modal,
so a yes is not checked again.
- **A failed rename shows the error as the main process words it**
("Error invoking remote method…"), untranslated. It is the same text the
alert box showed. A sentence of the app's own means changing the handler
in the main process.
- **A deletion that fails is said where it was before**: for a site, in
the notice at the top of the window; for a ticket's work, in the ticket
card. Not in the question, which has closed by then.
- **The guide quotes the old question** word for word, and still
describes the old rename: `docs/guide/ticket-branches.md`,
`docs/guide/managing-sites.md`. That is #561.
- **`session.acceptConfirms()`** is still used by three journey files,
all for discards.

## Related

Part of #557. Part of #542. Follows #600. Does what #599 left for the
ticket list's question.

---

<details>
<summary>Design decisions and alternatives considered</summary>

- **One dialog for both questions.** `ConfirmDialog` takes what is asked
and what a yes does. It is the design system's alert dialog with its
"irreversible" intent, which is what makes the button red, puts the
focus on Cancel and turns a press outside away.
- **A yes closes the dialog at once.** The alert dialog can stay open
with a spinner until the work is done. A site's deletion already says
how it stands in the sites list, and a ticket's in its row, and both say
a failure where they always did. The dialog does not take that over.
- **The title says what goes, by name.** The system's box said "this
site". The dialog can be read without looking behind it.
- **The rename dialog stays held while it fades after a rename that
worked**, and is let go when its popup has gone. Otherwise its button
and close button come back for a fifth of a second.
- **A complaint puts the focus on the field and is the field's
description**, so that it is read with the field as well as when it
appears.
- **The note about the system's alerts and confirms** moved from
`onRename`, which no longer has one, to `confirmAnd`, which is where the
remaining ones are.

</details>

<details>
<summary>Review outcome (required — see AGENTS.md)</summary>

0 [fix here] · 3 [follow-up] on the first pass. 0 defects · 1
[follow-up] on the second.

- **Review:** completed — a separate agent context, against
`.github/instructions/code-review.instructions.md`; head `389e081`, base
`abb144269b9b108f0cd17e739b620c9199b1e89c`; it read the diff and the
libraries' source and ran lint and the unit tests, not the journeys. No
defects. Follow-ups:
1. "A no deletes nothing" looked for the folder, or the branch, which is
still there at the start of a deletion too. **Taken:** the journeys also
read what a deletion says as it begins.
  2. The guide quotes the old question. Left for #561.
  3. A failed rename shows the main process's wording. Left; in Risks.
- Notes taken: the dialog coming back to life while it fades after a
rename, and the focus after a failed one.
- **Second pass:** completed — a separate agent context, on the fix-up
before it was committed (staged over `389e081`), same base. No defects.
It checked that the held state cannot be left stuck (no way to reopen
the dialog while it fades: the backdrop takes the pointer and the focus
is given back after), that the focus is not taken at a wrong moment, and
that the slowed fade in the journey applies to the popup. One follow-up,
**taken:** the complaint is now the field's description.
- **Since review:** the second pass's fix-up plus that description, two
comments and one assertion read once instead of retried, committed
together as `db9e863a9a0e71218bcdb713d782b0be61445efa`. Not reviewed
again; every suite was run on it, and the new assertion goes red when
its line is removed.

Checks on `db9e863a9a0e71218bcdb713d782b0be61445efa`, macOS:

| Check | Result |
|---|---|
| `npx eslint . --max-warnings=0` | clean |
| `npm test` | 1840 pass, 2 skipped |
| `npm run test:electron` | 1841 pass, 1 skipped |
| `npm run test:e2e` | 93 of 93 |
| `npm run test:e2e:packaged` | 15 of 15, on an unsigned build |
| Seven journey files in a 1024×728 window | 26 of 26 |
| Seven journey files with the status read slowed | 26 of 26 |

</details>

<details>
<summary>Implementation notes</summary>

- `src/renderer/components/rename-site-dialog.jsx`: was
`rename-site-modal.jsx`.
- `src/renderer/components/confirm-dialog.jsx` (new): `ConfirmDialog`.
- `src/renderer/site-dialogs.cjs` (new): `renameProblem`,
`deleteSiteQuestion`.
- `src/renderer/ticket-branch-list.cjs`: `deleteWorkQuestion` gives a
title, a description and the button's words, for a ticket and for an
issue.
- `src/renderer/index.jsx`: `asking` and `askFirst` in the site's view;
`onRename` rejects.
- `tests/e2e/helpers/ui.cjs`: `confirmDialog`, `confirmYesButton`,
`confirmNoButton`.
- The rename journey slows the dialog's fade to three seconds for one
step, to look at the dialog on its way out. It costs that test three
seconds.

</details>

<details>
<summary>Screenshots or recording</summary>

Not attached: I have no way to upload an image from here. What the
screenshots I took show:

- **Rename:** a small centred dialog, "Rename site" and a close button,
the field with the name, a blue **Rename** button at the bottom right;
with an empty name, a red notice "Site name cannot be empty." between
the field and the button.
- **Delete site:** a wider dialog with no close button, "Delete
first-name?" as its title, two lines under it, and at the bottom right
**Cancel** with the focus ring and a red **Delete site**.
- **Delete a ticket's work:** the same, titled "Delete all work on
ticket #60001?", with a red **Delete this ticket's work**.

</details>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

…ay a failed setup there (#602)

## Why

Part of the redesign in #542, item 8 of #557: the toasts. The window's
confirmations were the older component library's snackbars, restyled by
hand in the page's own stylesheet, and only one of their sentences could
be translated.

One thing they could not say at all: why a site failed to set up. That
was shown only if the create-site dialog happened to be open when the
setup failed, and lost otherwise (#600 left it for here).

## What changes

**The confirmations are the design system's notices**, stacked in the
window's bottom corner as the prototype has them: green for what worked,
red for what did not, each with a **Dismiss** button.

What they do is what the snackbars did:

- One for something that worked is said politely and goes by itself
after six seconds.
- One for something that did not is said at once and does not time out.
- A repeat of the newest is not shown or said twice, and three are kept
at most.

What is different:

- **Every notice has a Dismiss button.** A snackbar was dismissed by
pressing it anywhere. Dismissing one leaves the focus on the stack, as
the snackbars' list had it.
- **The stack is a region named "Notifications"**, which a screen reader
can go to.
- **A site that could not be set up is said there**, as an error. The
create-site dialog's message is its own again: which answer is missing.
Its two ways in no longer differ over a message left behind, since none
is.
- **The sentences can be translated.** The ones a value or a branch
chooses are worded in `confirmations.cjs`, with unit tests: what the
apply flow did, a saved patch, an opened pull request, a deletion or a
setup that failed.
- **Tooltips of the design system are drawn over everything.** They were
under the stack, so the name of a notice's button was hidden by the
notice above it.

Not in this pull request, by decision: **no new confirmations.** The
prototype raises a toast for many things the app does not confirm (a
rename, a deletion, a server starting). The app says what it said
before, plus the failed setup.

## How to test this

Platforms: any. The change is in the renderer only.

The journeys walk the stack on both platforms. From the repository's
root:

```bash
npm run build:once && npx playwright test --project=journeys toasts.spec create-site.spec i18n.spec
```

`toasts.spec.js` is new: a confirmation is shown and said once, goes at
its time and not before, can be dismissed; an error is said at once,
stays, and is joined by a later success without going with it; a
notice's tooltip is over the notice above it. `create-site.spec.js`
covers the failed setup, with a dialog open and with none. Each claim
was checked by breaking it: 23 breaks, all red.

By hand, on the current head, on either platform:

**Starting state:** a site that is set up.

1. Open the site's menu (⋮, top right) and choose **Copy path**.
- A green notice "Copied the path" appears in the bottom right corner,
above the footer. It goes after about six seconds.
2. Choose **Copy path** again and click the notice's **✕**.
   - It goes at once.
3. Turn the network off, click **Create new site**, fill the dialog in
and click **Create site**.
- The dialog closes. When the clone fails, a red notice says "The site
could not be created." and why. It is still there a minute later.
4. While it is showing, choose **Copy path** again and rest the pointer
on the green notice's **✕**.
- The green notice is under the red one. A "Dismiss" tooltip shows over
the red notice, not behind it.
5. Click the red notice's **✕**.
   - It goes.

**What must not have happened:**

- Step 3 left nothing in the sites list for the site that failed, and no
dialog open.
- The red notice did not go by itself in step 4, when the green one did.
- A notice never stopped a click on what is beside it: the stack takes a
press only where a notice is.

## Risks and limitations

- **Review:** two passes by a separate context. 3 to fix here on each,
all fixed. The first pass caught a mistake of mine: I had set the
lifetime to ten seconds, believing that was the snackbars'. It was six,
and is six. Details below.
- **Checked on macOS only**, at the default size and in a 1024×728
window. Windows is CI's.
- **With the site's status read slowed by a second, two journeys fail
that this change does not touch**: `site-header.spec.js` (a viewport
check) and `trunk-update.spec.js` (an update asked for straight after a
ticket is linked). Both fail the same way on `redesign/wpds` without
this change; I checked. They pass at normal speed and have been passing
on the Windows runner. The eight other files that read a toast pass
slowed, 25 of 25.
- **The manual steps above were not run by a person.** I looked at
screenshots of one notice, of two, and of the tooltip.
- **A failed setup's notice shows the error as the main process words
it** ("Error invoking remote method 'wordpress:setup': Error: …"). The
dialog showed the same text. It is now in a notice that stays in front
of a newcomer.
- **Three newer notices push out the oldest, an error included.** As
before. A reducer that drops successes first would be a change of
behaviour.
- **A notice raised while a dialog is open cannot be reached by
keyboard** until the dialog closes: the dialog keeps the focus. It is
still said, and can be dismissed with the pointer, which leaves the
dialog open; I ran that with the rename dialog.
- **The "Notifications" region is always there**, empty when nothing is
said.
- **The five sentences worded where they are raised** ("Updated to the
latest trunk", "This site is ready to work on", and three more) go
through the translator, but no test would notice if one stopped: the
unit tests reach the module's, and the pseudo-locale journey reads
"Copied the path".
- **The guide's other pages** still describe the redesign's earlier
screens (#561). One sentence is corrected here because this change made
it false.

## Related

Part of #557. Part of #542. Follows #601. Settles what #600 left about a
failed setup.

---

<details>
<summary>Design decisions and alternatives considered</summary>

- **Six seconds, not the prototype's 3.2.** The prototype's is short for
a sentence, and the app's has not changed.
- **A Dismiss button on every notice.** The prototype's notices have
none, and its errors time out like the rest. An error that stays needs a
way to go, and a success could always be sent away early.
- **The dialog no longer shows why a setup failed.** Two places saying
it, one of them only sometimes, is what lost it. With the notice saying
it always, the dialog's line is its own and needs no owner outside it.
- **No shadow in the prototype; one here.** A notice over a page of
cards reads as one more card without it. It is the design system's
elevation token.
- **The journeys find the stack by its label, not its role.** A
confirmation can be raised while a dialog is open, for something done
inside it, and an open dialog hides everything else from the roles.
- **Every lookup of a toast's text goes through the stack.** A notice is
said through a live region elsewhere in the document, which holds the
same text; a search of the whole page finds both.

</details>

<details>
<summary>Review outcome (required — see AGENTS.md)</summary>

3 [fix here] · 3 [follow-up] on the first pass, all 3 fixed. 3 [fix
here] · 2 [follow-up] on the second, all 3 fixed.

- **Review:** completed — a separate agent context, against
`.github/instructions/code-review.instructions.md`; head `3297f74`, base
`6c7e6792026c533f8e91de7105c61ef5505d6e2b`; it read the diff and the
libraries' source and ran lint and the unit tests, not the journeys.
Fixed:
1. The lifetime was ten seconds, said to be the snackbars'. Theirs was
six (`NOTICE_TIMEOUT` in `@wordpress/components` 41). It is six.
2. Dismissing a notice left the focus at the top of the document. It is
put on the stack.
3. The guide said a failed setup's reason goes to the log and not to a
dialog.
- Follow-ups taken: the design system's tooltips under the stack; two
steps of the journey. Not reproduced when run: dismissing a notice
closing an open dialog.
- **Second pass:** completed — a separate agent context; head
`953f4a32e08a9b3a274a7a9979a4382d7f87b755`, same base. No finding in the
app's code. Fixed, all in `toasts.spec.js`:
1. The check that a confirmation is still there depended on how fast the
machine was. The clock is stopped under it.
2. The check that a repeat is not shown twice could be read before a
second one had appeared. It is told by what is left after one is
dismissed, and by what was said by the end.
3. The tooltip's place could be read before the tooltip had been moved
to its button. It is read once it reaches the notice above.
- Also taken: the guide's sentence said the notice stays until
dismissed, which three newer ones can undo. Left: the main process's
wording in the notice; in Risks.
- **Since review:** `953f4a3` →
`ba41d4e633b8c7f8e001a5e3ef9930907302f67e`: the journey and one sentence
of the guide. No source under `src/` changed. Not reviewed again; every
suite was run on it, and eight breaks go red against the rewritten
journey.

Checks on `ba41d4e633b8c7f8e001a5e3ef9930907302f67e`, macOS:

| Check | Result |
|---|---|
| `npx eslint . --max-warnings=0` | clean |
| `npm test` | 1846 pass, 2 skipped |
| `npm run test:electron` | 1847 pass, 1 skipped |
| `npm run test:e2e` | 95 of 95 |
| `npm run test:e2e:packaged` | 15 of 15, on an unsigned build |
| Ten journey files in a 1024×728 window | 33 of 33 |
| Eight journey files with the status read slowed | 25 of 25 |

</details>

<details>
<summary>Implementation notes</summary>

- `src/renderer/components/toast-stack.jsx` (new): `ToastStack`.
- `src/renderer/confirmations.cjs`: the reducer is as it was. New:
`toastView`, `TOAST_LIFETIME_MS`, `setupFailureMessage`,
`applyDoneMessage`, `patchSavedMessage`, `savedAndResetMessage`. The
module now needs `@wordpress/i18n`.
- `src/renderer/index.jsx`: the stack in the same portal on `body`; the
failed setup's notice; `createSiteError` gone.
- `src/renderer/index.html`: the snackbars' rules are gone.
`src/renderer/shell.css`: the stack, and `--wp-ui-tooltip-z-index` on
`:root`, which is where the design system reads it from.
- `tests/e2e/helpers/ui.cjs`: `toasts`, `toast`. Eight journey files
used `getByTestId( 'snackbar' )` or a search of the whole page.
- The toasts journey uses Playwright's clock. Stopped, it also stops the
app's menus from being pressed, so it is stopped only between a notice
appearing and its time being up.

</details>

<details>
<summary>Screenshots or recording</summary>

Not attached: I have no way to upload an image from here. What the
screenshots I took show:

- **Two notices** in the bottom right corner, above the footer, 360
pixels wide: a red one with a warning icon and four lines of bold text,
and under it a green one with a tick, "Copied the path". Each has a ✕ at
its right.
- **The tooltip:** a small dark "Dismiss" label above the green notice's
✕, drawn over the lower edge of the red notice.

</details>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

## Why

#542 replaces the app's interface with the one in the
[prototype](https://github.com/jameskoster/wordpress-contributor-toolkit-prototype),
drawn with the WordPress Design System. It was built in slices on
`redesign/wpds`, so that trunk, which releases are cut from, never held
a half-redesigned window. The window is whole now: the shell, the page
header and details, every card and dialog, and the tray. This pull
request is how the branch reaches trunk.

It lands before the last three sub-issues, on purpose. The settings
dialog (#559) and dark mode (#560) add to a finished window and do not
need a branch to hide in, and the guide (#561) is easier to rewrite
against what is on trunk. They follow as pull requests against trunk.

## What changes

Everything `redesign/wpds` holds; this pull request adds nothing of its
own. Each slice was reviewed in its own pull request against that
branch, and says there how to test it and what it leaves out.

- **The shell** (#555): a sites list, the page area and a footer, in a
larger window. #590
- **The page header and the details** (#556): the site's menu in the
header, and what the checkout is in a sidebar that can be put away.
#594
- **The site's page** (#557): the server and the build watch in the
header and the details
(#595); the ticket
card, the apply card with a preview dialog, and the list of a site's
tickets (#596,
#597,
#599); the
create-site, rename and delete dialogs
(#600,
#601);
confirmations as notices in the window's corner
(#602); the page's
notices, update card and setup checklist
(#605); the
terminal, logs, mail and the review dialogs painted with the design
system's tokens
(#606,
#608); and lint
rules that keep it so
(#609,
#610).
- **The tray** (#558): along the bottom of the window, holding the
terminal, the logs or the mail, with a count of unseen debug.log lines
on the footer
(#612,
#613,
#614,
#615).
- Along the way:
#611 (the site
menu's update item says why it is held), and three that tidy up before
landing: #616 (a
journey's race with the page's clock),
#617 (comments the
finished redesign made untrue) and
#618 (the server's
button by its present name in `AGENTS.md`).

**What a contributor will notice first:** the terminal, the logs and the
mail are no longer on the page but behind three buttons at the foot of
the window; the terminal is dark text on light; the server and the build
watch are started from the header; a patch is previewed in a dialog
before it is applied; and what worked is said in the window's corner.

**Not in this pull request:**

- The settings dialog (#559). Until it, nothing about how the window is
arranged is remembered across restarts: the details, the tray's height,
the apply card's fold.
- Dark mode (#560). The terminal reads its colours once, when it is
made, and will need to follow the theme.
- The user guide and its screenshots (#561), which describe the old
interface. They are published from release tags, so they are not wrong
until a release ships this; #561 is next, ahead of #559 and #560, for
that reason.
- How a mail is drawn, and how the window handles a link. Both are
unchanged and tracked separately.

## How to test this

Platforms: macOS and Windows, both. Buildkite builds signed artifacts
for this pull request; use the build for its current head, and check
that it is: a push to the branch makes earlier builds stale.

The suite, from the repository root, after `npm ci`:

```
npm run lint
npm test
npm run test:e2e
```

113 journeys walk every slice on macOS and Windows on each push. What
they do not do is run a real site: a clone of `wordpress-develop`, an
install, a build and a server are stood in for. The one test that does,
`real-setup.yml`, is run by hand and was run on this branch at `548c020`
(https://github.com/WordPress/contributor-toolkit/actions/runs/37298667056):
a Core site on macOS and on Windows and a Gutenberg site on macOS were
created, installed, built and served, and passed. **The Gutenberg site
on Windows did not finish.** Its first attempt was cancelled after 74
minutes inside the journey, a minute short of the limit that would have
failed it with evidence, so it says nothing about where it was; a second
attempt was still running when this was written and its result is not in
this description. The commits since `548c020` change a journey, comments
and prose.

**A pass by hand, on a real machine** (any platform; Apple Silicon for
the server, which no test on a pull request starts for real). It follows
the order a contributor meets things in:

1. Open the app with no sites. **Create new site**, a Core site, in a
folder with a space in its path. The setup checklist runs its steps; the
terminal's button at the foot of the window shows what each is doing.
2. Let the checklist's last step start the server, and finish
WordPress's own setup in the browser. Back in the app the header says
"Server running" and "Build watching". Stop the server and start it
again: from **Server running** in the header, or with **Stop** and
**Start** beside "Server" in the details.
3. Press the three buttons at the left of the footer in turn. Terminal:
type `help`. Logs: the server's lines, the build watch's, and Debug.log.
Email: where SMTP is listening. Drag the tray's top edge.
4. Link a ticket by its number. The card shows the ticket and its pull
requests and patches.
5. Apply one of them. The preview dialog names the files; **Apply and
rebuild** runs the steps on the card.
6. Edit a file under `src/`, then **Review & submit changes**. The diff
is the edit and nothing else.
7. Create a second site, or open one from before, and move between the
two from the sites list. Each has its own terminal, logs and mail.
8. **Update to latest trunk** from the site's menu.

**What must not have happened:** work lost in a link, an apply, a switch
or an update that did not say so; `node_modules` rebuilt where nothing
changed; a failure said only in a tray that stayed closed; one site's
output in another's tray; anything on the page under the tray.

**What cannot be tested by hand, and what was not:** none of the slices'
manual steps were run by a person. I looked at screenshots and drove the
app through the journeys; everything local was on macOS, with Windows
left to CI. This pass is the first one by hand.

## Risks and limitations

- **It is one commit on trunk**, since the repository allows only squash
merges. The slices' pull requests are its record. `redesign/wpds` should
not be branched from after this: it will have diverged from trunk.
- **Reviewed in slices, not as a whole.** Twenty-two pull requests, all
but a two-word change to `AGENTS.md` reviewed by a separate reviewer
context before they were opened, most in two passes; see below. The
branch was then swept once for what falls between slices, which found
comments and one unread field
(#617) and the
three points that follow.
- **Three questions and two failures still use the system's own
dialogs**: the discards ask through its confirm box, and a path that
could not be copied and a server started before there is a build are
said in its alert. #557 meant to replace them and did so for deletions
only.
- **Some dialogs are repainted, not rebuilt.** The review dialog and its
destinations, the mail dialog and the question an update asks about
loose edits have the design system's colours and type on the old
component library's parts.
- **A real Gutenberg setup on Windows is not shown to pass on this
branch.** See "How to test this". It passed on trunk before the
redesign, in 35 minutes; here it was past 46 on its second attempt.
Whether that is the runner or the branch is not known.
- **The guide describes the old interface** until #561. Do not cut a
release before it.
- **The bundle roughly doubled**
(#590): the sites
list brings `DataViews` and what it needs. Launch time was not measured.
- **Less is always in view.** A build's output, a new line in debug.log
and a caught mail are in a tray that may be closed. A failure opens the
terminal, or the logs if nothing else is open; unseen debug.log lines
are counted on the footer; a mail that arrives shows nowhere until its
tray is opened, which was decided and is not an oversight.
- **Translation is about half done.** The shell, the cards, the tray and
most dialogs go through the translator. Roughly 200 strings in
components and hooks do not yet (the review dialog and its destinations,
the setup checklist, the logs, most of what the hooks say), nor about
150 in the modules they take sentences from. Strings that are new are in
English in the shipped translations until they are translated.
- **Focus is lost in a few places**: when the app swaps what the tray
holds from under it, when a notice with a focused button goes, when a
row's own action removes the row.
- **Some failures are still worded by the main process** ("Error
invoking remote method…"): a failed rename, a failed setup.
- **Things carried over, not made by this:** a start that throws leaves
the server's button dead until a restart; erasing typed input in the
terminal breaks once the line wraps; a line written to debug.log while
it is being attached to can be shown twice.
- **#571 and
#603 will conflict
with trunk after this**, in the mail's journey and helpers and in the
dev server's hook.
- Each slice's own list has more, and says which of its limits were
chosen.

## Related

Closes #557. Closes #558. Part of #542, which stays open for #559, #560
and #561. #555 and #556 are closed already.

---

<details>
<summary>Design decisions and alternatives considered</summary>

- **An integration branch, and one landing.** A window drawn half by the
old view and half by the new one could not be released, and the slices
were too many to hold back one by one behind a flag. Fixes and changes
with no visible effect went to trunk first and were merged across, so
this diff is the redesign and little else.
- **Landing before #559 to #561.** The plan was to land when all seven
sub-issues were in the branch. The remaining three do not change what is
there: two add to it and one documents it. Holding a finished window on
a branch for them only lengthens the time trunk and the branch can drift
apart.
- **What the prototype lacks is kept and redrawn**, and what it has
somewhere else moves to where it puts it. Its labels are adopted. Where
a slice departs from it, the slice says so.

</details>

<details>
<summary>Review outcome (required — see AGENTS.md)</summary>

**No review of the whole diff was run. The record is the slices':
twenty-two pull requests into `redesign/wpds`, each but one reviewed
before it was opened by a separate, read-only reviewer context following
`.github/instructions/code-review.instructions.md`, most in two passes
(the change, then its fix-up), with the counts and the findings in each
pull request's own review outcome. The one is
#618, two words in
a line of prose.**

- **Review:** completed, per slice —
#590,
#594 to
#602,
#605,
#606,
#608 to
#617 (no review was
run for #618);
everything marked to fix in a slice was fixed in that slice, and what
was left is in its Risks.
- **Review:** completed, for leftovers only — a separate agent context,
read-only; `redesign/wpds` at `548c020` against trunk; not a review of
correctness, which the slices had: a search for dead CSS and code,
comments that waited for a slice that has landed, what is left of the
old component library and of the system's dialogs, strings not yet
translatable, and repository docs that name the branch. Nothing found in
the stylesheet, the dependencies or the docs; thirteen comments and one
unread field, fixed in
#617; the rest is
in Risks above.
- **CodeRabbit:** not run. Its check reads "Review skipped: automatic
reviews are disabled" on this pull request and on the slices, so the
slices' pre-PR reviews are the reviews of record, each for the head it
names.
- **Since review:** nothing was added to the branch outside a reviewed
slice, apart from three merges of trunk (`da19ac6`, `3344172`,
`23d46e7`).

</details>

<details>
<summary>Implementation notes</summary>

- `git diff origin/trunk...origin/redesign/wpds`: 148 files, about
14,800 lines added and 3,000 removed; about 6,300 of the added lines are
tests.
- The site's view, which was one component of five thousand lines, is
spread over the four regions the layout has: the header, the cards, the
details and the tray. Decisions are in `src/renderer/*.cjs` with unit
tests; components draw them.
- New for the suite: journeys per region under `tests/e2e/journeys/`,
lint rules of the repository's own (`eslint-rules/`), and Stylelint over
the window's stylesheet.
- The main process changed in one place for the redesign's sake: the
debug.log tail says which lines the file already held
(#614).

</details>

<details>
<summary>Screenshots or recording</summary>

Not attached: I have no way to upload images from the command line. The
prototype shows the design; the signed build shows the app.

</details>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>