unitree-go2-multi and unitree-go2-multi-teleop fail startup because no modules are deployed

Description

Summary

Both unitree-go2-multi and unitree-go2-multi-teleop fail during startup because the resulting blueprint has no deployed modules.

The worker pool starts successfully, but no modules are deployed before ModuleCoordinator.build_all_modules() is called.

Both blueprints reproduce the same failure independently.

Reproduction

unitree-go2-multi

cd ~/dimensional/dimos

uv run pytest \
  'dimos/robot/test_blueprint_startup.py::test_blueprint_starts[unitree-go2-multi]' \
  -m '' \
  -vv -s --tb=long

unitree-go2-multi-teleop

uv run pytest \
  'dimos/robot/test_blueprint_startup.py::test_blueprint_starts[unitree-go2-multi-teleop]' \
  -m '' \
  -vv -s --tb=long

Actual behavior

For unitree-go2-multi, startup reaches:

Starting the modules
Worker pool started. n_workers=2
Shutting down all workers...
All workers shut down

No module deployment occurs between starting and shutting down the worker pool.

ModuleCoordinator.build_all_modules() then fails because _deployed_modules is empty:

ValueError: No modules deployed. Call deploy() before build_all_modules().

The startup test reports:

Blueprint 'unitree-go2-multi' exited during startup with code 1.

unitree-go2-multi-teleop independently reproduces the same sequence and exception:

Starting the modules
Worker pool started. n_workers=2
Shutting down all workers...
All workers shut down

ValueError: No modules deployed. Call deploy() before build_all_modules().

Expected behavior

These registered blueprints should either:

1. deploy the modules required for their respective Go2 multi-robot configurations, or
2. not be registered as runnable blueprints if they are incomplete/deprecated placeholders.

ModuleCoordinator.build_all_modules() should not be reached with an empty blueprint during normal execution of these registered blueprint names.

Notes

This appears to be one issue family affecting at least:

• unitree-go2-multi
• unitree-go2-multi-teleop

Both were reproduced independently, so this does not appear to be test-order or full-suite state leakage.

This is also distinct from the hardware/config-dependent startup failures tracked in #4130. These two blueprints fail before attempting to connect to Go2 hardware because no modules are deployed at all.

The underlying cause is likely in the blueprint definitions or registration/configuration path that results in an empty blueprint.

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.

Run the two targeted pytest commands for unitree-go2-multi and unitree-go2-multi-teleop described in dimos/robot/test_blueprint_startup.py, then inspect the blueprint definitions and registration/configuration path. Trace startup through ModuleCoordinator.build_all_modules() and verify that each registered blueprint deploys its required modules, or is no longer registered as runnable if incomplete.