Fade the strip's right edge only when content overflows

.claude/skills/manual-test/SKILL.md

@@ -98,8 +98,13 @@ D2. Reach [populated / overflowing state] → [what to look at] → does it look
 - **Design checks are their own section and follow the batching rule** — present them one at a time like any other section, after (or alongside) the functional sections, and don't advance until the user has judged every visual case in the batch. They belong ONLY when a screen's look actually changed; a pure logic/data change gets none. When the user is unsure about a state, proactively offer to look via `/check-screenshot` and compare it to what the design was meant to be — do not vouch for a screen you haven't seen.
 - **Prefer a clean-slate `/cleardb` before the round starts — ONCE, not per-section.** Unless there is an explicit reason to keep the existing data, recommend the user run **`/cleardb`** (then relaunch `./dev.sh`) **before Section 1** so the whole round runs against an empty, predictable DB — existing pins/tasks won't interfere with setup or outcomes. Do this **once per round, before the first section only** — do NOT ask for a `/cleardb` before Section 2, Section 3, etc.; later sections build on the same fresh DB plus whatever earlier sections created. `/cleardb` is `disable-model-invocation` and destructive (it backs up first, stops `./dev.sh`, and needs a relaunch), so **you cannot run it yourself** — the user runs it.
 
-  **ASK before any `/cleardb` — never just instruct.** Whenever you're about to recommend one, put the question to the user with **`AskUserQuestion`** (not plain text) and let them decide, offering at minimum: **clear it** (clean slate, backed up first), **keep the data** (you adapt the setup steps to coexist with what's already there), and where useful **back up only**. Their local DB is often the only copy of real data, and only they know whether it matters right now — so this is their call, not a default you apply on their behalf. Say plainly what a clear costs them (it stops the running app, needs a `./dev.sh` relaunch, and is restorable from the timestamped `.preclear_*` copy) so the choice is informed. If they decline, do NOT re-ask in later sections — adapt the checklist and move on. Reasons to skip/defer it (call them out explicitly): the change is specifically about **existing-data / migration / sync-merge** behavior, the test needs pre-existing fixtures that only live in the current DB, or the user says to keep their data.
+  **ASK before any `/cleardb` — never just instruct.** Whenever you're about to recommend one, put the question to the user with **`AskUserQuestion`** (not plain text) and let them decide, offering at minimum: **clear it** (clean slate, backed up first), **keep the data** (you adapt the setup steps to coexist with what's already there), and where useful **back up only**. Their local DB is often the only copy of real data, and only they know whether it matters right now — so the decision is theirs. Say plainly what a clear costs them (it stops the running app, needs a `./dev.sh` relaunch, and is restorable from the timestamped `.preclear_*` copy) so the choice is informed. If they decline, do NOT re-ask in later sections — adapt the checklist and move on.
+
+  **Always give a recommendation — asking is not the same as abstaining.** You have read the diff and written the checklist, so you know better than the user whether these particular tests need a predictable DB. Put your recommended option **first** in the `AskUserQuestion` list with **"(Recommended)"** in the label, and give the **actual reason from this checklist** in its description — name the test that needs it (e.g. "Section 3 needs a known, small set of eligible leaf tasks, otherwise the 'few pills fit' case can't happen"), not a generic "cleaner is better". This is a testability call, not a taste call, so the no-coin-flipping rule does not apply — never present the options flat and leave the user to guess.
+
+  **Which way to lean.** Recommend **clearing** when the checklist depends on counts, ordering, emptiness, or "not enough items to fill X" states — anything a large existing task set would drown out (Today's 5 empty state, suggestion pools, overflow/no-overflow thresholds, "N others" badges). Recommend **keeping** when the change is about **existing-data / migration / sync-merge** behavior, when the tests need pre-existing fixtures that only live in the current DB, when every test creates its own tasks and is indifferent to what else is there, or when the user has already said to keep their data. Whichever you recommend, state in the same breath what it costs: if keeping, name the specific test that will be weakened and how to judge it anyway.
 - Mention which platform to test on (Linux via `./dev.sh` unless the change is mobile-specific).
+- **Width-dependent tests: use maximise/restore, not "drag the window to half width".** On the dev desktop the app launches at a deliberately phone-shaped **411x820** (`linux/runner/my_application.cc` sets that default size), so the wide and narrow cases are **maximise** vs **un-maximise**. Important caveat: un-maximising returns the window to **whatever size it was last dragged to**, not to 411x820 — the phone-shaped size only comes back on a **fresh `./dev.sh` launch**. So if a section needs the true narrow case and the user has resized during the round, tell them to **relaunch `./dev.sh`** rather than assuming restore is phone-width. Asking the user to "drag the right edge until X no longer fits" makes them fight the window manager for an arbitrary intermediate width. Phrase width tests as **"maximise the window"** / **"un-maximise (restore) it"**, and pick task names long enough that the wide state genuinely fits and the restored state genuinely overflows, so the two built-in states are all that's needed. Only ask for a manual drag when a test truly needs a specific in-between width — and say why.
 - **Present tests in batches by section.** Don't dump all test cases at once — show one section at a time (e.g. "Today's 5" tests first, then "All Tasks" after the user reports results). This prevents the list from feeling overwhelming and lets the user focus. **This applies to the caller too** — when presenting the agent's results, you MUST show only the first section and hold back the rest until the user reports results. Never flatten all sections into one list or present them all at once, even as a "summary". **Do NOT move to the next section until the user has reported results for ALL test cases in the current section.** If the user reports on only some tests (e.g. "1. works" but there are 10 tests), re-display the remaining tests from that section — do NOT advance to the next section.
 - **Snackbar undo tests are time-sensitive.** The undo snackbar only lasts 5 seconds. Rules for undo tests:
   - An undo test must be a **separate, self-contained test case** — never an addendum tagged onto a non-undo test ("now tap Undo").