v1.4.1

• The package no longer ships Python bytecode from the bundled client.
• The docs and the bundled clients use neutral example names. No command, field or error code changed.

v1.4.0

• Device API format 11: the error code system_version_unverified and the error fields version and reason are gone, and a system's writes state in GET /v1/devices/{deviceId} is replaced by blockedActions (the actions this device's client cannot run yet; each answers device_outdated until the client updates). An action whose system runs a program version Deepdock has not yet approved for it answers the new 409 version_not_covered (CLI exit 2): nothing ran, retrying gets the same answer, and it works once Deepdock approves that version or the customer runs an approved one. The bundled TypeScript and Python clients, the skill's error reference and the device types follow. This needs the API from the Deepdock release that carries these changes.
• deepdock devices and deepdock incidents list read the organisation's lists as { "data": [...], "nextCursor": ... }, the form /v1 already uses (was { "data": { "items": [...], "nextCursor": ... } }). They need the API from the next Deepdock release; an older API answers the old form, which this version does not read.
• The CLI follows the API's British spelling and its renamed code: GET /partner/organisations (was /partner/orgs), the error code organisation_required (was organization_required) and cli_outdated (was client_outdated, still exit 4). The bundled device types and the skill's error reference include them. These need the API from the next Deepdock release.
• The command group org is now orgs (deepdock orgs list, deepdock orgs select); the old name is gone, with no alias.
• A device is named <deviceId> in every usage string, help text, the README and the bundled skill (devices rename|release|systems <deviceId>, actions list <deviceId> <system>).
• The README and the bundled skill advise reusing one HTTP connection for calls (keep-alive), because a fresh connection can hit a cold start.
• The docs, the bundled skill and the device API pin say "pair" for taking a device into your organisation (was "claim"); the rate_limited and pairing_code_invalid texts follow, and requestId is described as present on every error body. Field names and error codes are unchanged (claimedAt stays).

v1.2.0

• Every /v1 answer uses one data envelope. A list (a many action read, GET /v1/devices) answers { "data": [...], "nextCursor": ... } (was { "data": { "items": [...], "nextCursor": ... } }); nextCursor sits beside data and appears only on a list that pages. A single-record read (cardinality: one) answers { "data": { ...record } } and a record that is not found answers 404 not_found. Writes and error bodies are unchanged.
• Every refused action input (type, length, enum, bounds, a missing or unknown field, a bad limit or cursor) answers 422 invalid_input with error.fields; 400 invalid_request is for a malformed request only.
• The bundled TypeScript and Python clients read the new shape (Page.items keeps its name and holds data) and gain readOne / read_one for a single-record read. The skill and its references show the new answers.
• The bundled TypeScript and Python clients gain download for a file action (file: true in the action index): it posts the inputs like a read and returns the bytes, the content type and the file name from Content-Disposition (filename* first). A body shorter than its Content-Length throws DeepdockTransportError; a refusal is a DeepdockError as for any action, and 503 target_busy is retried the same way. The skill describes file actions in calling-actions.md.

v1.1.2

• The bundled TypeScript and Python clients wait 35 seconds per attempt (was 30): a call can wait up to 10 seconds for the device's slot and then up to 20 seconds on the device. They also retry 503 target_busy up to three attempts (maxAttempts / max_attempts), waiting the Retry-After seconds (at most 15, one second without the header) and sending the same request, so a write keeps its idempotency key. DeepdockError carries the header as retryAfter / retry_after.

v1.1.1

• A new error code, partner_deactivated (403): Deepdock has deactivated the organisation, so none of its keys work and its devices are disconnected until Deepdock reactivates it. The CLI exits with 2 on it, as on partner_not_approved. The bundled device types and the skill's error reference include it.

v1.1.0

• Each system in a device's systems answer carries connectors: the connectors the device runs for that system, each with a name and a kind (database or http). The bundled device types and the client's DeviceSystem include it.

v1.0.29

• A paused action's reason can also read credentials_rejected (the program no longer accepts the stored sign-in) or certificate_changed (the program's server certificate changed). Both are fixed by the customer choosing "Anmeldung erneuern" in the Deepdock client, and the action resumes by itself. Calls answer action_paused meanwhile, as for any pause. The bundled device types and the skill's concepts list include them.

v1.0.28

• The device API's Error.code list no longer names organization_required, forbidden, conflict and already_member: only the dashboard tree (/partner) answers them, never /v1. The CLI still meets them on its own /partner calls and keeps their exit codes (organization_required 1, the other three 2), now from a list of its own. Nothing changes for a script that reads --json or the exit code.

v1.0.27

• An update is called with PATCH again; a read and a create stay POST. All three take a flat JSON body and nothing in the URL. The method must be the action's own: any other answers 405 invalid_request with Allow naming the one method (POST or PATCH), so a POST to an update is refused and does nothing. A query string on an action path is still 400 invalid_request. A write still needs an Idempotency-Key; a read ignores it.
• Each entry of the action index has a method (POST or PATCH) beside its operation (read, create or update).
• The bundled clients' write takes the action's operation after the action name (write(deviceId, system, action, 'create' | 'update', key, input)) and sends POST for a create and PATCH for an update; PendingWrite carries it as operation. Reads are unchanged. Idempotency handling is unchanged.
• The skill's references describe the contract.

v1.0.26

• Every action is called with POST /v1/devices/{deviceId}/systems/{system}/actions/{action} and its inputs in a flat JSON body, reads and updates included. There is no GET read and no PATCH update any more: any other method answers 405 invalid_request with Allow: POST, and a query string on an action path answers 400 invalid_request ("inputs go in the JSON body, not in the URL"), so no value reaches a URL, a request log or a proxy. A read takes limit (a JSON integer) and cursor (a string) in the same body; a write still needs an Idempotency-Key, a read ignores it. Values are typed as given: an integer input is a JSON number, and "1001" is refused where it is declared as one.
• The action index keeps its route, but each entry's method is replaced by operation (read, create or update). actions list derives its read/write column from it.
• The bundled TypeScript and Python clients send reads as POST with a JSON body, including limit and cursor. write always sends POST, so its method parameter (and PendingWrite.method) is gone; input values are typed (string | number | boolean) instead of text only. Idempotency handling is unchanged.
• The skill's references describe the new contract.