@oddington/sdk 0.1.34 → 0.1.36

package/README.md

@@ -79,6 +79,21 @@ declared `review` handler crosses the Inbox publication seam as `review`; Inbox
 retains the canonical `invoice-import` routine identity separately, without
 deploying or executing that handler.
 
+With `access: { ai: true }`, `os.ai.generateText` returns non-empty `{ text }`.
+`os.ai.generateObject` returns `{ object }` validated against the requested
+`schema`, with its inferred type. An invalid answer throws `RoutineAIError`
+with code `invalid_output`, a clear bounded `detail`, and the original final
+answer as optional `text` for routine-owned recovery. The text is bounded at
+256 KiB and excluded from the error message and ordinary JSON serialization.
+The routine can inspect it explicitly, apply its own recovery rules, report
+an item failure and continue; it must not cast a rejected answer to the promised
+type. OS does not coerce, drop fields, repair or retry automatically.
+
+An AI call failure can be caught and handled without automatically failing the
+Run. Uncaught routine or step exceptions still fail execution, and outstanding
+AI calls drain before completion. The host retains authority, isolation,
+cancellation and byte limits. Local and remote Runs use the same API.
+
 The bounded grammar supports closed objects with required properties, arrays with
 an explicit `maxItems` from 1 to 64, booleans, strings (at most 4096 code points),
 finite numbers and safe integers with optional inclusive bounds, and Files.
@@ -413,7 +428,12 @@ across processes or fresh routine runs. Caller inputs remain owned by the caller
 Each request resolves current authority; hosted routine Files calls use the
 selected workspace's HTTPS OS host, and managed calls use the authenticated
 private parent transport. `FileOperationError` exposes a bounded code,
-status and retryability without server details. Reads return the successful Web
+status and retryability. Input validation can also include a safe `detail` reason
+and numeric byte counts; its message explains the rejected field or expected
+versus received size. Streaming rejection marks partial received counts with
+`receivedAtLeast: true`. These facts survive local Run summaries and saved
+failure evidence without raw names, keys, file content or provider text. Older
+errors without `detail` remain valid. Reads return the successful Web
 Response without consuming its body. Local transfer is bounded and buffered
 before constructing that Response. Creation grants private creator access;
 workspace membership alone never grants another creator's File.
@@ -775,12 +795,11 @@ Checkout-backed app children retain immediate publication.
 
 Retain evidence with `inbox.files.add({ path: 'evidence.txt' })`. Paths stay within
 the invocation's working root and uploaded bytes are verified against the retained
-file. Use `inbox.repository.readRecords`, `writeRecords`, `updateRecords` and
-`deleteRecords` for shared Records capabilities. Writes require a trusted routine
-launch and installed write grant. Carry the returned `receipt.commit` into a
-subsequent `readRecords({ repository, refs, atCommit: receipt.commit })` to capture
-the prepared version for review. Retrying writes or publication uses the same
-request key and exact input; server boundaries own validation, effects and receipts.
+file. Use `data.repository(name)` for Record reads and `changes()` for guarded
+creates, updates and deletions. Local Runs read their own successive proposals
+and leave ordinary uncommitted files for review. `os routine publish` sends the
+retained logical changes explicitly. Inbox publication has no Record methods;
+managed Response handlers retain their separately injected repository capability.
 
 Hosts publishing as a member supply the existing `request` option: