@deepdockai/cli 1.0.13 → 1.0.15

package/CHANGELOG.md

@@ -1,5 +1,13 @@
 # Changelog
 
+## 1.0.15
+
+- `device_offline` also covers a call cut off by a Deepdock restart or deploy (retry a write with the same key). `temporarily_unavailable` is also sent, with `Retry-After: 5`, when Deepdock cannot reach its database. The skill's error reference, idempotency and concepts pages say so.
+
+## 1.0.14
+
+- A system's `access` can be `password_missing`: the database account exists, but its stored password is not on the PC. Like `missing`, every action of the system is refused with `access_missing` (its message names the password) and the customer repeats "Erneut einrichten" in the Deepdock client. The agent skill's TypeScript client types it, and its concepts reference explains it.
+
 ## 1.0.13
 
 - A device carries `lastKnownAt`: the time of its last report while it is not connected, `null` while it is connected. Every system of a device carries `lockedActions`: the actions the device reports locked because its database account lacks a right they need, under the spec set it runs now, or `null` when there is no verdict or the verdict is for an older spec set. Both are in the device list and, for `lockedActions`, in `GET /v1/devices/{deviceId}/systems`. The agent skill's TypeScript client types them, and its concepts reference explains them.

package/dist/deepdock.js

@@ -11428,7 +11428,7 @@ import { spawn } from "node:child_process";
 import { homedir, hostname } from "node:os";
 
 // src/version.ts
-var VERSION = "1.0.13";
+var VERSION = "1.0.15";
 
 // src/runtime.ts
 var DEFAULT_BASE_URL = "https://api.deepdock.ai";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@deepdockai/cli",
-  "version": "1.0.13",
+  "version": "1.0.15",
   "description": "Deepdock partner CLI: pair devices, see systems and actions, create the API key your code runs them with.",
   "type": "module",
   "license": "MIT",

package/skill/references/clients/deepdock.ts

@@ -51,7 +51,7 @@ export type WriteMethod = 'POST' | 'PATCH'
 
 export type SystemStatus = 'running' | 'stopped' | 'missing' | 'unknown'
 /** The database access the device last reported; `null` while none is known. */
