mesh_tools
mesh_tools
¶
The assistant's door to the other devices.
Spec §22 and §33. Two tools, deliberately: one that only looks, one that acts. Splitting them means the model can answer « quels appareils sont allumés ? » without ever entering the code path that sends something.
mesh_devices is read-only and always safe.
mesh_send routes one catalogued remote tool to one resolved device, and
carries the risk metadata that makes the approval system treat it as an
outward action — because it is one: it changes what appears on a screen the
user may not be standing in front of.
What this file refuses to do is as important as what it does. It never takes a device id from the model when a phrase would do, it never invents a tool name, and it never reports a queued command as done: the status and the sentence come straight from the dispatcher, which is the only component that knows the truth.
Classes¶
MeshDevicesTool
¶
MeshDevicesTool(registry: DeviceRegistry | None = None)
MeshSendTool
¶
MeshSendTool(
registry: DeviceRegistry | None = None,
queue: "CommandQueue | None" = None,
)
HandoffContinueTool
¶
Bases: BaseTool
« Continue ça sur mon téléphone » — reprendre ici ce qu'on regarde là.
Spatial Mesh, handoff — 25 août 2026. mesh_send savait déjà envoyer une ressource, à condition qu'on lui dise laquelle : le modèle devait donc connaître un identifiant que rien ne lui donnait. Cet outil part de ce que l'utilisateur REGARDE — le cliché d'écran publié par l'interface — et n'invente rien quand il n'y a rien à reprendre.
Ce qu'il ne fait pas, délibérément : promettre un état de vue. Le client mobile ouvre un écran et met en évidence une tâche ou un projet ; il ne sait restaurer ni onglet, ni filtre, ni position. Envoyer ces champs les ferait voyager sans être lus, et la phrase de confirmation finirait par les promettre. La phrase rendue vient du RÉCEPTEUR, jamais de l'envoi.