Keyboard shortcuts designed for efficient agent testing

cmoriarty commented

2026-09-15 00:27:06 -04:00

Owner

I read that shopify engineers are designing their applications to have very robust keyboard control so agents can run UI tests quickly and headlessly. Lets implement it in braid, and see if there are any efficiency gains in doing UI testing driven by keyboard control. Or perhaps it will imrpove scripting of UI tests. Or both?

Here is the article if you want to reference:
https://shopify.engineering/back-to-native

I read that shopify engineers are designing their applications to have very robust keyboard control so agents can run UI tests quickly and headlessly. Lets implement it in braid, and see if there are any efficiency gains in doing UI testing driven by keyboard control. Or perhaps it will imrpove scripting of UI tests. Or both? Here is the article if you want to reference: https://shopify.engineering/back-to-native

cmoriarty referenced this issue

2026-09-15 11:18:01 -04:00

Audit test suites for performance #39

cmoriarty referenced this issue from a commit

2026-09-26 18:32:35 -04:00

feat(ui): every console action has a key and a name, and the tests split into a fast lane and a full one (#30, #39)

cmoriarty referenced this issue from a pull request that will close it,

2026-09-26 18:33:32 -04:00

feat(ui): every console action has a key and a name, and the tests split into a fast lane and a full one (#30, #39) #58

cmoriarty closed this issue

2026-09-26 18:40:10 -04:00

cmoriarty commented

2026-09-26 18:41:20 -04:00

Author

Owner

Shipped in #58 (commit c88c254) and archived as openspec/changes/archive/2026-09-26-keyboard-commands-and-fast-tests. The behaviour is specified in openspec/specs/keyboard-commands.

What shipped

Every console action is a named command with keys: g r / g i / g m / g s (runs, inbox, inference, settings), n (new run), ] / [ (next and previous run), j/k or ↓/↑ (steps), g a (the step the run is on), t / v / d / r (transcript, review, details, redo), Y (accept a failed step), h (thinking), a (subagents), i (composer), S / R (stop and resume the run). Esc closes the lens, then leaves the step, then the run.
A command is available exactly when its button is on screen. Redo and Stop open their confirmations. Keys never fire while you type or while a dialog is open.
? opens a sheet built from the same command table the keys use, so it can't drift from them.
window.braid exposes commands(), run(id) and state(), so an agent can drive the console and check the result without reading the page.

Is it more efficient? Yes. e2e/keyboard.spec.ts runs the same six-move tour both ways: 94 ms by keys against 255 ms by clicks on its own, and 241–360 ms against 595–617 ms with other specs running. That's roughly 2–3× in Playwright. An agent driving a browser through tool calls saves more, because one key press or braid.run replaces a page read plus a find plus a click. It also simplifies scripting: specs can assert on braid.state() instead of on the DOM.

Shipped in #58 (commit c88c254) and archived as `openspec/changes/archive/2026-09-26-keyboard-commands-and-fast-tests`. The behaviour is specified in `openspec/specs/keyboard-commands`. **What shipped** - Every console action is a named command with keys: `g r` / `g i` / `g m` / `g s` (runs, inbox, inference, settings), `n` (new run), `]` / `[` (next and previous run), `j`/`k` or ↓/↑ (steps), `g a` (the step the run is on), `t` / `v` / `d` / `r` (transcript, review, details, redo), `Y` (accept a failed step), `h` (thinking), `a` (subagents), `i` (composer), `S` / `R` (stop and resume the run). `Esc` closes the lens, then leaves the step, then the run. - A command is available exactly when its button is on screen. Redo and Stop open their confirmations. Keys never fire while you type or while a dialog is open. - `?` opens a sheet built from the same command table the keys use, so it can't drift from them. - `window.braid` exposes `commands()`, `run(id)` and `state()`, so an agent can drive the console and check the result without reading the page. **Is it more efficient?** Yes. `e2e/keyboard.spec.ts` runs the same six-move tour both ways: 94 ms by keys against 255 ms by clicks on its own, and 241–360 ms against 595–617 ms with other specs running. That's roughly 2–3× in Playwright. An agent driving a browser through tool calls saves more, because one key press or `braid.run` replaces a page read plus a find plus a click. It also simplifies scripting: specs can assert on `braid.state()` instead of on the DOM.

Rows
Columns

Keyboard shortcuts designed for efficient agent testing #30