@7365admin1/core 3.79.1-staging.350 → 3.79.1-staging.351

package/CHANGELOG.md

@@ -1,5 +1,199 @@
 # @iservice365/core
 
+## 3.89.0
+
+### Minor Changes
+
+- d3afd05: Robots: a network-wide listing for the Seven365 console (`useRobotNetworkController` - `listNetworkRobots`, `getNetworkSummary`). Every robot at every client site, with client and site names, paginated, searchable, filterable (client, site, class, brand) and sortable; soft-deleted robots excluded; no credentials; no live vendor calls. Gated on the super-admin membership with the cross-client grant.
+
+## 3.88.0
+
+### Minor Changes
+
+- 81cb7d9: Robots: building maps (per-floor doors, lift shafts, levels, drawn walls/zones; versioned saves, soft delete) and a durable lift queue (one holder per lift, lease/timeout, release; simulated car for demo robots). New collections `robot-building-maps` and `robot-lift-sessions` with index helpers.
+
+## 3.87.0
+
+### Minor Changes
+
+- 07d82bd: Robots: edit and remove, an audit trail, fault notifications, and spot cleaning
+
+  - `useRobotController` gains `updateRobot` (name, serial) and `deleteRobot` (soft
+    delete via the existing `deletedAt` field; removed robots stop listing and
+    answer as not found). The estate is read off the stored robot.
+  - Robot create, edit, remove and every accepted command write a console-audit
+    row (`robot.*` actions). The credential pair is not on the allow-list.
+  - A robot reporting a fault notifies Seven365 staff once per occurrence
+    (`platform` category), noticed on a state read. `ROBOT_FAULT_NOTIFY=off`
+    silences it. The demo brand faults two minutes in every thirty.
+  - New `spotClean` capability; a spot command needs it. The demo brand has it;
+    Ounitech does not until its pixel frame is verified.
+  - The state response carries `fault` and `capabilities`.
+
+## 3.86.0
+
+### Minor Changes
+
+- f6b10f4: Route the fleet through the adapter, and add a demo brand you can actually see
+
+  The vendor-neutral contract shipped but nothing used it: the fleet service still
+  called Ounitech directly, so a second brand could not have worked end to end.
+  Everything now goes through `TRobotAdapter`, and the registry holds a FACTORY
+  per brand — an adapter is built per robot from that robot's own credentials, so
+  one estate's appid can never sign another estate's request.
+
+  Adds a demo brand: three simulated robots on two floors that move, drain and
+  recharge their batteries, respond to commands, and carry generated floor plans
+  as PNG data URIs. It reaches no network and writes nothing.
+
+  It exists because until a vendor supplies credentials every robot screen is
+  empty and no button can be pressed — and because it is a second brand on the
+  same contract, declaring Full Control where Ounitech reaches no tier at all. If
+  the screens draw different controls for the two without being told which is
+  which, the platform really is brand-agnostic.
+
+  Adds `GET /robots/brands` so the Add Robot form can offer them, each with its
+  Open-RMF tier.
+
+## 3.85.0
+
+### Minor Changes
+
+- 8afb16f: The robot's live position, streamed
+
+  Adds `robot-tracking.service.ts` and a `trackRobot` SSE endpoint. The parsing,
+  staleness and backoff shipped earlier were pure and tested but nothing opened a
+  connection, so nothing was ever live — the screens read `get-robot-list`, which
+  carries no position at all, and the 3D layout could not draw the robot.
+
+  The stream follows a viewer rather than running as a fleet-wide daemon: a screen
+  opens it, the API opens one upstream, and both close when the viewer leaves.
+
+  Events are ours, not the vendor's frames: a normalised pose, and an explicit
+  `lost` when the stream goes quiet — a screen has to tell "the robot is here"
+  from "we no longer know where the robot is", and the vendor's stream cannot say
+  the second thing.
+
+## 3.84.0
+
+### Minor Changes
+
+- 3c562a9: Building map: a floor plan, and the 3D layout generated from it
+
+  Adds `building-map.util.ts` — the Open-RMF building-map model (levels, vertices,
+  walls, floors, doors, measurements), the scale handling, and the generation step
+  that turns an annotated level into the geometry a 3D view draws.
+
+  The shape is taken from a real `office.building.yaml` in `open-rmf/rmf_demos`,
+  and the wall defaults are `traffic_editor`'s own (10cm thick, 2.5m high, 1px =
+  5cm before a measurement), so a map made here can be exported to RMF and one
+  made in `traffic_editor` read here.
+
+  `wallsFromOccupancyGrid` traces walls straight out of a floor-plan image, so
+  uploading a plan produces a layout without anyone drawing walls by hand — a SLAM
+  occupancy grid already marks walls as dark pixels.
+
+  `buildingMapFromRobotMaps` reads the cleaning robot's own floor maps into that
+  model: one level per floor, the vendor's resolution as the scale, its origin as
+  the level offset, its cleaning areas as RMF cleaning-zone waypoints and its dock
+  as a charger.
+
+## 3.83.0
+
+### Minor Changes
+
+- b9d7f9c: Robot fleet: a vendor-neutral adapter contract, so any brand can be integrated
+
+  Adds `robot-adapter.util.ts` — the capability model, the tier calculation and the
+  brand registry — and `ounitech.adapter.ts`, the first brand behind it.
+
+  The capability names and tier requirements are Open-RMF's, verbatim from the
+  Fleet Adapters table: Full Control, Traffic Light, Read Only, No Interface. That
+  means a brand's datasheet reads straight into a tier, and a vendor conversation
+  gets a name ("your API is Read Only, we need Traffic Light") rather than a list
+  of features we would like.
+
+  Screens ask the adapter what the robot can do rather than assuming, so a brand
+  that cannot pause a process is never shown a Pause button that would fail.
+  `commandSupported` refuses an unsupported command at the service too, because a
+  command can also arrive from an API caller or a scheduled job.
+
+  `uncontrollableFleetWarning` enforces Open-RMF's rule that a shared space may
+  contain at most one fleet it cannot control — a read-only cleaning fleet plus a
+  security robot with no interface is the exact pair the book says makes deadlock
+  avoidance nearly impossible.
+
+  Adds `brand` to the robot record so a row says whose protocol it answers.
+  Defaulted to `ounitech` because every existing row is one; a second brand makes
+  it a required choice rather than a fallback.
+
+## 3.82.0
+
+### Minor Changes
+
+- dbc439a: Cleaning robot: fleet endpoints, and the lift contract
+
+  Adds `robot-fleet.controller.ts` — live state, floors and areas, map image URLs,
+  the cleaning schedule, and one command endpoint covering full, area, spot and
+  return. Every handler loads the robot first and authorises the estate named on
+  the STORED record, never one named in the request, so a robot cannot be reached
+  by quoting its id; credentials are read server-side and never enter a response.
+
+  Adds `parseRobotCommand`, pure, so the command rules can be asserted without a
+  robot. Fields are refused on commands that do not use them rather than ignored —
+  silently dropping a spot polygon from an area command would clean the wrong
+  thing and report success.
+
+  Adds `getRobotById` and `setRobotSn` to the robot repository. `setRobotSn` only
+  ever fills a blank serial, so a later discovery cannot re-point a nickname at a
+  different machine.
+
+  Adds `lift-contract.util.ts` — the lift vocabulary, with field names and enum
+  values taken verbatim from Open-RMF's `rmf_lift_msgs`, plus an in-memory lift
+  simulator. No Modbus and no register numbers: the Inovance open-protocol
+  register map has not been supplied, so the driver sits behind an interface and
+  the queue and session logic can be built and tested against the simulator first.
+
+## 3.81.0
+
+### Minor Changes
+
+- fde0167: Cleaning robot: robot cloud connector, and stop projecting robot credentials
+
+  Adds the signed client for the cleaning-robot cloud (`robot-cloud.util.ts`,
+  `robot-cloud.service.ts`): request signing, the status vocabulary, the
+  pixel/metre transform and the area colour conversions, plus the nine
+  request/response endpoints. Credentials are passed in by the caller and are
+  never read from the environment, logged, or placed in a request body.
+
+  Also fixes a credential disclosure in the existing robot listing: `getRobots`
+  projected `appKey` and `appToken` — the pair that signs every command sent to
+  that estate's robots — into the response, so anyone holding `see-all-robots`
+  received them. They are no longer returned.
+
+  Fixes `POST /robots`, which had never worked: the service assigned an ObjectId
+  where the model's schema wanted a string, so every create ended in
+  `400 "createdBy" must be a string` and no robot could be registered at all.
+
+  Adds the server-side enforcement of the five robot permissions, which have
+  existed in the client catalogue but were never checked by the API. `"*"` allows
+  everything; an empty list allows everything only on a `type: "admin"` role (the
+  Seven365 staff role is seeded with `[]`, so enforcing it would refuse the
+  platform owner); a non-empty list is enforced exactly.
+
+  Adds `robotSn` to the robot record (optional, discovered from `get-robot-list`
+  when absent) and `robot-fleet.service.ts`, which bridges a stored robot to the
+  vendor cloud: live state, maps, map image URLs minted at use, and dispatch.
+
+  Adds a table of which application may set up and monitor which robot type, so
+  cleaning robots and security robots share one module while each app sees only
+  its own.
+
+  Adds an optional `type` ("cleaning" | "security") to the robot record with an
+  optional filter, so both device classes share one module and one collection
+  while each app lists only its own. Existing rows are untouched and an
+  unfiltered query behaves exactly as before.
+
 ## 3.80.0
 
 ### Minor Changes

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@7365admin1/core",
   "license": "MIT",
-  "version": "3.79.1-staging.350",
+  "version": "3.79.1-staging.351",
   "author": "7365admin1",
   "main": "dist/index.js",
   "module": "dist/index.mjs",