search.spec: Fehl-Klick entfernt — Reload IST der Weg zurück in den Lesemodus

Der Spec klickte nach page.reload() den Mode-Toggle „um den Edit-Modus zu
verlassen" — nach dem Reload ist die Seite aber schon im Lesemodus (React-
State resettet), der Klick wechselte also HINEIN. Das passierte jahrelang
folgenlos, weil der Fokus auf dem Toggle-Button blieb und „/" die Suche
öffnete. Seit dem Editor-Auto-Fokus (PR #140) landet der Fokus im Editor
und „/" wird dort zu Text — je nach Ausgang des Rennens gegen den rAF-
verzögerten Fokus mal grün (Läufe 381/385), mal rot (383/387/389/390).
Fix: den Klick streichen; „/" läuft im Lesemodus als globaler Shortcut.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0155v2aT8AG1kZDQEZiCLBWC

apps/web/e2e/search.spec.ts

@@ -39,8 +39,13 @@ test('search finds page content, highlights it, and is keyboard-operable', async
   await page.keyboard.type(`the unique ${word} lives in this body`);
   await page.reload();
   await expect(page.locator('.editor-content')).toContainText(word);
-  // Leave edit mode so "/" is a shortcut, not editor input.
+  // The reload already landed back in read mode (the mode state resets), so
-  await page.locator('.editor-page__mode-toggle').click();
+  // "/" acts as the global shortcut here. This spec used to click the mode
+  // toggle again "to leave edit mode" — which actually RE-ENTERED it; that
+  // passed only while entering edit mode left focus on the toggle button.
+  // Since the editor grabs focus on entering edit mode (PR #140), "/" would
+  // become ordinary editor input there, racing the deferred focus — the
+  // intermittent-then-persistent failure of this pack.
 
   // Open search with the "/" shortcut.
   await page.keyboard.press('/');

apps/web/src/styles/base.css

@@ -1623,25 +1623,33 @@ ul[data-type='task_list'] li {
 }
 
 /* The checkbox is the top flex child; nudge it onto the first text line and
-   drop the leading/trailing margins of the item's paragraph so the text meets
+   drop the leading/trailing margins of the item's paragraphs so the text meets
-   the checkbox instead of dropping a line. Covers both DOM shapes: read-mode
+   the checkbox instead of dropping a line. DESCENDANT selectors on purpose
-   `li > input` + `li > p`, and editor `li > label > input` + `li > div > p`.
+   (issue #137, second regression): the DOM depth differs per surface —
-   Uses `:first-of-type`/`:last-of-type` (NOT `:first-child`): in the read-mode
+   public/docToHtml renders `li > input` + `li > p`, but the editor/auth read
-   markup the `<input>` is the first child, so the paragraph is never
+   view (TipTap ReactNodeView) nests the paragraph TWO wrappers deep:
-   `:first-child` and a `:first-child` reset would silently miss (issue #137). */
+   `li > div[data-node-view-content] > div > p`. Child-combinator chains keep
+   missing one of the shapes; matching any `p` inside the task item is the
+   robust form. `:first-of-type`/`:last-of-type` (NOT `:first-child`) because
+   the `<input>`/`<label>` precedes the paragraph in the read-mode markup. */
 ul[data-type='task_list'] li > input[type='checkbox'],
 ul[data-type='task_list'] li > label {
   flex: none;
   margin-top: 0.25em;
 }
 
-ul[data-type='task_list'] li > p:first-of-type,
+/* Editor/auth NodeView only (the bare-input shape has no label): its line
-ul[data-type='task_list'] li > div > p:first-of-type {
+   metrics sit the checkbox ~3px lower than in the public view, so pull the
+   label up by that much — tuned to Stefan's eye on the live stage (#137). */
+ul[data-type='task_list'] li > label {
+  margin-top: calc(0.25em - 3px);
+}
+
+ul[data-type='task_list'] li p:first-of-type {
   margin-top: 0;
 }
 
-ul[data-type='task_list'] li > p:last-of-type,
+ul[data-type='task_list'] li p:last-of-type {
-ul[data-type='task_list'] li > div > p:last-of-type {
   margin-bottom: 0;
 }