anbaric 1.56.5 → 1.56.7

package/docs/api/actors-and-agents.md

@@ -157,10 +157,12 @@ that fail throw `The OpenAI request failed with status <n>`.
 
 ### `AnthropicAgent`
 
-An `Agent` backed by the Anthropic Messages API. The API has no JSON-schema
-response format, so the output schema is offered as a single tool the model is
-forced to call; its arguments are the structured output. System messages are
-lifted out of the conversation into the API's own `system` field.
+An `Agent` backed by the Anthropic Messages API, asking for the output schema
+through the API's `json_schema` output format (every current Claude model
+supports it; the older forced-tool-call approach is rejected from Claude Opus
+5.5 on). Objects in the schema are closed and every property made required, as
+that format demands. System messages are lifted out of the conversation into
+the API's own `system` field.
 
 ```ts
 class AnthropicAgent extends Agent
@@ -175,9 +177,10 @@ type AnthropicConnection = {
 }
 ```
 
-Failures throw `The Anthropic request failed with status <n>`; a model that
-answers with prose instead of calling the tool throws `The Anthropic response
-carried no structured content`.
+Failures throw `The Anthropic request failed with status <n>`; a reply with no
+text throws `The Anthropic response carried no structured content`, and prose
+where JSON was asked for throws `The Anthropic response was not the JSON it was
+asked for`.
 
 ### `GeminiAgent`
 

package/docs/api/state-machine.md

@@ -348,6 +348,13 @@ Storage comes from `JobRunSchedulePersistenceFactory` — in memory locally, the
 platform database when deployed, where claiming a due run is atomic so several
 instances can schedule the same machines safely.
 
+Claiming coalesces: when more than one of a machine's runs has come due — the
+scheduler was down, a deploy took a while — only the most recent is claimed
+and started, and the earlier ones are recorded as **superseded** by it
+(`superseded_at` and `superseded_by` on the stored run). The consumer is sent
+one catch-up job, never one per missed tick. Runs of different machines, or
+of the same machine in different apps, are never coalesced with each other.
+
 ---
 
 ## `Actor`

package/docs/features/ai-agents.md

@@ -91,7 +91,7 @@ new OpenAIAgent("triager", "support", {
 
 new AnthropicAgent("triager", "support", {
     apiKey: process.env.ANTHROPIC_API_KEY!,
-    model: "claude-opus-5",
+    model: "claude-opus-5-5",
     maxTokens: 4096,                         // optional; the Messages API needs a budget
 });
 
@@ -102,9 +102,9 @@ new GeminiAgent("triager", "support", {
 ```
 
 Each asks its provider for structured output the way that provider supports it -
-OpenAI's JSON-schema response format, a forced tool call on Anthropic, Gemini's
-JSON response schema - so your action only ever sees properties matching the
-schema you gave it.
+OpenAI's JSON-schema response format, Anthropic's `json_schema` output format,
+Gemini's JSON response schema - so your action only ever sees properties
+matching the schema you gave it.
 
 For a provider none of them covers, implement an `Agent.Client` (a class with a
 `generate(request)` method) and pass it to a plain `Agent`. See the [API

package/docs/features/scheduled-runs.md

@@ -53,10 +53,14 @@ runs as they come due. Two things follow from that, both deliberate:
 
 - **A restart doesn't lose the timetable.** The plan is already stored, so the
   scheduler picks up where it left off.
-- **Downtime doesn't silently skip runs.** A scheduler that was down for two
-  days starts the runs it missed as soon as it comes back, rather than
-  pretending they never existed. If you don't want that catch-up for a
-  particular machine, make its action check `scheduledFor` and return early.
+- **Downtime doesn't silently skip runs — and doesn't replay them either.** A
+  scheduler that was down for two days starts **one** catch-up run as soon as
+  it comes back: the most recent run it missed. The earlier missed runs are
+  recorded as superseded by it, so the timetable shows what was skipped and
+  why, but an hourly sync that missed a day never becomes twenty-four syncs
+  fired in the same second. The job's `scheduledFor` tells you which run it
+  is; if a machine must not catch up at all, make its action check that and
+  return early.
 
 Every scheduled job carries the run it belongs to:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "anbaric",
-  "version": "1.56.5",
+  "version": "1.56.7",
   "description": "Everything needed to write an Anbaric app: state machines, jobs, document and secret stores, local in-memory implementations and the Anbaric Cloud clients",
   "license": "MIT",
   "type": "module",
@@ -24,9 +24,9 @@
     "prepublishOnly": "npm run build"
   },
   "dependencies": {
-    "anbaric-impl-cloud": "^1.56.5",
-    "anbaric-data-store": "^1.56.5",
-    "anbaric-state-machine": "^1.56.5",
-    "anbaric-tsapi": "^1.56.5"
+    "anbaric-impl-cloud": "^1.56.7",
+    "anbaric-data-store": "^1.56.7",
+    "anbaric-state-machine": "^1.56.7",
+    "anbaric-tsapi": "^1.56.7"
   }
 }