···66`tools/browser-automation/*` paths remain as thin compatibility wrappers for
77the current `perlsky` workflow.
8899+## Quickstart
1010+1111+```sh
1212+npm install
1313+npx playwright install chromium
1414+node bin/atproto-smoke.mjs print-example --mode dual > config.json
1515+$EDITOR config.json
1616+node bin/atproto-smoke.mjs run-dual --config config.json
1717+```
1818+1919+For the lowest-friction path, point the suite at an existing PDS and two
2020+existing accounts. The package is intentionally adapter-friendly, but
2121+bring-your-own accounts are the default path for non-Perl PDS implementations.
2222+923## Current Scope
10241125The existing browser automation is already strong enough to be useful outside
···99113The browser layer stays because it catches real `social-app` assumptions and
100114AppView proxying issues. The direct API/AppView layers belong underneath it so
101115regressions become easier to debug and less brittle when the UI changes.
116116+117117+In other words: this project should eventually answer both "does my PDS return
118118+the right protocol shapes?" and "does it still behave correctly through
119119+`bsky.app` and AppView-backed reads?".
102120103121## Planned Next Steps
104122