# Bugs

# M1 — One agent end to end

# M2 — Seeing the work

# M3 — Second vendor and review

# M4 — Merging and history

# M5 — Workflows

# M6 — Fan-out

# M7 — Inbox triage

# M8 — macOS client

- macOS client feasibility build
  See `docs/macos.md`. Throwaway AppKit + WKWebView shell with a UI/navigation delegate and the Notification polyfill, pointed at a development byre. Compare with Safari: identity and both SSE streams, terminal Ctrl keys, typed vs Go-menu ⌘K/P/L/S/ with a dialog open, screenshot paste and Finder drop, code Copy, every `_blank` link type, notification permission and click, blur on app switch and window close, an hour hidden then a question, sleep/wake, quit with a draft. Record OS/SDK and signing results.
- macOS client shell
  `mac/` Xcode project: one window hosting a persistent WKWebView on the configured origin, connection sheet with 401/403/TLS/unreachable errors and Change Server…, `_blank` and off-origin links to NSWorkspace, menus with no File menu and no key equivalents for page shortcuts, hide-on-close, quit via pagehide, reload-once crash recovery.
- macOS client notifications
  Document-start `Notification` polyfill backed by UNUserNotificationCenter via a main-frame, origin-checked message handler; `tag` as request id, click shows the window then calls the page's onclick; permission re-read on activation.
- macOS client parity review
  Side by side with Safari on the same server, size and appearance, using disposable tasks: every tab, switcher, Inbox choice types, merge/discard dialogs, light/dark, narrow windows, IME. Document build, setup, storage and limits in `docs/operations.md`.