Achhina's Digital Garden

2026-07-11 OpenRouter Interceptor Capture Cap and Settings Rewiring

3 min read

2026-07-11 OpenRouter Interceptor Capture Cap and Settings Rewiring

What I set out to do

Follow-up to the 2026-07-09 OpenRouter Interceptor Capture Consolidation work. Now that the sidebar groups captures into one card per character, the 100-capture cap bounds raw requests rather than visible characters, so distinct characters age out under request volume. Goal: raise the cap so the panel reliably surfaces more characters, without accidentally growing storage beyond the intended data.

What I actually did

Confirmed first that the grouping feature is purely display-side: groupCaptures() runs at render time and persists nothing, and the grouping commit touched only captures-list.ts plus a Playwright test. Storage was never in that diff.

Raised MAX_CAPTURES 100 → 1000. While wiring it I found a real defect cluster in the settings layer:

  • settings.maxCaptures was a dead field: background.ts enforced a hardcoded constant and never read the setting.
  • The options page “Maximum stored captures” dropdown (id=maxCaptures) persisted to settings.maxOptionsCaptures, a different key, so the labeled control drove nothing.
  • Root cause: two separate default-settings objects using divergent key names (maxCaptures in background vs maxOptionsCaptures in options), plus background.ts only ever reading downloadPath/autoDownload. The entire capture-behavior settings family (autoCapture, notifyCaptures, and their *Options* twins) was unread.

Fixes, each on its own branch, fast-forward merged to main:

  1. b705764 raise cap to 1000.
  2. b9e6693 make maxCaptures live (background enforces settings.maxCaptures, constant is now the fallback) and wire the dropdown to the correct field; added a 1000 option; removed orphaned maxOptionsCaptures.
  3. aac2364 make autoCapture functional (extracted shouldCapture()/resolveMaxCaptures() into a pure, unit-tested src/utils/capture-settings.ts; gate handleOpenRouterRequest on it); removed the notifyCaptures control entirely (chose removal over adding the notifications permission for per-capture desktop spam); dropped the dead autoOptionsCapture/notifyOptionsCaptures fields; added a test:unit npm script.

What was striking

  • The notifications permission was absent from the manifest, which turned “make notifyCaptures work” into an outward-facing permission change. That is a genuine user decision (permission re-prompt on update), so I asked rather than defaulted; user chose to remove the control.
  • The unit tests (vitest) were never wired into any npm script or the pre-commit hook. They only ran via ad-hoc npx vitest. Added test:unit so coverage is discoverable. Pre-commit still runs only prettier/eslint/tsc-files, not the unit suite.
  • Storage-layer dedup (an alternative to raising the cap) is a trap here: analysis queries persist a captureId and the sidebar resolves “view capture” by id, so replacing/merging captures orphans those references. Display grouping stays non-destructive; raising the cap is the safe lever.

Verification

typecheck clean · test:unit 356 pass (24 files, +7 new) · npm test Playwright 211 pass.

Graph View

Backlinks