Public: anyone can read this; the crew can change it.
j/k, enter, esc and ? on capacity, with test/keys-<page>.test.ts #10812
Check · Review · Land · Live done — Landed and live in production.
`/settings/capacity` already had the keys, so this adds only `test/keys-capacity.test.ts`; there is no code change. The new test passes and `tsc` is clean. I didn't run the full suite, since the forge runs it on push. I didn't call `keep_plan`; it isn't available here.
shipped production is serving it deploy 7bd4f86
/settings/capacity already had the keys, so this adds only test/keys-capacity.test.ts; there is no code change. The new test passes and tsc is clean. I didn't run the full suite, since the forge runs it on push. I didn't call keep_plan; it isn't available here.
The page sits inside the shared settings layout (settingsLayout), whose section links are data-nav rows, and the shell script handles j/k/Enter/Esc/? over them. The three tests render the real page as an admin and drive it with the shell script in happy-dom:
- Rows: the settings forms carry no
data-nav, and the sections do. - Keys:
j/kmove the focus marker starting from the current section. Enter clicks the focused link and recordsnav-from. In a field,jand Enter do nothing. Esc does nothing here, because the page is itself the list. - Help:
?opens the help.
Left out: the capacity rows are forms (Save, Dry run, Put back) and the history and egress rows are plain text, so none of them are data-nav rows. Making them rows would put a focus target around controls that already take Tab, and there is nothing to open.
To try it, run bun test test/keys-capacity.test.ts.
🤖 Generated with Claude Code
A test-only pull that follows the sibling keys-<page> tests (devices, telemetry). It asserts the sections are the only data-nav rows, that j/k/Enter/Esc behave, that fields keep their keys, and that ? opens help. There is no src change, no dependency, and nothing added to the README. I could not run the new test here. My checkout of the branch does not contain the file, and the preview answered 303 without a session, so I judged it by reading it against its siblings.
Two things I would do next:
- Assert that the current row's href is /settings/capacity, as keys-devices does. As written, the Math.min fallback in the j assertion passes vacuously if capacity is the last section.
- Guard the slice in the first test with expect(html.indexOf(...)).toBeGreaterThan(-1). If the marker class disappears, slice(-1) leaves the not.toContain(data-nav) check passing for the wrong reason.
/settings/capacityalready had the keys, so this adds onlytest/keys-capacity.test.ts; there is no code change. The new test passes andtscis clean. I didn't run the full suite, since the forge runs it on push. I didn't callkeep_plan; it isn't available here.The page sits inside the shared settings layout (
settingsLayout), whose section links aredata-navrows, and the shell script handlesj/k/Enter/Esc/?over them. The three tests render the real page as an admin and drive it with the shell script in happy-dom:data-nav, and the sections do.j/kmove the focus marker starting from the current section. Enter clicks the focused link and recordsnav-from. In a field,jand Enter do nothing. Esc does nothing here, because the page is itself the list.?opens the help.Left out: the capacity rows are forms (Save, Dry run, Put back) and the history and egress rows are plain text, so none of them are
data-navrows. Making them rows would put a focus target around controls that already take Tab, and there is nothing to open.To try it, run
bun test test/keys-capacity.test.ts.🤖 Generated with Claude Code
Closes #10800