Skip to content
KAMOUniverse

Changelog

What's new.

Every improvement to the platform, as it ships.

  1. · SecurityService

    IoT reports — no god mode, the owner rule, and ReportDefinition.exportRight enforced at download, schedule and every run (SP13)

  2. · SecurityService

    SecurityService opens Service Work jobs for IoT — endpoints, one-transaction opener, crossapp scan (SP13)

  3. · kamo-internal

    The Advanced tab's Kamo OAuth client panel — status, one-time secret, Amazon vendor id, activate (IoT SP09)

    SecurityService P1-P3 **************** had no screen, so operator step B5 (generate the Alexa client secret, register the vendor id's redirect addresses, activate) could not be done. The proxy relays exactly three shapes; the new secret appears once, in its own dialog, never in a list.

  4. · kamo-shared-library

    IoT Activity and IoT Command Audit reports

  5. · kamo-shared-library

    IotReportSupport (SI clamp, vendor retention, lookups) and IotAlarmReportMapping

  6. · kamo-shared-library

    ReportDefinition.exportRight — a per-report export right on top of EXPORT_REPORTS

  7. · kamo-shared-library

    SP13 availability calculator and vendor-retention windows

  8. · EmailService

    Deleting a contact clears the IoT devices tagged to it (SP13)

  9. · kamo-shared-library

    SP13 message template and value text

  10. · kamo-shared-library

    SP13 trade map, priority map and diagnostics policy

  11. · MediaService

    MediaService internal chat-post and chat-target endpoints for IoT (SP13)

  12. · kamo-shared-library

    SP13 service-job link entity, repository and six activity kinds

  13. · EmailService

    IOT_ALARM phone push body and withdraw-with-update (SP10)

    An IOT_ALARM event card (source **************** as iot-service's AlarmNotifier writes it, or <alarmUuid>:<seq>) is mirrored as an IOT_ALARM push: channel/colour/vibration by priority, sticky when URGENT, tag and collapse key iot-alarm-<alarmId>. Other cards keep the NOTIFICATION push; mirrorToPush is unchanged. POST **************** withdraws as the DELETE does (id may be <alarmUuid>:* for every event card of one alarm) and, with an update, sends each member who had a tray entry one replacement push with the same tag on iot-alarm-updates.

  14. · MediaService

    Holder-only relay topic /topic/iot/relay/{connectionId} (SP10)

    Core NATS iot.relay.{uuid} is relayed verbatim to /topic/iot/relay/{uuid}. The frame is a wake only **************** SUBSCRIBE needs iot-service I-OD1 (GET **************** ?memberId=, answer {allow, orgId}) to say the session's member holds the live lease in the session's org; cached 10 s either way, fail closed. Client SEND to the prefix is refused.

  15. · MediaService

    IOT_ALARM — exempt from the presence gate and the rate limit (IoT SP10)

    An alarm is not seen because a browser tab is open, and every lifecycle step (raised, escalated, acknowledged) shares one collapse key, so the 15 s limit would drop the escalation. The SI-member refusal stays first. APNs marks an URGENT alarm time-sensitive; no Critical Alerts entitlement.

  16. · KlusterServices

    Iot.relay.> — svc_iot publishes, svc_media subscribes (IoT SP10)

    The Google Home relay wakes the phone that holds a connection's lease: IoTService publishes a content-free frame on iot.relay.{connectionId} and MediaService forwards it to the holder-only STOMP topic. No other user gains the subject.

  17. · kamo-shared-library

    On-device vocabulary and iot_on_device_links entity (SP10)

    The link entity keeps only the SHA-256 of the phone's link secret, and that hash is @JsonIgnore so it never reaches a response or an event.

  18. · kamo-internal

    Charter editor lists OPERATE_DEVICE and OPERATE_SECURITY_DEVICE; KamoAI master §11 and IoT master §10 rows (SP11)

    ACTION_CLASSES ends with the two IoT SP11 classes and APPROVAL holds 24 items (one per shared-lib AiActionClass). The KamoAI master gains its §11 row for the iot_ pack; the IoT master gains the SP11 execution row (E1-E6).

  19. · MCPGatewayService

    Classify the ten iot tools; the catalogue guards move 101 to 111 (SP11 P12)

    The three iot writes are NOT_DISCLOSING and the seven reads NOT_CONTENT with the spec's reasons (pinned in ContentReadToolsCoverageTest too). RegistryCompletenessTest: 111 tools, the also-classes, the performers of the two classes, **************** ApprovalsCoverageTest: both classes UNLISTED, approvals_request unchanged. ToolListParityTest's org has every app but IoT (its snapshots predate the app); IotToolListTest covers an org with it. The golden schema file gains exactly ten iot lines and loses none.

  20. · MCPGatewayService

    IotCallerView and the pure view rules V1-V11 (SP11 §4.4)

    A key a device lists twice is a manifest defect and is never used (fail closed).

  21. · MCPGatewayService

    IotManifestClient, a per-session ETag-validated manifest cache with single flight (SP11 §4.4)

  22. · MCPGatewayService

    Per-caller schemas and availability for the ten iot tools (SP11 §4.5)

  23. · MCPGatewayService

    IoT error map, value checks, class check, whitelisted results and the command watch (SP11 §4.7, §4.9)

  24. · MCPGatewayService

    IotPack, the ten iot_ tools on the Tool Plane (SP11 §4.6-§4.10)

  25. · MCPGatewayService

    Downstream approval headers, conditional GET with ETag, opt-in error fields (SP11 P11)

  26. · MCPGatewayService

    CallerSchema per caller after visibility; PHYSICAL after outside content always asks a person; the approval travels on the plan (SP11 P4-P7)

    A static tool's schema and availability may depend on the caller (CallerSchema): viewed after visibility for tools/list (one 3 s budget shared by the list) and again for every call (10 s), withheld -> TOOL_NOT_AVAILABLE {reason}; a view that widens its base or throws withholds the tool. For an SI, a PHYSICAL call whose charter outcome would execute is asked of a person when the run is externally tainted (D8). An approved or approver-edited re-execution, or a verified request standing in for the approval, reaches its handler with ToolPlan.APPROVAL = ApprovalRef(approvalId, decider, class, mode) (kept on the call's own plan, so the verified-request, basis and regarding keys stay).

  27. · MCPGatewayService

    ToolRisk.PHYSICAL, the iot_ prefix, two charter classes, the IOT door and ApprovalRef (SP11 P1-P3, P8-P10)

  28. · AIService

    Brief words for the two physical charter classes; copilot ceiling pinned (SP11)

    CharterCompiler words OPERATE_DEVICE and OPERATE_SECURITY_DEVICE and keeps both silent while unnamed (as the two team classes of CP05 R1-3), so no existing SI's brief text changes and VERSION stays. CopilotCeilingTest pins the human

  29. · SecurityService

    Purge sweep, OAuth configuration and the repository scan (IoT SP09)

  30. · SecurityService

    Internal grant revocation for IoTService and platform client administration (IoT SP09)

Your universe is waiting.

Start free in minutes. Add products whenever you are ready — no migration, no new logins.

Start freeBuild your universe

Free forever — no credit card required