demo-gps-nav fails startup because required WebsocketVisSpec module reference cannot be resolved

Description

demo-gps-nav fails startup because required WebsocketVisSpec module reference cannot be resolved

Summary

demo-gps-nav fails during startup because GpsNavSkillContainer has a required WebsocketVisSpec module reference, but the blueprint does not provide any module that satisfies that specification.

This reproduces consistently when running the blueprint startup smoke test in isolation.

Reproduction

cd ~/dimensional/dimos

uv run pytest \
  'dimos/robot/test_blueprint_startup.py::test_blueprint_starts[demo-gps-nav]' \
  -m '' \
  -vv -s --tb=long

Actual behavior

The blueprint exits during startup.

GpsNavSkillContainer requires the following module reference:

GpsNavSkillContainer
  _vis: WebsocketVisSpec
  optional=False

No module in the blueprint satisfies the required WebsocketVisSpec, so the coordinator fails while resolving module references.

The startup smoke test reports:

Blueprint 'demo-gps-nav' exited during startup with code 1.

Expected behavior

demo-gps-nav should either:

1. Include a module satisfying the required WebsocketVisSpec, or
2. Make the visualization reference optional if visualization is not required for the GPS navigation demo.

A registered software-only blueprint should not fail startup because a required module reference cannot be resolved.

Notes

This was reproduced independently after the full macOS test suite exposed the failure, so it does not appear to be caused by test ordering or state left behind by another test.

This is separate from #4130. The failure is caused by an unresolved required module reference rather than missing robot hardware, credentials, IP configuration, or an external asset.

During cleanup, the run also logged an McpServer/stop error involving cannot join current thread. That appears secondary to the blueprint construction failure and is not the primary issue reported here.

Suggested labels

bug

---

QA provenance clarification

This issue was discovered during a macOS release QA pass using an additional local runtime startup harness that launched registered blueprints and checked whether they remained alive through startup.

The local QA harness was:

dimos/robot/test_blueprint_startup.py

That file was not tracked on main and was not an existing DimOS CI test.

The underlying failure documented in this issue was subsequently reproduced in isolation, so the bug itself remains valid. This clarification is only to correct the original issue wording where it may have implied that test_blueprint_startup.py was already part of the repository or CI.

Runtime startup coverage itself is being discussed separately in #4130.

Start with the isolated command for dimos/robot/test_blueprint_startup.py::test_blueprint_starts[demo-gps-nav], then trace the demo-gps-nav blueprint and GpsNavSkillContainer reference to WebsocketVisSpec. Confirm which module references are registered during startup. Done means the blueprint starts successfully without an unresolved required reference, with the visualization dependency handled according to the issue's expected behavior.