The only coverage of the simulator→registry position path was either
bridge-level unit tests (registry_bridge_test.go against a fake adapter) or
handler-level immediate-sync tests (TestImmediateSyncOnAddAndUpdate against a
recording fake with explicit positions). Nothing proved a position travels
from the simulator handler all the way into the live fleet.Registry — and
specifically that an origin-default node is written to the registry at the
spread geometry DefaultNodePositions assigns, not co-located at (0,0,0).
Add two end-to-end tests that wire a real SQLite-backed *fleet.Registry
behind the SimulatorHandler (the same wiring cmd/mothership/main.go uses,
via a test-local fleetRegistryTestAdapter that mirrors the production
fleetRegistryAdapter since the latter lives in package main and isn't
importable):
- TestSimulatorHandlerToRegistry_CreateAndUpdate: AddNode (no position) →
CreateVirtualNode → SyncToRegistry → AddVirtualNode into the live registry,
asserting the node lands at exactly DefaultNodePositions(space,1) (never
(0,0,0)); then UpdateNode → SetNodePosition, asserting the new position
flows through to the same registry row without duplicating it.
- TestSimulatorHandlerToRegistry_OriginNodesGetSpreadGeometry: 4 nodes
posted at the DB default origin {0,0,1} must land in the registry at the
distinct, spread-out DefaultNodePositions(space,4) set — never co-located
at the origin (the failure mode in bf-18yn / bf-4q5w).
Split from bf-4oiz. go test ./internal/simulator/... ./internal/api/... and
full go test/vet ./... all green.
Co-Authored-By: Claude <noreply@anthropic.com>
Bead-Id: bf-69ym
14565743c5