sher
  1. 01
  2. 02
  3. 03
  4. 04
Build a simple browser demo for middle-out compression. Let someone paste text, compress it, and see the byte savings immediately.
1 Step

I need to preserve the existing app shell and understand the compression API before I add the demo.

Read app/page.tsx
Read lib/compress.ts

I found the app shell and the middle-out encoder. I’ll build the demo inside that shell and use the encoder’s real byte output for the comparison.

2 Tool calls
Edited components/MiddleOutDemo.tsx +4 -0
+export function MiddleOutDemo() {
+ const result = compress(input);
+ return <ResultCard result={result} />;
+}
Edited app/page.tsx +1 -0
+<MiddleOutDemo />

The first pass is in place: paste text, run middle-out, and compare the original and compressed byte counts in one result card.

Add tests before I send this to Dinesh.
Thinking

The important edges are empty input, Unicode text, data that grows after encoding, and very large pastes.

2 Tool calls
Wrote components/MiddleOutDemo.test.tsx
describe('MiddleOutDemo', () => { /* empty, Unicode, byte totals, and 64 KB guard */ });
$ bun test MiddleOutDemo
$ bun test MiddleOutDemo
4 pass
0 fail

The demo is covered for empty input, Unicode byte counts, incompressible text, the reported ratio, and the 64 KB input guard. All four tests pass.

Make the empty state obvious. I don’t want a blank results panel.

The empty state now asks for text and explains that the original size, compressed size, and savings will appear together.

Check the demo at a narrow phone width before you call it done.
1 Tool call
$ bun run test:e2e --project mobile
$ bun run test:e2e --project mobile
3 pass
0 fail

At phone width the size cards stack below the input and the compression ratio stays visible. The mobile checks pass.

What happens if someone pastes an entire source file?

The demo stops at 64 KB. Profiling kept the encoder under one 16 ms frame at that size; larger inputs should move to a Web Worker rather than freezing the input.

Make that limit clear before people hit it.

The counter now shows remaining bytes and names the 64 KB limit before the input is full. It measures UTF-8 bytes, matching what the encoder receives.

Good. Leave a concise summary for the reviewer.
1 Step

Pied Piper now has an accessible, responsive middle-out demo with real byte counts, a clear 64 KB guard, plain-language savings, and passing tests.

The 64 KB guard also uses UTF-8 byte length, so multi-byte text reaches the same limit the encoder actually receives.

Sher: Share live agent sessions