| name | browser-automation-core |
| description | Shared reference for the browser-automation cluster: the surface model (web/DOM vs native macOS UI), the session lifecycle (one-shot vs persistent vs supervised-TTY), the recon-then-act selector strategy, and the debug-first evidence rule every spoke shares. USE WHEN choosing an automation engine, targeting elements, or deciding what counts as proof a UI works. |
| cluster | browser-automation |
| version | 1.0.0 |
Browser Automation Core
Shared model for the browser-automation cluster. The drivers all differ in what they touch and
how long they live โ keep these concepts consistent here so no spoke contradicts another.
1. The decision the cluster turns on: which surface?
Everything starts with one question โ what are you actually driving? There are two surfaces,
and they do not overlap:
โโ Web / DOM surface โโโโโโโโโโโโโโ โโ Native OS surface โโโโโโโโโโโโโ
your target โโโ โ a page in a Chromium browser โ OR โ a desktop app's real UI โ
โ โ selectors, accessibility tree โ โ โ OS accessibility elements โ
โ โ browser / webapp-testing โ โ โ peekaboo โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
- Web/DOM โ anything rendered in a browser. You target CSS selectors / ARIA refs inside the
page. Drivers: (headless Chromium, debug-first) and (Playwright against
a local dev server).