@decidio/sdk 0.2.0 → 0.2.2

package/README.md

@@ -144,6 +144,17 @@ evidence is yours, not ours. To also prove *who* issued it, pin your workspace's
 record verify panel — or simply read it off the `receipt` command's output, which prints your
 workspace's issuer DID from the authenticated response so you never have to hunt for it).
 
+**What VALID means — and what it does not.** A pinned `VALID` proves the receipt's bytes were
+sealed by your workspace's issuer and are unaltered since. It does **not** prove the approved
+action ran. Execution is confirmed *after* the seal, and a sealed record is immutable, so the
+receipt's own `authority.result` and `confirmation.status` are a snapshot taken at seal time — a
+receipt for an approved-but-never-executed action verifies `VALID`, correctly. The verifier now
+prints those fields under `as sealed`, plus a note saying exactly this, so the distinction is on
+screen rather than left to inference. The check is **cryptographic, not semantic**: it does not
+evaluate business rules, timestamp plausibility, revocation, or whether a later record superseded
+this one. For current execution status, ask the issuer (`npx @decidio/sdk receipt <decisionId>`
+reports the live evidence tier).
+
 One receipt proves itself. Pass several files and their **ordering** is verified too — in
 **seal order** (each receipt's `prevHash` links to its predecessor's `contentHash`), which is
 the order decisions were *sealed*, not the order of their displayed decision numbers (two
@@ -255,8 +266,21 @@ catch (e) { console.log(e.name); }   // DecidioSuspendedError — expected, not
 ```
 
 Run `node --env-file=.env agent.mjs`, then `node --env-file=.env submit.mjs` once, approve from
-another terminal, and the running worker executes it. Now kill the worker, restart it, and
-approve: it still executes — and restarting created no second request. **If you can't declare the name at wrap time** (a dynamic
+another terminal, and the running worker executes it.
+
+To see recovery, the approval has to be waiting while nothing is running — so submit a **second**
+request with the worker stopped:
+
+1. Stop the worker (Ctrl-C).
+2. `node --env-file=.env submit.mjs` again — it parks; nothing is running to pick it up.
+3. Approve it from the other terminal. It stays parked, approved and unexecuted.
+4. Start the worker again: it executes that request exactly once, and restarting created no
+   duplicate.
+
+Step 2 is the one that is easy to skip: by the time you restart, the first request has already
+executed, so without a second submission there is nothing left to approve.
+
+**If you can't declare the name at wrap time** (a dynamic
 `describe`), register the raw function explicitly at startup instead —
 `guard.register("payInvoice", payInvoiceRaw)` — before calling `guard.worker()`. Without one of
 those two, a cold worker has an empty registry and reports `no_handler` (the parked action is
@@ -421,7 +445,7 @@ for engines you don't. Each adapter's shipped `.d.ts` header documents its wirin
 - `doctor` — config, connectivity, and what your current token can do
 - `approvals [--mine] [--json]` / `approvals approve|reject <id> [reason]` — the human side, from your terminal (the list is workspace-wide; `--mine` narrows it to this directory's agent)
 - `receipt <id>` — download a sealed decision's Authority Receipt to a `.json` file
-- `verify [--issuer <did>] <file>...` — verify receipts offline (the canonical verifier; the standalone `@decidio/verify` package is the same implementation, for auditors who want zero Decidio dependency — the sdk's embedded copy is pinned to the previous release, so message wording may trail it one version; verdicts and semantics are conformance-locked identical). Unknown flags are refused, never ignored. Fully offline AND fully decoupled: it touches no network and reads no `.env` — a receipt verifies identically from an empty directory.
+- `verify [--issuer <did>] <file>...` — verify receipts offline (the canonical verifier; the standalone `@decidio/verify` package is the same implementation, for auditors who want zero Decidio dependency — the sdk depends on the verifier released alongside it, at the same version). Unknown flags are refused, never ignored. Fully offline AND fully decoupled: it touches no network and reads no `.env` — a receipt verifies identically from an empty directory.
 - `tokens list [--mine]` / `tokens revoke <jti>` — see and kill agent tokens (values are never re-shown; the jti is the revocation handle). Each row carries its status — `active`, `expired`, or `REVOKED <date>` — so the list confirms the revocations it performs; re-revoking is an honest no-op (exit 1). The list is workspace-wide (a shared workspace shows every member's agents); `--mine` narrows to this directory's agent
 - `quickstart cleanup` — revoke the tour's token and delete its local credentials. What stays, honestly: sealed records (permanent by design) and the agent's registration row (inert without key or token; server-side deregistration is on the roadmap)
 - `dev [--target URL]` — local relay for the resume webhook (operator setups)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@decidio/sdk",
-  "version": "0.2.0",
+  "version": "0.2.2",
   "description": "One-line approval gate for AI-agent actions. Wrap a risky tool call with guard.protect(); Decidio's policy engine decides proceed | route | block, a human approves routed actions, and every outcome is sealed as a verifiable Authority Receipt.",
   "license": "Apache-2.0",
   "type": "module",
@@ -33,7 +33,8 @@
     "./openai": {
       "types": "./dist/adapters/openai.d.ts",
       "default": "./dist/adapters/openai.js"
-    }
+    },
+    "./package.json": "./package.json"
   },
   "files": [
     "dist",
@@ -86,7 +87,7 @@
     "prepublishOnly": "npm run typecheck && npm run build"
   },
   "dependencies": {
-    "@decidio/verify": "0.1.12"
+    "@decidio/verify": "0.2.2"
   },
   "author": "OmniTwin Technologies Inc.",
   "bugs": {