Turning Arc behavior into testable contracts

“Feature parity with Arc” was a useful research prompt. It was a terrible implementation ticket.

A model can list product features all day: compact chrome, command palette, floating agent panel, split view. That list does not tell an agent, or a test, what done means. Visual resemblance is not a state transition.

I needed the boring form: each inspiration becomes an invariant the browser can check.

Compact chrome stopped meaning “feel dense.” In Narada it means the chrome strip has a fixed height, and the page viewport starts immediately under it. Today that height is 48 CSS pixels in shared layout code, and the browser-chrome e2e keeps the native view glued to that boundary when the window resizes.

The agent panel stopped meaning “a chat that sits somewhere on the page.” A compact floating panel opens without resizing the native page. Docking is allowed later, but only as an explicit layout change the tests can see in bounds, not as accidental DOM stacking over the web content.

Commands stopped meaning “something like Arc’s palette.” The omnibox is a separate overlay window placed under the chrome. Accepting a suggestion routes somewhere concrete. Escape dismisses it. The viewport stays put.

The same rewrite applies to the softer product language:

• background agent work should not steal the active tab or typing focus unless the person asked for take-over
• agent-created tabs can carry session identity; claimed user tabs should not silently regroup
• tooltips and pointer feedback over the page are child windows with known titles, not z-index fights inside the document

None of that is full Arc parity. Several surfaces are still contracts and tests, not finished product polish. The point is the translation step: once a behavior is an invariant with a screenshot or native snapshot, coding agents and humans argue about the same thing.

I still use other browsers with Computer Use when I am discovering what to care about. I do not treat “looks like the reference” as the implementation ticket. Write the contract. Measure the bounds. Then ship.

Blog series: discovery first, then proof. Next is scoring “done” without trusting the model alone.

Narada: narada.koley.in