ASTRO ATOMICA
← Making Henge · All case studies

CASE STUDY 02 / LOOPS & HARNESSES

Make the next mistake observable

Small state fixtures, real hit targets, and a repeatable route from a visible defect to a regression check.

Astro Atomica · Engineering notes · November 8, 2026

The useful unit of agent-assisted development is a closed feedback loop: change something, observe what happened, and turn the failure into a cheaper check for the next iteration.

Give the agent a state it can reach

Henge’s composable UX workflow asks for small transitions with known inputs. To test a paused turn becoming a handoff, start from a paused fixture. Replaying a long setup sequence for every test adds opportunities to miss the relevant state.

The application integration tests use a test session repository, fake timers and a real app controller. They can inspect saved state while exercising the DOM. A thin integration layer connects the rules to the actual controls; lower-level tests isolate the transformations.

Shared instructions live in the visible agents/ tree, with AGENTS.md as the entry point. That gives successive agents the same product rules, observation requirements and workflows instead of relying on one chat’s memory.

  1. Describe the failureA control looks correct but the edge of its visible box misses.
  2. Reach the stateOpen a known layout, viewport and settings surface.
  3. Measure the behaviorProbe the hit target, its corners and the gap beside it.
  4. Repair and retain the checkAlign the visible geometry and rerun the audit.

The button audit tests more than the center

An early toolbar defect exposed a mismatch between visible button size, grid slots and inherited padding. Invisible hit-area extensions also made nearby space clickable. The resulting decision was simple: the visible control should own its click target.

The repo-local browser harness measures control rectangles and uses elementFromPoint at the center and inset corners. It also samples the gaps between neighbors. The initial audit defines a 44-pixel target for ordinary controls and an explicit smaller allowance for player gears, rather than hiding the compromise.

That changes the review question from “does the screenshot look right?” to “does every tested part of this visible control activate the intended action?” Browser geometry remains necessary even when unit tests pass.

Measure what moves during play

Later iterations examined layout before and after pause, resume, expiry, handoff and digit rollover. The project records fixes for expanding expiry actions, inserted List action rows, long names, changing borders and missing Treemap context.

The audit matrix separates intentional motion—the wheel or queue moving to the next player—from unintended movement in surrounding controls. It covers portrait, desktop and short landscape, representative themes, and dense eight-player layouts. Regression tests then protect specific failures such as focus loss or replacing a Grid control during an update.

The retained event trail adds another observation route. It records accepted and ignored transitions and supports diagnostic snapshots. It helps explain how the app reached a state, rather than relying on the final screenshot alone.

Keep the loops at the right cost

Fast domain tests, browser interaction checks, visual inspection and native release checks answer different questions. The web/NAS publishing path allows frequent interface iteration without advancing a native build counter. Validated changes can then be batched into a deliberate paired mobile release.

The lesson is not that an agent can verify everything automatically. It is that each discovered failure can leave behind a reproducible state, a clearer contract, or a harness that makes the next review more reliable.