Design and Test an Inspectable Browser Scene

Build log: start with four verbs

The first brief contained four user actions: orbit the field, filter signals by confidence, select a visible signal, and reset. That was enough to define scene state, controls, and tests. The visual direction stayed separate: dark indigo space, warm selection, restrained glow, and labels that remain legible against the field.

A perspective projection was sufficient for this prototype. A real scene graph, mesh geometry, lighting, materials, or camera depth would justify Three.js or another engine. Choosing Canvas kept the starter dependency-free and made its actual technical boundary easy to explain.

Make state observable

The page publishes a narrow inspection surface. Tests can read the selected ID, confidence filter, camera values, visible nodes, scene name, motion preference, and contract version. They can load one of four fixtures and reset to baseline.

window.__SIGNAL_GARDEN__ = {
  version: 2,
  getState() {
    return {
      selectedId,
      confidenceFilter,
      camera: { yaw, pitch, distance },
      visibleNodeIds,
      animation
    };
  },
  loadTestScene(name) { /* deterministic fixture */ },
  reset() { /* known baseline */ }
};

The production-facing portion remains read-only; only fixture loading and reset mutate state for tests. Version 2 adds a keyboard-operable signal selector that reaches the same selection state as clicking a node on the canvas.

Use named moments instead of random screenshots

Each named moment connects an input, expected state, and screenshot. That is more useful than comparing arbitrary animation frames. Reduced motion is also reported in state, so the test records which visual mode it exercised.

The interaction and test pass

The current starter supports drag-to-orbit, arrow-key camera movement, a confidence range, scene buttons, reset by button or R key, canvas node clicks, and a labeled signal selector for keyboard selection. The visible readout exposes node count, selected signal, and camera position. Empty results are announced through a live status region.

We served the updated files on localhost and ran the smoke test in installed Google Chrome at 1440 × 900 with reduced motion enabled. The bounded checks cover state-contract v2, baseline, dense and empty states, keyboard reset, keyboard node selection, and screenshot capture. Human inspection still has to judge hierarchy, label collision, and visual quality. Wider viewport, browser, assistive-technology, and performance coverage remain open.

How an agent can help without becoming the evidence

A coding agent can work from the four verbs, file boundary, test fixtures, and state contract; implement one pass; run the browser checks; then return state plus screenshots for review. For a larger scene, checkpoint the interaction skeleton before spending time on materials and motion. When tools can publish or operate external systems, isolate the environment and keep those actions behind separate approval.

GPT-6 Astra is suitable for a long version of that workflow, especially when the task joins code, browser interaction, screenshots, and changing requirements. It did not generate this starter and was not used in its browser test. The page therefore demonstrates an agent-ready method, not Astra's 3D capability.

Release questions for a real project

• Do pointer and keyboard paths reach the same essential actions?
• Do all fixtures reset to documented state without console errors?
• Are dense, empty, loading, reduced-motion, and asset-failure states readable at target viewports?
• Has performance been measured on representative devices?
• Have third-party assets, privacy behavior, and accessibility been reviewed by the appropriate owners?
• If published, was the exact public URL read back after an authorized deployment?