[Aqua-123]

Why

The incremental writer flushes every 5 seconds during a recording. For the keyboard file, each flush encoded all presses since the start with KeyboardEvents::to_bytes and kept a second copy of every press. The total work grows with the square of the recording length. #3034 made cursor.json append-only; this does the same for keyboard.bin.

What changed

• New KeyboardEventsEncoder in cap-project keeps the encoded presses and encodes only new ones. Each write is the magic header, the varint press count, then the kept bytes. This is the bincode standard layout, so the file is byte-identical to to_bytes().
• IncrementalFiles uses the encoder and keeps the atomic replace.

Scope

• The file format is unchanged. Disk I/O per flush is unchanged: the file is still rewritten whole.
• The sampling thread still keeps its own press list for the final recorder response.

Verification

• Simulated 1 h recording (720 flushes, 72,000 presses): 506 ms → 1.8 ms total encode time, median of 7 alternating runs. Each run checks the final bytes against to_bytes(). Reproduce with cargo run -p cap-project --release --example keyboard-incremental-encoding-benchmark -- 7.
• New test compares the encoder with to_bytes() after each random batch and at varint width boundaries (250/251, 65,535/65,536). Existing incremental writer tests in cursor.rs pass unchanged.

Confidence Score: 5/5

The PR appears safe to merge; no actionable issues were found.

Summary

This PR encodes each new keyboard press once and keeps the encoded bytes for later flushes.

• Keyboard-file flushes encode only the new presses.

No actionable issues were found. Tests and benchmarks were inspected, not run.

_{Reviews (1) · Last reviewed commit: "perf(recording): append keyboard presses..." · Reviewed by Greptile}

[vercel]

@Aqua-123 is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.