docs: SDK code samples on every API reference page, checked as code

docs/adr/ADR-0014-Public-Sandbox-And-Docs-Playground.md

@@ -1,6 +1,6 @@
 # ADR-0014: Public sandbox and docs playground
 
-**Status:** Proposed 2026-10-01, waiting for the operator's decision and the open questions below.
+**Status:** Accepted by the operator on 2026-10-01 (PR #103 merged), with the proposed answers to the three open questions. Not built yet; see the order of work.
 
 **Date:** Proposed 2026-10-01.
 

docs/site/build-book/06-connect-your-systems.mdx

@@ -152,8 +152,9 @@ external connector. The literal procedure, with what to expect and what to do at
 
 ### Status
 
-Registration through maker checker is live in production. Releasing to a registered endpoint is built and tested, and
-not yet checked against a live endpoint in production. `verifyParmanaRelease` and `verify_parmana_release` are in the
+Registration through maker checker, and releasing approved requests to the registered endpoint, are live in
+production, checked end to end on 2026-10-01 (`docs/CLAIMS.md` 2.50, `examples/live-checks/external-connector`). An
+approved request took 24 to 32 seconds there (G-84): give agents a timeout of at least 120 seconds. `verifyParmanaRelease` and `verify_parmana_release` are in the
 repository and not yet published. What the endpoint answers is its claim, not proof that it acted
 (`docs/VERIFICATION-GAPS.md` G-82).
 

docs/site/build-book/10-security-model-and-limits.mdx

@@ -52,6 +52,7 @@ The open items that matter most when you build with Parmana:
 | G-51 | Facts the agent declares (such as `refundEligible`, `fraudCheckPassed`) are not checked against another system. | Use them only to refuse. The signed approval authorizes.                                                                     |
 | G-82 | An external endpoint's answer is its claim, not proof that it acted.                                            | Keep the endpoint's own records; reconcile them against Trust Records.                                                       |
 | G-83 | The external release connects to the first checked address only.                                                | If that address is down, the release fails as an unknown outcome instead of trying the next one. Availability, not security. |
+| G-84 | An approved request takes 24 to 32 seconds in production, past the SDKs' default 30 second timeout.             | Set a 120 second timeout; after a timeout, read the record before sending anything new.                                      |
 
 Also scoped, not absent:
 
@@ -63,7 +64,8 @@ Also scoped, not absent:
   read.
 - **Approval notifications are best effort.** One attempt, no retry; the Refusal Records are the complete list.
 - **Python verifies Ed25519 only.** A record's ML-DSA-65 signatures are checked by the TypeScript verifier.
-- **Releasing to an external endpoint is not yet checked against a live endpoint in production** (ADR-0013 step 6).
+- **Releasing to an external endpoint was checked live once**, on 2026-10-01, with an endpoint that acts on nothing
+  (`docs/CLAIMS.md` 2.50).
 
 ## Reporting a vulnerability
 

docs/site/changelog.mdx

@@ -283,7 +283,7 @@ or equal to 4096`, because KMS refuses a raw Ed25519 message over 4096 bytes. A
   `development`. The startup log gains `signingReadinessConfigured`. This mitigates the ordering gap G-52
   and does not close it.
 - New page [AWS KMS signing](/deployment/aws-kms-signing): create the key, the Vercel role and policy, the environment, and how to verify. Adds `npm run verify:kms` (`scripts/verify-kms-signing.ts`), which signs test data through the repository's own `KmsSigner` on both sides of the 4096 byte KMS limit and requires KMS to refuse a raw message over it. Verified on 2026-09-20 against the real key with a limited IAM user, and end to end with the server signing a full Trust Record under KMS. Pages that said KMS was roadmap or not built (Cryptography, FAQ, Local deployment, Deploy patterns) are corrected. Azure Key Vault, Google Cloud KMS and HSM remain unimplemented.
-- An approved action whose connector is not configured now returns `503` with code `CONNECTOR_NOT_REGISTERED` and the message "No connector is registered for capability '<action>' on this deployment. Nothing was executed." Before, it was a bare `500` with no code, and only the server log named the cause. Both SDKs already expose the code (`serverCode` in TypeScript, `server_code` in Python 1.1.6).
+- An approved action whose connector is not configured now returns `503` with code `CONNECTOR_NOT_REGISTERED` and the message `No connector is registered for capability '<action>' on this deployment. Nothing was executed.` Before, it was a bare `500` with no code, and only the server log named the cause. Both SDKs already expose the code (`serverCode` in TypeScript, `server_code` in Python 1.1.6).
 - Deployment artifacts found by following the production runbook on a fresh clone. The `Dockerfile` copied a package that no longer exists (`packages/receipt`) and skipped real workspaces, and the image did not contain `docs/site/parmana-handbook.pdf`, which the API needs at startup, so a container built from it could not have started. `scripts/apply-all-migrations.sql` was missing 7 of 30 migrations (including `execution_audit_events` and `policies`) and carried outdated text for others. It is now generated from `supabase/migrations/` with `npm run generate:migration-bundle`, and a test fails when it drifts. The runbook and the policy governance guide now say that proposing a policy change also needs a `USER` (human) key, because a service key is refused with `403 NON_HUMAN_CALLER_DENIED`.
 - TypeScript SDK 1.1.6 and Python SDK 1.1.6 (both published on 2026-09-20, so both SDKs now share one version). TypeScript: the client builds a default `HttpTransport` from its own configuration when `transport` is omitted, so `timeout`, `retryPolicy` and `apiKey` apply with no extra wiring (1.1.5 and earlier threw `Transport is required.`), and `userAgent` is now sent as the `User-Agent` header. Python: `InternalServerError` now carries the server's code on `server_code`, so you can tell `SIGNING_UNAVAILABLE` from `EXECUTION_RECORD_INCOMPLETE`. The Python client docstring now lists 429 among retried statuses.
 - TypeScript SDK 1.1.3 (published to npm on 2026-09-20): `InternalServerError` now carries the

docs/site/concepts/human-approval.mdx

@@ -192,10 +192,13 @@ server trusts the public key. Add one through maker checker, with no deploy:
 
 <Steps>
   <Step title="The approver creates a key pair on their own machine">
-    ```bash npx tsx scripts/generate-approver-key.ts \ --approver-id
-    manager-priya --key-id manager-priya-key-1 --out-dir ~/.parmana ``` They
-    send the public key file, `manager-priya__manager-priya-key-1.public.pem`,
-    to a proposer.
+
+    ```bash
+    npx tsx scripts/generate-approver-key.ts --approver-id manager-priya --key-id manager-priya-key-1 --out-dir ~/.parmana
+    ```
+
+    They send the public key file, `manager-priya__manager-priya-key-1.public.pem`, to a proposer.
+
   </Step>
   <Step title="One person proposes trusting it">
     `POST /approval-issuers/changes` with `action: "add"`, the ids, the public
@@ -211,13 +214,14 @@ The full walkthrough, with rotation, revocation and errors, is
 [Manage approvers](/guides/manage-approvers).
 
 Approvers can also be listed in the server code, `TRUSTED_APPROVAL_ISSUERS` in
-`packages/api/src/bootstrap/createApprovalIssuerRegistry.ts`. Those change only with a pull
-request and a deploy. The code list is checked first.
+`packages/api/src/bootstrap/codeApprovalIssuers.ts`. Those change only with a pull request and a
+deploy. The code list is checked first.
 
 <Info>
-  The hosted deployment trusts one approver in code, added on 2026-09-28.
-  Approver keys are always Ed25519, whatever signing algorithm the server itself
-  uses.
+  The hosted deployment's code list holds one key, `manager-charak1987-key-1`,
+  revoked on 2026-09-30; its current approver key was added through maker
+  checker. Approver keys are always Ed25519, whatever signing algorithm the
+  server itself uses.
 </Info>
 
 ## Add an approval to any action

docs/site/llms-full.txt

@@ -1588,10 +1588,13 @@ server trusts the public key. Add one through maker checker, with no deploy:
 
 <Steps>
   <Step title="The approver creates a key pair on their own machine">
-    ```bash npx tsx scripts/generate-approver-key.ts \ --approver-id
-    manager-priya --key-id manager-priya-key-1 --out-dir ~/.parmana ``` They
-    send the public key file, `manager-priya__manager-priya-key-1.public.pem`,
-    to a proposer.
+
+    ```bash
+    npx tsx scripts/generate-approver-key.ts --approver-id manager-priya --key-id manager-priya-key-1 --out-dir ~/.parmana
+    ```
+
+    They send the public key file, `manager-priya__manager-priya-key-1.public.pem`, to a proposer.
+
   </Step>
   <Step title="One person proposes trusting it">
     `POST /approval-issuers/changes` with `action: "add"`, the ids, the public
@@ -1607,13 +1610,14 @@ The full walkthrough, with rotation, revocation and errors, is
 [Manage approvers](/guides/manage-approvers).
 
 Approvers can also be listed in the server code, `TRUSTED_APPROVAL_ISSUERS` in
-`packages/api/src/bootstrap/createApprovalIssuerRegistry.ts`. Those change only with a pull
-request and a deploy. The code list is checked first.
+`packages/api/src/bootstrap/codeApprovalIssuers.ts`. Those change only with a pull request and a
+deploy. The code list is checked first.
 
 <Info>
-  The hosted deployment trusts one approver in code, added on 2026-09-28.
-  Approver keys are always Ed25519, whatever signing algorithm the server itself
-  uses.
+  The hosted deployment's code list holds one key, `manager-charak1987-key-1`,
+  revoked on 2026-09-30; its current approver key was added through maker
+  checker. Approver keys are always Ed25519, whatever signing algorithm the
+  server itself uses.
 </Info>
 
 ## Add an approval to any action