-export type SystemAccess = 'ok' | 'outdated' | 'missing' | 'not_set_up' | null
+export type SystemAccess = 'ok' | 'outdated' | 'missing' | 'password_missing' | 'not_set_up' | null
 
 /**
  * Whether writes on the system run. `unverified` makes writes answer system_version_unverified:

package/skill/references/concepts.md

@@ -46,14 +46,14 @@ has a display `label` (may be `null`), a `version` the device reported (may be a
 | Field | Value | Meaning | What to do |
 |---|---|---|---|
 | device `status` | `connected` | the device is online and can run actions | normal |
-| device `status` | `offline` | the device is not connected right now (PC off, no network) | calls answer `device_offline`; retry later, show "offline" |
+| device `status` | `offline` | the device is not connected right now (PC off, no network) | calls answer `device_offline` (also while `connected`, if a Deepdock restart cuts a call off); retry later, show "offline" |
 | device `status` | `inactive` | not connected for 7 days; still paired | as offline; check with the site whether the PC still exists |
 | device `lastKnownAt` | ISO time or `null` | the time of the device's last report while it is not connected. `null` while it is connected | show the last known state with this time; it may be out of date |
 | system `status` | `running` | the customer's program is running on the device | normal |
 | system `status` | `stopped` | the program is installed but not running | calls answer `system_unavailable`; the site starts the program |
 | system `status` | `missing` | the program was not found where the device expects it | calls answer `system_unavailable`; contact the site and Deepdock |
 | system `status` | `unknown` | the device could not tell whether the program runs (its probe failed or is unavailable on that PC) | do not read it as stopped; the device decides when a call arrives |
-| system `access` | `ok`, `outdated`, `missing`, `not_set_up`, or `null` | the database access the device last reported (`null`: none known yet) | `outdated` refuses the actions that need the missing right with `access_outdated`, `missing` refuses every action with `access_missing`; the customer repeats "Erneut einrichten" in the Deepdock client, the incident closes by itself once `access` is `ok`, nothing to resume |
+| system `access` | `ok`, `outdated`, `missing`, `password_missing`, `not_set_up`, or `null` | the database access the device last reported (`null`: none known yet) | `outdated` refuses the actions that need the missing right with `access_outdated`, `missing` (the account cannot log in) and `password_missing` (the account exists but its stored password is not on the PC) refuse every action with `access_missing`; the customer repeats "Erneut einrichten" in the Deepdock client, the incident closes by itself once `access` is `ok`, nothing to resume |
 | system `accessLastCheckedAt` | ISO time or `null` | set when `access` is the last known value because the device could not read it (its database stopped or unreachable): when it last read it. `null` when the latest report read it | show the access as last known, with this time; nothing to do until the device reads it again |
 | system `lockedActions` | list of action names or `null` | the actions the device reports locked because its database account lacks a right they need, under the spec set it runs now. `null`: no verdict yet, or the verdict is for an older spec set | do not offer a locked action as available; it answers `access_outdated` until the customer repeats "Erneut einrichten" |
 | action state | `active` | the action can be called | normal |

package/skill/references/errors.md

@@ -54,14 +54,14 @@ dashboard-only.
 
 | Code | Status | Meaning | Retry | Show |
 |---|---|---|---|---|
-| `device_offline` | 503 | the device is not connected, is shutting down, or did not answer within 20 s. **A write may still have landed** | yes, with backoff (seconds to minutes); a write only with the same key | "the customer PC is offline; we will retry" |
+| `device_offline` | 503 | the device is not connected, is shutting down, did not answer within 20 s, or the call was cut off inside Deepdock by a restart or deploy. **A write may still have landed** | yes, with backoff (seconds to minutes); a write only with the same key | "the customer PC is offline; we will retry" |
 | `device_syncing` | 503 | the device has not reported its Deepdock client yet (just paired, or its report did not come through); Deepdock asks it again. Nothing was written | yes, after `Retry-After` (5 s); a write with the same key | "the customer PC is connecting; retrying" |
 | `device_outdated` | 409 | the device's Deepdock client is too old for this call. It updates itself when a newer version is released for your organisation, once nobody is signed in on the PC. Nothing was written | after the update (`outdated` on `GET /v1/devices/{deviceId}` turns `false`); retrying before it gets the same answer. A write keeps its key | "the Deepdock client on the customer PC needs an update" |
 | `system_version_unverified` | 409 | a write on a system whose vendor version Deepdock has not verified yet. Nothing was sent to the device; reads still work. `error.version` is the version the system last reported and `error.reason` is `unverified_version`, or `unparseable` when that version is not dotted digits | `unverified_version`: after Deepdock has verified that version (`writes` on the system in `GET /v1/devices/{deviceId}` turns `verified`); retrying before it gets the same answer. `unparseable`: retrying does not help, contact Deepdock; only a different reported version changes it. A write keeps its key | "the customer's system was updated to a version Deepdock has not yet verified; changes will work once it has" |
 | `action_paused` | 503 | the action is paused on the device (`GET .../systems` shows `reason`); only Deepdock resumes it | later, when `GET .../systems` shows it active; do not loop | "this feature is paused while Deepdock checks the customer system" |
 | `system_unavailable` | 503 | the customer's program is stopped or missing on the device | later; often resolves when the customer restarts the program | "the customer's software is not running" |
 | `target_busy` | 503 | the customer's system is busy or unreachable | yes, with backoff | "the customer's system is busy; retrying" |
-| `temporarily_unavailable` | 503 | Deepdock could not check the key | yes, with backoff | "temporary problem; retrying" |
+| `temporarily_unavailable` | 503 | Deepdock could not check the key or reach its own database (sent with `Retry-After: 5`) | yes, with backoff | "temporary problem; retrying" |
 
 ## Write outcomes
 

package/skill/references/idempotency.md

@@ -38,7 +38,7 @@ example to avoid double-logging.
 
 ### `503 device_offline` on a write
 
-The device did not answer within 20 seconds, or was not connected. **The write may still have
+The device did not answer within 20 seconds, was not connected, or the call was cut off inside Deepdock by a restart or deploy. **The write may still have
 landed.** Retry with the **same key**: you get either the stored result (replayed) or a fresh run,
 never two writes. Back off between retries (seconds, then minutes); a device can be off for hours,
 so the retry runs from the persisted pending write in a job or queue, not inside the request that