- Shipped
- October 19, 2026 at 1:50 AM UTC
- Author
- Kamo
- Commit
- 10edd93
- IotPack.planSend: when the SI's own view lacks the device or the function (or may not OPERATE it) and the caller is on an order-scoped session, IoTService's GET **************** is asked whether the order's REQUESTER may operate it; its item is planned like any other (same value checks, class by safety class, summary), else the existing DEVICE_NOT_AVAILABLE / **************** IoTService lends the grant and audits it. - New read iot_order_devices (functionKey, optional name and deviceId), AI_ONLY and listed to an SI always: "Devices the person who gave you this order can operate with a function, while you carry out their order." NOT_ON_ORDER outside an order. Items are re-checked as an SI's view is (IotOrderFunctions / IotViewRules.orderFunction): never STREAM or camera.snapshot, SAFETY_CRITICAL and above the SI ceiling only on god's order, VERIFIED only (UNVERIFIED too on god's order, never FAILING), only the asked key, and none when the answer is not for this order's requester. - On an order iot_send_command is offered on its base deviceId/functionKey (no enum of the SI's own devices, never withheld IOT_NOTHING_AVAILABLE), so a device the lookup found can be named. - IotViewRules: a god-order view (Round 2) also keeps UNVERIFIED functions (V2), never FAILING. - Catalogue golden **************** regenerated: exactly one line added, iot_order_devices; registry size 163; ContentReadTools entry.