Investigate: Root Cause Without Guessing

Real run of this skill on the example Notes app in poteto-kit, with a bug seeded for the demo. The prompt did not mention it.

Investigation: search returns nothing when the typed text matches a note title (capitalised titles only)

• Reproduction: REPRODUCED. Steps: npm ci, then npm run verify -- --feature search --scenario shortcut-filters-and-selects (build c0ab390, repo's verify-app). Result FAIL; failing row: a title match leaves only that note | expected ["Grocery list"] | observed [] | FAIL. Artifacts: artifacts/2026-10-19T04-30-32-957Z/search-shortcut-filters-and-selects/ (report.md, screenshot.png, console.json = []).
• Hypotheses:
  • H1 Title is compared without case folding: SUPPORTED. If true, any title containing an uppercase letter misses and body matches still work; refuted if lowercase queries on capitalised titles match. Evidence: src/features/search/filter-notes.ts:8 note.title.includes(needle) while the body goes through normalize(...); needle is lowercased at :12 via normalize (:3-5).
  • H2 The palette mangles or truncates the query before it is filtered: REFUTED. search-palette.tsx:59 passes event.target.value to setQuery unchanged, search-store.ts:23-25 stores it as is, and search-palette.tsx:20 hands it straight to filterNotes. Body-only queries in capitals still match (below), so the query path is fine.
  • H3 Note data in the store has altered titles: REFUTED. Seed titles are intact (src/electron/main/index.ts:5-7), and the same data matches once H1 is toggled.
• Root cause: the title is not lowercased before being compared with the lowercased query (OBSERVED) at src/features/search/filter-notes.ts:8, introduced in c0ab390 refactor search matching (git log -p -- src/features/search/filter-notes.ts; the previous code was note.title.toLowerCase().includes(needle)).
• Confirmation: probe npx tsx probe.ts calling filterNotes on the 3 seed notes.
  Before: "Grocery list" -> [], "grocery list" -> [], "groc" -> [], "Meeting" -> [], "verification" -> ["Meeting agenda"], "REPORT" -> ["Meeting agenda"].
  Toggled line 8 to normalize(note.title).includes(needle): all of the first four return their note, and the scenario goes PASS search/shortcut-filters-and-selects, 1/1 scenarios passed.
  git checkout src/features/search/filter-notes.ts reverted it: [] again for "Grocery list". Symptom follows the toggle both ways.
• Observed facts:
  1. All three seed titles start with a capital letter and none is found by its own title ("Welcome to Notes" -> [], "Grocery list" -> [], "Meeting" -> []).
  2. Body matching is case-insensitive and unaffected ("REPORT" finds Meeting agenda, filter-notes.ts:8).
  3. A single commit touched the search feature after the initial import (git log --oneline -- src/features/search shows c0ab390 and 2ad2643).
  4. The browser console is clean (console.json = []), so this is wrong filtering, not a runtime error.
• Inferences:
  1. A note whose title is entirely lowercase and typed in lowercase would still be found, so the user sees "some" notes missing (INFERRED from line 8; no such seed note exists to run).
  2. Notes whose body happens to contain the title words appear to work, which explains the "some" in the report (INFERRED; e.g. "notes" returns Welcome to Notes only through its body text).
• Unknowns / not checked: other callers of filterNotes (only search-palette.tsx:3,20 imports it, via grep); no title containing non-ASCII characters tested.
• Proposed fix: filter-notes.ts:8 becomes normalize(note.title).includes(needle) || normalize(note.body).includes(needle) (not applied; the repo is back at c0ab390 after the toggle).