feat(web): convert and redesign Settings, Help, Login, Audit, Export, Account and Set Password (#833)

docs/designs/674-tail-redesign/SELECTION.md

@@ -0,0 +1,32 @@
+# Settings and support — selected compositions
+
+Owner selections for #833, applied to both desktop and phone:
+
+| Screen | Direction |
+| --- | --- |
+| Farm settings | C — Focus panels |
+| Help | B — Working desk |
+| Login | B — Working desk |
+| Audit log | C — Focus panels |
+| Export | C — Focus panels |
+| Account | C — Focus panels |
+| Set Password | B — Working desk |
+
+Open `tail-direction-lab.html`. Switching screens restores that screen's selected composition; A/B/C remain available for comparison.
+
+## Requested refinements
+
+- Help's contents navigation remains visible while scrolling the article, with its own overflow for long contents lists. On phone it remains a horizontal strip above the article.
+- Highlight the section currently being read with a tinted background, bold label and `aria-current="location"`. Update on manual scrolling as well as topic clicks, keep the active contents item visible, and clear the highlight when search returns no sections.
+- Phone navigation remains five direct, equally sized items with the existing icons: Daily entry, Stock, Sales, History, More.
+- Render Help copy as text with explicitly supported paired emphasis. A literal `/login?farm=<code>` is not an HTML opening tag. Rendering it as raw HTML had caused the browser to wrap the subsequent phone navigation inside `code` and break the grid.
+
+## Login banner proposal — not an authorization change
+
+The owner approved the farm-banner placement in Login B's left panel. The mockup reserves a labelled image slot, not an actual farm image; the empty preview retains the text fallback. This approves the visual placement, not a change to authentication or image access.
+
+Current production banners are authenticated: `web/src/farm/useLogoObjectUrl.ts` fetches `/account/banner` through the authorized API client. Their existing use is the post-login splash. Login cannot fetch them anonymously under that contract.
+
+Before implementing the login-banner proposal, decide how pre-login imagery is intentionally made available and how the correct farm is identified. Do not remove authorization or implicitly persist private banner bytes in the browser as part of a styling change. Keep neutral Cluckwork branding when no suitable pre-login image is available. The existing post-login splash is not removed by this proposal.
+
+This artifact is a design prototype. It does not submit credentials, upload branding, save account data, or download real exports. Selection is not a claim that the implementation or every production state is complete.

docs/designs/822-mui-revamp.md

@@ -352,6 +352,13 @@ Order is by dependency, then by what each slice teaches the next. **Deletions ar
 
 Only one CSS deletion actually landed with #832: `.dialog .confirm-body` / `.dialog .confirm-body strong` (UsersPage's disable-warning paragraph was its last consumer anywhere in the repo; `useConfirm.tsx` had already dropped it in #827). Every other class family the five screens used — `table.data`, `.page-head`, `.form-grid`/`.inline-form`, `.actions`, `tr.inactive`, `.dialog-foot`, `.numfield-field`, `.named-picker-trigger`, `.hint`, `.check`, `.cell`, `td.nowrap` — is still shared with an unconverted screen, confirmed by grep before touching each one.
 
+**Amendment (#833, landed 2026-09-18, ahead of #831 in real order).** #833 shipped while #831 was still in flight on its own branch (`feat/831-mui-ledgers`, unmerged at #833's head), which changes four things this row's own text assumed:
+
+- **`FilterBar` was cherry-picked from #831's branch, not read from `main`.** Row 7 says "reused, never rebuilt: seven screens call one component," and by the time #833 reached Audit (the seventh, done last per D8), #831 had already built `FilterBar`/`FilterDateField` and converted six of its own seven ledger screens on its own unmerged branch. #833 cherry-picked #831's isolated `FilterBar` commit (`47fce5a`, two new files, zero other changes) onto `feat/833-mui-tail` rather than rebuild it, per the brief's own contingency for exactly this ordering. The PR names the cherry-picked SHA.
+- **`.muted`/`.error`/`.success` were left unconverted on Audit, breaking with this PR's own pattern on its other six screens.** Pair 17 (`p.error`/`p.warn` → `Alert`) is scoped "each screen slice," and #833 converted it everywhere except Audit — Login, SetPassword, Export, Account and Settings all got `Alert`/`Typography color="text.secondary"`. Audit did not, because #831's own shipped ledger screens (Stock, History, Expenses, on its unmerged branch) all keep `.muted`/`.error`/`.success` as raw paragraphs, matching #832's own precedent of leaving semantic-text classes for a later, dedicated pass. Audit sits in the ledger family by D3.3's own row grouping (Audit shares a row with the ledgers' "table" shape), so #833 matched its nearest siblings' shipped look rather than pair 17's letter, on the theory that a ledger screen reading differently from the six beside it in the nav is a worse outcome than an inconsistent PR-to-PR reading of one pair. `#831`'s own PR is the one that will convert these classes on all seven ledger screens at once, Audit included, if it chooses to.
+- **`.toolbar`, `table.data`, `.page-head`, `.content`, the badge rules, the semantic-text rules and the shared `.card` rule were NOT deleted.** Row 9's "last consumer AuditPage.tsx, #833" and D8's own #833 deletion list both assumed #833 would be the slice to retire these — true only if #833 merges after #831. At #833's head, six other screens in the same worktree (Feed, Water, Reports, History, Expenses, Stock — all #831's, unmerged) still render `.toolbar`, and `table.data`/`.page-head` are shared even more broadly. #833's own PR body states the check it ran against `origin/main` at open-PR time and which of the two possible outcomes applied.
+- **Help was converted far more narrowly than D3.3's row describes.** "Keeps its docs layout as `Container maxWidth='md'` prose" undersold how much of Help's existing CSS-driven structure (`.help-hero`, `.help-search*`, `.help-toc*`, `.glossary-group`/`.glossary-entry`, `.mistakes`) survives: `HelpPage.test.tsx` has dozens of assertions keyed directly to that structure, and the issue's own text says "Presentation only — do not touch the prose or the glossary here." #833 converted only the outer wrapper (`Container maxWidth="md"`) and the page's own `<h2>`, plus the shared `GlossaryLink` component (pair 20) — leaving the rest of Help's CSS classes in `styles.css` undeleted, as a deliberate, recorded scope reduction rather than the fuller conversion this row implies. A follow-up issue is the owner's call, not filed by this PR.
+
 ### D9. The precache ceiling (#825). Owner review
 
 Ceiling **1,800 KiB** of precache, enforced in CI by extending `scripts/verify-sw.mjs` (it already extracts the manifest at L150-161; it sums the listed files' sizes from `dist/` and fails above the ceiling). Derivation: MUI plus the realistic kit measured 1632.68 KiB; D7.2 adds 118.9 KiB; that is 1751.6 KiB, and 1,800 leaves 2.7% for the small controls. The alternative is a ceiling below the unoptimised kit measurement (1,600 KiB) on the argument that this epic deletes as it adds and a ceiling above the measurement is not a ceiling. Its cost is stated plainly: #825 installs the gate at order 3, before any deletion slice, and no deletion estimate exists yet (the hand-built controls are TSX, which the precache counts as part of the JS chunk, and nobody has measured what #826 and #827 remove), so a 1,600 ceiling can go red at #828 and stay red until enough hand-built code is gone; it also forces the `opsz` fallback in D7.2. #825 measures the JS delta of deleting `NamedEntityPicker` and `Dialog` on a throwaway branch before the number is chosen, so the choice is decidable. Either way: above the ceiling a slice must retire hand-built code to land, and a slice that adds more than 10 KiB of precache without deleting code names the reason in its PR body. The check is a `pull_request` check in the `web` job, so a documentation-only PR skips it (#782), which is correct: such a PR changes no bundle input. Script-time ceiling per #674: re-measure with the record's method when #826 lands, since `Autocomplete` is the component the record named as needing its own number.

specs/product/GLOSSARY.md

@@ -971,9 +971,44 @@ as the logo (PNG/JPEG/WebP, a still image, no SVG, dimensions and metadata
 handled the same way — see below), but its own larger size cap (5 MB by default,
 since a detailed hero image is typically heavier than a small sidebar mark) and its own
 Owner-only upload and everyone-sees-it read, same as the logo. The
-splash is skipped entirely when no banner is set — it is never shown empty, and
-never shown on the pre-login screen (that screen has no farm to show a banner
-for yet).
+splash is skipped entirely when no banner is set — it is never shown empty.
+
+The pre-login screen itself has no farm to fetch a banner for — `/account/banner`
+stays authenticated, and signing in is exactly what has not happened yet — but it
+can still show one (#833): the device caches the banner's bytes locally the moment
+the post-login splash fetches them. Not the same mechanism the cached **farm
+palette** (below) uses: a colour is a few bytes of text and fits localStorage, but
+production's Content-Security-Policy allows images only from this origin or a
+`blob:` URL, never a `data:` one — so the banner's actual bytes live in IndexedDB
+and are shown through a `blob:` object URL, the same mechanism the authenticated
+logo/banner fetch already uses once signed in.
+
+On a later visit, Login shows the cached image only when the farm-code field's
+CURRENT value — typed, prefilled from a link, or picked from the remembered-farm
+list — names the farm that cache entry belongs to; typing or picking a different
+code hides it immediately, without waiting for the form to be submitted. A field
+naming no cached farm at all (nothing typed yet, or a farm never signed in on
+this device) shows plain Cluckwork branding instead. Forgetting a remembered farm
+clears its cached banner alongside its cached palette.
+
+Each cache entry also remembers WHICH account wrote it, not just the farm code:
+a **farm code** can be reassigned to a different farm after a rename (#732 — see
+above), so the code alone cannot tell "still the same farm" from "a different
+farm now using this farm's old code". The moment a sign-in proves which account a
+code belongs to today, a mismatched cache entry is cleared. Until that sign-in
+happens, a device that already held one farm's banner may show it briefly under a
+code since reassigned to a different farm — a stale attribution to a device that
+already had those bytes, not a new disclosure to a device that never held them.
+
+Deliberately narrower than the palette's own pre-login reach: the palette also
+shows for a farm a `?farm=<code>` link merely *names*, even on a device that has
+never signed in there, because a colour carries no private information. A banner
+is farm-supplied imagery, so showing one to whoever holds a link — rather than
+only to a device this farm has actually authenticated on before — would be a
+new disclosure the owner did not approve; #833's own design note is explicit that
+the banner's placement was approved, not a change to authentication or image
+access. A `?farm=<code>` link therefore shows no banner, cached or otherwise,
+regardless of what the device remembers.
 
 What gets stored is never quite the file that was uploaded. The image is taken
 apart and rebuilt, which drops two things on purpose: **embedded metadata** — a

tools/simulation/ui/specs/owner.spec.ts

@@ -191,38 +191,32 @@ test.describe("Owner", () => {
     await expect(page.getByRole("heading", { name: tEn("audit:heading") })).toBeVisible();
     await expect(page.getByRole("alert")).toBeHidden();
 
-    const table = page
-      .getByRole("table")
-      .filter({ has: page.getByRole("columnheader", { name: tEn("audit:whenHeader") }) });
-    await expect(table).toBeVisible();
-    const allRows = await table.locator("tbody tr").count();
-    expect(allRows, "the audit log is empty — the fixture wrote no auditable events").toBeGreaterThan(0);
+    const panels = page.getByRole("article");
+    await expect(panels.first()).toBeVisible();
+    expect(await panels.count(), "the audit log is empty — the fixture wrote no auditable events").toBeGreaterThan(0);
     await expect(page.getByText(tEn("audit:emptyMessage"))).toBeHidden();
 
-    // Filtering is the screen's one interaction, and the assertion has to be
-    // about WHAT CAME BACK, not how much of it.
-    //
-    // An earlier version asserted `filteredRows <= allRows`. That cannot fail:
-    // a filter the server ignores entirely returns every row, and
-    // `allRows <= allRows` is true. Deleting the `action` handling server-side
-    // would have left it green (PR #390 review).
-    //
-    // So: pick a real action and assert that EVERY remaining row is that action.
-    // That is the guarantee the control claims, and a no-op filter fails it as
-    // soon as the log holds more than one kind of event — which the assertion
-    // below on `distinctActions` proves it does, rather than assuming it.
-    const filter = page.getByLabel(tEn("audit:actionFilterLabel"));
-    const actionCells = table.locator("tbody tr td:nth-child(3)");
-    const before = (await actionCells.allInnerTexts()).map((a) => a.trim());
+    const firstPanel = panels.first();
+    const firstSummary = firstPanel.locator("summary");
+    const firstSummaryText = await firstSummary.innerText();
+    await expect(firstSummary).toBeVisible();
+    await expect(firstPanel).toHaveAccessibleName(firstSummaryText);
+    const summaryId = await firstSummary.getAttribute("id");
+    if (!summaryId) throw new Error("the first Audit summary has no id");
+    await expect(firstPanel).toHaveAttribute("aria-labelledby", summaryId);
+    const actorId = await firstPanel.getAttribute("aria-describedby");
+    if (!actorId) throw new Error("the first Audit panel has no actor description");
+    const actor = page.locator(`#${actorId}`);
+    const actorText = await actor.textContent();
+    if (!actorText) throw new Error("the first Audit panel has no actor text");
+    await expect(firstPanel).toHaveAccessibleDescription(actorText);
+    await firstSummary.click();
+    await expect(firstPanel).toHaveAttribute("open", "");
+    await expect(actor).toBeVisible();
 
-    // Count what is actually on screen and filter to one of THOSE actions.
-    //
-    // An earlier version took `options[1]` — the first entry in the filter's own
-    // dropdown. That worked only because `manager.spec.ts` sorts before this file
-    // and performs exactly one adjust per run, so the action happened to exist:
-    // an unstated ordering coupling between two spec files (PR #390 review round
-    // 2). Deriving the target from the rows in front of us has no such
-    // dependency, and it cannot pick an action with zero rows.
+    const filter = page.getByLabel(tEn("audit:actionFilterLabel"));
+    const before = (await panels.locator("summary").allTextContents())
+      .map((summary) => summary.split(" UTC · ")[1] ?? "");
     const counts = new Map<string, number>();
     for (const action of before) counts.set(action, (counts.get(action) ?? 0) + 1);
     expect(
@@ -231,31 +225,19 @@ test.describe("Owner", () => {
         + "from a working one — this spec cannot prove anything against this fixture",
     ).toBeGreaterThan(1);
 
-    // The rarest visible action: the strictest subset available, so a no-op
-    // filter is maximally obvious.
     const chosenLabel = [...counts.entries()].sort((a, b) => a[1] - b[1])[0]![0];
     const option = filter.locator("option").filter({ hasText: chosenLabel }).first();
     const chosenValue = await option.getAttribute("value");
     expect(chosenValue, `no filter option matches the rendered label "${chosenLabel}"`).toBeTruthy();
     await filter.selectOption(chosenValue!);
 
-    // POLL, do not snapshot. `allInnerTexts()` does not auto-retry, and
-    // AuditPage.load() clears `events` to null (unmounting the tbody entirely)
-    // before the filtered page arrives — so reading once, immediately, can catch
-    // the empty transient. The previous version's "wait" was
-    // `expect(getByRole("alert")).toBeHidden()`, which is vacuous here: this
-    // screen renders no alert on the success path, so the locator matches nothing
-    // and resolves on its first poll. That reintroduced exactly the intermittency
-    // the count-free rewrite was meant to remove, on a different axis
-    // (PR #390 review round 2).
-    //
-    // A no-op filter never reaches "settled", so this still fails closed.
     await expect
       .poll(
         async () => {
-          const rows = (await actionCells.allInnerTexts()).map((a) => a.trim());
-          if (rows.length === 0) return "still-loading";
-          return rows.every((a) => a === chosenLabel) ? "settled" : "mixed";
+          const actions = (await panels.locator("summary").allTextContents())
+            .map((summary) => summary.split(" UTC · ")[1] ?? "");
+          if (actions.length === 0) return "still-loading";
+          return actions.every((action) => action === chosenLabel) ? "settled" : "mixed";
         },
         {
           message:

tools/simulation/ui/specs/phone.spec.ts

@@ -717,3 +717,17 @@ test.describe("Phone shell", { tag: "@phone" }, () => {
     ).toBe(clientWidth);
   });
 });
+
+test.describe("Login farm picker at phone width", { tag: "@phone" }, () => {
+  test("the Forget control meets the 44px touch-target floor on both axes", async ({ page }) => {
+    await page.addInitScript(([key, codes]) => {
+      window.localStorage.setItem(key as string, JSON.stringify(codes));
+    }, ["cluckwork.farmCodes", ["farm-a"]] as const);
+    await page.goto("/login");
+
+    const forget = page.getByRole("button", { name: tEn("auth:forgetFarm", { farmCode: "farm-a" }) });
+    const box = await rectOf(forget, "the Forget control");
+    expect.soft(box.width, "the Forget control is too narrow to hit").toBeGreaterThanOrEqual(MIN_TARGET_PX);
+    expect.soft(box.height, "the Forget control is too short to hit").toBeGreaterThanOrEqual(MIN_TARGET_PX);
+  });
+});

tools/simulation/ui/specs/pwa.spec.ts

@@ -97,7 +97,7 @@ test.describe("PWA shell", () => {
       // browser's offline error page.
       await expect(page).toHaveTitle("Cluckwork");
       await expect(
-        page.getByRole("heading", { name: tEn("auth:title") }),
+        page.getByRole("heading", { name: tEn("auth:title"), level: 1 }),
         "the shell did not render offline — the precache is not answering navigations",
       ).toBeVisible();
 

tools/simulation/ui/src/fixtures.ts

@@ -163,7 +163,7 @@ export const test = base.extend<Fixtures>({
       // longer sign in at all. That is not hypothetical; it happened.
       //
       // The bare `main` element is not usable either: the login screen is a
-      // `<main class="auth">` too, so it cannot tell the shell from the form it
+      // bare `<main>` too (#833), so it cannot tell the shell from the form it
       // replaced. The `id` is what separates them — AppLayout's is the only
       // element in the app carrying `main-content`, and the login screen's has
       // no id at all.