fix(zoom): stop reporting map labels as a precise address (#13)

[omarshahine]

Fixes #13.

What was actually wrong

The issue reported that the macOS 27 beta redesigned FindMy so a row click no longer reveals a precise location, making --zoom ineffective. Reproduced on macOS 26.6.2 — the redesign already shipped, and the failure is worse than "ineffective":

$ findmy person "Lora Shahine" --zoom --json
{
  "name": "Lora Shahine",
  "location": "Winston-Salem, NC",
  "precise_address": "Champaign Point, 3D"      ← a lake headland and the map's 3D control
}

Every person returned the same string, because it came from the map canvas, not from them. Wrong location data labelled precise is worse than no data.

Root causes

Three separate defects, each verified on this machine:

1. screencapture -l includes the window's drop shadow. A 1024x768 window captured 2184x1672 instead of 2048x1536 — ~34pt of padding per side. The image-to-window point mapping assumes the origins coincide and that imageWidth/windowWidth is the backing scale; the shadow breaks both, inflating the derived scale to 2.13 and landing every synthesized click ~22pt low and ~25pt right. The row was never selected at all. -o omits the shadow and makes the arithmetic exact. The redesigned sidebar also moved the name column in to ~66pt from the window edge, under the old 80pt cutoff, so pixelLayout drops to 60pt (which still clears the older split-view layout's ~90pt).

2. No guard that a detail pane exists. ExtractDetailPaneAddress took the first line right of the sidebar as the header and everything after as the address. On a full-bleed map that is map furniture. The sidebar parser has had RequireSidebarVisible for this exact class of bug since the beginning; the detail-pane side had nothing.

With the click fixed, the redesign's actual answer is visible: a callout pinned to the map, carrying the entity's name over the same coarse location and staleness the sidebar already showed — no street address anywhere. So the header now has to match the clicked row's name, and address lines have to sit in the header's column. Header matching is against the entity name rather than DetailButtons() because that list is English-only and never populated per-locale, so gating on it would have broken every localized install.

3. looksLikeAddressLine matched street words as substrings. "Winston" matched "st", "Redmond" matched "rd", "Kirkland" matched "ln". Whole words only now, and a line carrying FindMy's • location/staleness separator is never an address.

Behaviour now

$ findmy person "Lora Shahine" --zoom --json
warning: --zoom read no precise address for "Lora Shahine".
         macOS 26 replaced FindMy's split view with a floating sidebar over a
         full-window map. Selecting a row now opens a map callout carrying the
         same coarse location as the sidebar, not a street address, so there is
         nothing more precise on screen to read. See issue #13.
{
  "name": "Lora Shahine",
  "location": "Winston-Salem, NC",
  "staleness": "Now",
  "distance": "2,273 mi"
}

Warning on stderr, exit 0, coarse reading intact — --json pipelines keep working, and precise_address is simply absent rather than invented. Documented under Limitations in the README.

Verification

go test ./..., go vet ./..., gofmt -l all clean. New tests cover both real captures (map canvas, map callout), the substring street-word bug, and pane-present-but-no-address.

Live on macOS 26.6.2, people / devices / items output was diffed against a binary built from origin/main — identical, apart from the fabricated address going away.

Worth knowing: PR CI here is plugin-inspector only and never runs go test ./..., so the Go verification above is local.

Out of scope, filed separately

While verifying I hit an intermittent Devices-tab parse where names and locations swap (Home • 3 days ago as the name, Omar's AirPods Max as the location). It reproduces identically on origin/main, so it is pre-existing and unrelated to this change. Filed with OCR evidence rather than widened into this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VDD6P9ft7DNNbrXpNWvCsk

[greptile-apps]

Greptile Summary

The PR prevents --zoom from reporting map furniture as a precise address when newer Find My layouts show a map callout instead of a detail pane.

• Omits window shadows from captures to restore accurate image-to-window coordinate mapping.
• Validates detail panes against the selected entity and filters address lines by shape and alignment.
• Warns without failing when no precise address is available, preserving JSON pipeline behavior.
• Adds regression tests for map canvases, callouts, address classification, and empty-address panes, plus documents the macOS 26 limitation.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete changed-code defect identified.

The changes consistently prevent unverified map text from entering precise-address output while retaining coarse results and successful command behavior when no detail address exists.

Important Files Changed

Filename	Overview
internal/findmy/findmy.go	Corrects capture geometry and adds entity-header, column-alignment, and whole-word safeguards around OCR-derived precise addresses.
cmd/findmy/main.go	Passes the selected entity name into detail extraction and treats unavailable precise addresses as a nonfatal warning.
internal/findmy/detail_pane_test.go	Adds focused regression coverage based on map-canvas and map-callout OCR captures, along with matcher and address-shape cases.
README.md	Documents that macOS 26 and later no longer expose a street address through the zoom interaction.

Sequence Diagram

sequenceDiagram
  participant CLI
  participant FindMy as Find My
  participant OCR
  CLI->>FindMy: Capture shadow-free sidebar
  CLI->>FindMy: Click matched entity row
  CLI->>FindMy: Capture resulting view
  CLI->>OCR: Read positioned text
  OCR-->>CLI: Header and candidate address lines
  alt Matching detail-pane header and valid address
    CLI-->>CLI: Populate precise address fields
  else No pane or no precise address
    CLI-->>CLI: Preserve coarse result and warn
  end

Loading

_{Reviews (1): Last reviewed commit: "fix(zoom): stop reporting map labels as ..." | Re-trigger Greptile}