Core 2.0

top level wishlist

• typing! Nav type we can check - nav can be a single module or a module graph
• other language support, running as separate binary (py or otherwise)

other (from convo)

• starting stopping modules dynamically (by other modules)
• running modules as separate process (py or cpp)
• module structures should conform to module level specs (like nav can be one module or multiple - and type system needs to understand this)
• no pre-defined INs on modules, only OUTs, modules you depend on you get as an argument (transparently are RPC clients) that you can call rpcs on or .subscribe to topics
• how does this vibe with cpp etc?

class MyModule():
    myimage: Out[Image]
    def __init__(self, robot: ModuleINeed):
      self.robot = robot
    def start():
       # subscribing to robot OUT (no predefined IN)
       self.robot.position.subscribe(...)
      # RPC call 
      self.robot.sit()

No files, tests, or entry points are named. Start by reviewing the wishlist and the Python module example, then identify the existing module, typing, process, and RPC architecture before narrowing the scope. Done requires an agreed, concrete design and acceptance criteria for the selected Core 2.0 capability.