@thinger-io/cli-core 0.4.1 → 0.4.2

package/CHANGELOG.md

@@ -1,5 +1,14 @@
 # Changelog
 
+## [0.4.2] - 2026-10-17
+
+### Fixed
+
+- The dashboard SDK ships with Thinger 7.4, not 7.5: the platform guides
+  mark as "since Thinger 7.4" what older servers lack, and the catalog
+  notes name Thinger 7.4 instead of develop builds (7.3.4-…). The SDK's
+  own base server keeps coming from its `compat.json`.
+
 ## [0.4.1] - 2026-10-16
 
 ### Fixed

package/docs/thinger-concepts.md

@@ -1,8 +1,8 @@
 # Thinger concepts
 
 How a Thinger.io account is organized, for agents that create resources, dashboards or
-alarms. It describes Thinger 7.5: what needs a later version says "since Thinger X", and what
-older servers lack says "since Thinger 7.5" (a server's version: `GET /v1/server/version`).
+alarms. It describes Thinger 7.4: what needs a later version says "since Thinger X", and what
+older servers lack says "since Thinger 7.4" (a server's version: `GET /v1/server/version`).
 `GET /v1/server/events` lists the live events; the OpenAPI document lists every route. Related
 guides: product code (document `product-code`) and server administration (document
 `server-admin`). The dashboard SDK is the npm package `@thinger-io/dashboard-sdk`, documented in
@@ -37,7 +37,7 @@ A **project** groups resources of the account so they can be shared and browsed
   of the project's devices, and asking for another device is refused. It needs the bucket to
   carry a `device` tag (product buckets do); a bucket without it is not filtered. A project with
   no devices reads such a bucket as empty. It is **on by default for new projects** since Thinger
-  7.5 (send
+  7.4 (send
   `config: {limit_bucket_access: false}` to opt out); for older projects, turn it on with
   `PUT /v1/users/<u>/projects/<p>` and `{config: {limit_bucket_access: true}}`, especially before
   sharing a project with members or public tokens.
@@ -159,7 +159,7 @@ Records get a `device` field; the bucket is created on the first write.
 
 **Field names**: `ts` is the record time. In MongoDB buckets `tags` and `_id` are reserved (they
 hold the record's tags and id): a record with a field of that name is refused, so rename it
-(`tag_count`, …). Since Thinger 7.5 the refusal names the field.
+(`tag_count`, …). Since Thinger 7.4 the refusal names the field.
 
 **Reading** (`GET /v2/users/<u>/buckets/<b>/data`, or the SDK's `buckets.read`): records come as
 `{ ts, ...fields }`, newest first. Query: `min_ts` / `max_ts` (ms), `items` (default 50, **at most
@@ -218,7 +218,7 @@ when null matters.
 
 ## Geofences
 
-Since Thinger 7.5. The server checks geofences natively: do not compute zone entries and exits in your own code. A
+Since Thinger 7.4. The server checks geofences natively: do not compute zone entries and exits in your own code. A
 property `geofences` on the device, or inherited from its type, group or product, holds a GeoJSON
 `FeatureCollection`. Each `Feature` is a `Polygon`, or a `Point` with `properties.radius` in
 meters. **Coordinates are `[lon, lat]`**, as in GeoJSON (the `location` property is `{lat, lon}`).
@@ -322,7 +322,7 @@ of the device.
   list, a field of the listed documents (nested ones with dots) filters by exact value (numbers
   as numbers, `true` / `false` also as booleans: `?connection.active=true` for connected devices),
   and a repeated parameter matches any of its values (nested fields and booleans since Thinger
-  7.5). Instance `state` values:
+  7.4). Instance `state` values:
   0 none, 1 activated, 2 acknowledged, 3 latched, 4 shelved, 5 cleared. `severity` values:
   0 none, 1 low, 2 medium, 3 high, 4 critical.
 - Notifications on activation, normalization and reminders call **endpoints**:
@@ -330,7 +330,7 @@ of the device.
   (`name`, `severity`, `state`, `origin.id` = device, `evaluation.last_values`, `notification.type`…).
 - Test a rule, a single source or a notification before saving with
   `POST …/alarms/rules/<r>/test-rule`, `/test-source` and `/test-notification`. `test-rule` and
-  `test-source` work before the rule exists (any new id; since Thinger 7.5); `test-source` takes a `check_interval`
+  `test-source` work before the rule exists (any new id; since Thinger 7.4); `test-source` takes a `check_interval`
   for bucket sources without aggregation (default: the rule's, or 1 minute).
 
 ## Endpoints, storages, tokens

package/docs/thinger-product-code.md

@@ -2,14 +2,14 @@
 
 JavaScript that a product's profile calls to compute, transform or route data for its devices:
 resource values (including simulated devices), payload transforms, the device a product call is
-for. Platform concepts: the document `concepts`. It describes Thinger 7.5; what needs a later
+for. Platform concepts: the document `concepts`. It describes Thinger 7.4; what needs a later
 version says "since Thinger X" (a server's version: `GET /v1/server/version`).
 
 ## Where it lives
 
 `PUT /v1/users/{user}/products/{product}/profile/code` with
 `{ "code": "<JavaScript>", "storage": "" }`, or `{ "storage": "<storage id>" }` to load
-`<storage>/index.js` from a file storage (with its `node_modules`). Since Thinger 7.5, add
+`<storage>/index.js` from a file storage (with its `node_modules`). Since Thinger 7.4, add
 `"path": "<folder>"` to
 load `<storage>/<folder>/index.js` (and that folder's `node_modules`) instead: one storage can then
 hold a whole application, e.g. the dashboard in `app/` and each product's code in

package/docs/thinger-server-admin.md

@@ -3,7 +3,7 @@
 For agents acting as a server **admin**: host settings, domains and brands, user accounts,
 OAuth clients, identity providers and proxies. Every route here needs an admin session or
 token. Read the OpenAPI document for each body; this guide covers what the schemas cannot say:
-order of steps, side effects and risks. It describes Thinger 7.5; what needs a later version says
+order of steps, side effects and risks. It describes Thinger 7.4; what needs a later version says
 "since Thinger X" (a server's version: `GET /v1/server/version`).
 
 Before changing anything, read the current value and tell the user what will change. Several
@@ -38,7 +38,7 @@ self-hosted server raise `accounts.limits.<collection>.max_count` (`projects`,
 brands limits are not shown by `GET settings`.
 
 On cloud instances the plan owns `accounts.limits.{accounts,brands,domains,members}`, `database`,
-`plugins`, `rate_limiter` and `http_server.hosts`: since Thinger 7.5, writing them returns 403.
+`plugins`, `rate_limiter` and `http_server.hosts`: since Thinger 7.4, writing them returns 403.
 To raise them, the customer changes the plan.
 
 ## Custom domain with its own brand

package/lib/mcp/catalog.js

@@ -103,7 +103,7 @@ export const CATALOG = {
             clone: 'Device_Clone',
             projects: 'Device_UpdateProjects',
         },
-        notes: '`type` defaults to Generic (IOTMP). Generic and MQTT devices authenticate with `credentials`: when creating one without them, credentials are generated and returned once (the server stores them hashed). HTTP devices send data through {tool:device_data_send}; assign a product with update {product} ("" unassigns). Virtual devices have no hardware: every resource comes from their product\'s API (product code can compute it), and they need a `location` property ({lat, lon}) to appear on maps, or they are placed by their IP. Native geofences (7.3.4-144 and later): a `geofences` property on the device, or inherited from its asset type, group or product, holds a GeoJSON FeatureCollection ([lon, lat]; Polygon, or Point with properties.radius in meters; properties.onEnter / onExit name an endpoint or ""). Every change of the device `location` emits device_geofence_event (with geofence_id, geofence_properties, product, asset_type, asset_group): store it with a product profile bucket or flow whose source is that event. See the Geofences section of {tool:doc_read} id "concepts". A new Virtual device shows disconnected in the create answer and connects a moment later.',
+        notes: '`type` defaults to Generic (IOTMP). Generic and MQTT devices authenticate with `credentials`: when creating one without them, credentials are generated and returned once (the server stores them hashed). HTTP devices send data through {tool:device_data_send}; assign a product with update {product} ("" unassigns). Virtual devices have no hardware: every resource comes from their product\'s API (product code can compute it), and they need a `location` property ({lat, lon}) to appear on maps, or they are placed by their IP. Native geofences (Thinger 7.4 and later): a `geofences` property on the device, or inherited from its asset type, group or product, holds a GeoJSON FeatureCollection ([lon, lat]; Polygon, or Point with properties.radius in meters; properties.onEnter / onExit name an endpoint or ""). Every change of the device `location` emits device_geofence_event (with geofence_id, geofence_properties, product, asset_type, asset_group): store it with a product profile bucket or flow whose source is that event. See the Geofences section of {tool:doc_read} id "concepts". A new Virtual device shows disconnected in the create answer and connects a moment later.',
         actions: {
             stats: {
                 op: 'Device_ReadStatistics',
@@ -268,7 +268,7 @@ export const CATALOG = {
             delete: 'Project_Delete',
             clone: 'Project_Clone',
         },
-        notes: 'The project\'s own id is the short one ("plant_a"); resources name it "<owner>@<project>" ("alice@plant_a"). They join it when created with projects in the body, or through their own update: {projects: ["alice@plant_a"]}; the list replaces the previous one. List the resources of a project with filter {project: "<project>"}. Share it with other accounts through project_member (and project_role for their permissions). New projects limit bucket data to their own devices (config.limit_bucket_access, default true on 7.3.4-135 and later): reads and tag lists of a bucket through the project return only its devices\' records, so such buckets need a device tag. Turn it on for older projects with update {config: {limit_bucket_access: true}} before sharing them with members or project-scoped tokens.',
+        notes: 'The project\'s own id is the short one ("plant_a"); resources name it "<owner>@<project>" ("alice@plant_a"). They join it when created with projects in the body, or through their own update: {projects: ["alice@plant_a"]}; the list replaces the previous one. List the resources of a project with filter {project: "<project>"}. Share it with other accounts through project_member (and project_role for their permissions). New projects limit bucket data to their own devices (config.limit_bucket_access, default true for new projects since Thinger 7.4): reads and tag lists of a bucket through the project return only its devices\' records, so such buckets need a device tag. Turn it on for older projects with update {config: {limit_bucket_access: true}} before sharing them with members or project-scoped tokens.',
     },
     token: {
         description: 'Access tokens of the account, with their permission tree.',
@@ -284,7 +284,7 @@ export const CATALOG = {
             clone: 'Token_Clone',
             projects: 'Token_UpdateProjects',
         },
-        notes: 'Permissions: `allow` (and optional `deny`) is {ResourceType: {id or "*": [actions] or "*"}}, e.g. {"Device": {"*": "*"}} or {"Device": {"sensor_1": ["ReadDeviceStatus", "AccessDeviceResources"]}}; {"*": {"*": "*"}} is full access. {tool:resource_describe} of any type lists its ResourceType and actions under `permissions`. The JWT (`access_token`) is returned by create and get, never by list. `expire` (unix ms) makes a token expire: it is signed into the JWT, so it cannot be changed on update (delete the token and create it again), and the server deletes the token afterwards. Without it a token does not expire: delete it to revoke it. Servers before 7.3.4-98 ignore `expire`.',
+        notes: 'Permissions: `allow` (and optional `deny`) is {ResourceType: {id or "*": [actions] or "*"}}, e.g. {"Device": {"*": "*"}} or {"Device": {"sensor_1": ["ReadDeviceStatus", "AccessDeviceResources"]}}; {"*": {"*": "*"}} is full access. {tool:resource_describe} of any type lists its ResourceType and actions under `permissions`. The JWT (`access_token`) is returned by create and get, never by list. `expire` (unix ms) makes a token expire: it is signed into the JWT, so it cannot be changed on update (delete the token and create it again), and the server deletes the token afterwards. Without it a token does not expire: delete it to revoke it. Servers before Thinger 7.4 ignore `expire`.',
     },
     alarm_rule: {
         description: 'Alarm rules: conditions on device or bucket data that raise alarm instances.',

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@thinger-io/cli-core",
-    "version": "0.4.1",
+    "version": "0.4.2",
     "description": "Shared core of the Thinger.io CLIs and their MCP servers: API client, auth, profiles, generic commands and MCP tools",
     "type": "module",
     "exports": {