Release Aiden Agent 0.60.0

docs/aiden-remote-api-v1.md

@@ -288,7 +288,7 @@ These routes were frozen as contract in Phase 1 and implemented in Phase 4 throu
 - `POST /bots/{botId}/restore`: `If-Match` plus `Idempotency-Key`, returning the restored authoritative detail.
 - `GET /bot-favorites` and `PATCH /bot-favorites`: at most 20 unique, non-archived Bot IDs; update is whole-list replacement under `If-Match`, so membership and order change atomically. A replacement may omit archived Bots and may still edit unrelated active favorites, but adding an archived Bot returns `bot_archived`. No successful favorites response retains an archived Bot ID.
 - `GET /bot-conversations?cursor=…&query=…&botId=…&limit=…`: newest-first stable pages of at most 50 items, with a 200-scalar search query and 128-scalar cursor. Search is confined to Bot name/purpose, conversation title, and the bounded previews actually projected by the Mac. Every item has `updatedAt >= createdAt`. `canRespondToApproval: true` is valid only while `activityState` is `waiting_for_approval`; a waiting row may still be non-respondable when the paired device lacks authority.
-- `POST /bots/{botId}/chats`: open-or-create the Bot's one persistent chat. The frozen v1 response remains `201` and the operation identifier remains `createBotChat` for compatibility with shipped clients, even when the existing chat is returned. When it already exists, the Mac returns it unchanged and ignores creation-only provider/model input. When absent, an empty body inherits the Bot provider/model; otherwise one exact providerId/modelId pair is required, plus `Idempotency-Key`. Partial pairs never fall back. The creation pair must be currently available; an unavailable selection fails closed without fallback. The Mac injects the authoritative `botId` and hidden managed-home workspace; neither identifier is accepted in the body, and every successful response includes that authoritative `botId`. Concurrent calls and retries converge on the same chat. Legacy duplicate chats remain readable for recovery, but only the deterministic canonical chat is writable or projected in the Bot inbox. After 0.59.0, while a host serves `bot-durable-session-v1`, `POST /chats/{chatId}/turns` on a Bot's chat answers `400 invalid_request` ("Update Aiden on this device to chat with this Bot…") and appends nothing: the Bot's conversation is its durable session, and a workspace-chat turn would run outside it. Paired desktops open a host's Bot through `GET /bots/{botId}/session`, its `/session/events` stream and the session routes, as phones do, and negotiate `bot:activity` when the host announces `bot-activity-v1` (they do not take `bot:cards`). A desktop that misses that answer (the host was briefly unreachable) asks again on its next reconnect; a refusal is final. Desktops offer Queue and Steer only while they hold `bot:activity`, because without it the host sends them no `queued` list. A desktop reads a newer host's session as far as it understands it, as phones do: an unknown session state reads as `unavailable`, an entry it cannot parse is left out, and a stream event it cannot parse makes it read `GET /bots/{botId}/session` again instead of dropping the stream. After a clean `closed` event it reopens the stream at once (up to twice in a row, then with backoff). `BotSession` and `BotMessageReceipt` compose the state fields from `BotSessionStateFields` and close with `unevaluatedProperties: false`; `BotSessionState` alone stays closed for Resume, Dismiss and Stop. A host error's own `message`, when short and printable, is what a paired desktop shows for a refused request.
+- `POST /bots/{botId}/chats`: open-or-create the Bot's one persistent chat. The frozen v1 response remains `201` and the operation identifier remains `createBotChat` for compatibility with shipped clients, even when the existing chat is returned. When it already exists, the Mac returns it unchanged and ignores creation-only provider/model input. When absent, an empty body inherits the Bot provider/model; otherwise one exact providerId/modelId pair is required, plus `Idempotency-Key`. Partial pairs never fall back. The creation pair must be currently available; an unavailable selection fails closed without fallback. The Mac injects the authoritative `botId` and hidden managed-home workspace; neither identifier is accepted in the body, and every successful response includes that authoritative `botId`. Concurrent calls and retries converge on the same chat. Legacy duplicate chats remain readable for recovery, but only the deterministic canonical chat is writable or projected in the Bot inbox. From 0.60.0, while a host serves `bot-durable-session-v1`, `POST /chats/{chatId}/turns` on a Bot's chat answers `400 invalid_request` ("Update Aiden on this device to chat with this Bot…") and appends nothing: the Bot's conversation is its durable session, and a workspace-chat turn would run outside it. Paired desktops open a host's Bot through `GET /bots/{botId}/session`, its `/session/events` stream and the session routes, as phones do, and negotiate `bot:activity` when the host announces `bot-activity-v1` (they do not take `bot:cards`). A desktop that misses that answer (the host was briefly unreachable) asks again on its next reconnect; a refusal is final. Desktops offer Queue and Steer only while they hold `bot:activity`, because without it the host sends them no `queued` list. A desktop reads a newer host's session as far as it understands it, as phones do: an unknown session state reads as `unavailable`, an entry it cannot parse is left out, and a stream event it cannot parse makes it read `GET /bots/{botId}/session` again instead of dropping the stream. After a clean `closed` event it reopens the stream at once (up to twice in a row, then with backoff). `BotSession` and `BotMessageReceipt` compose the state fields from `BotSessionStateFields` and close with `unevaluatedProperties: false`; `BotSessionState` alone stays closed for Resume, Dismiss and Stop. A host error's own `message`, when short and printable, is what a paired desktop shows for a refused request.
 - `GET /bot-capabilities?botId=…`: safe revisioned provider/model, image-input capability, file-scope, shell, connection/MCP, skill, and other-capability catalog plus the full notice status. The optional, exact `botId` selects an authenticated existing Bot so its saved unavailable choices can remain visible; omitting it returns the generic creation catalog. Unknown, duplicate, malformed, empty, and overlong query values fail closed. `supportsImages` is explicit and unknown capability fails closed. The response never returns display copy that the client could mistake for authority.
 - The catalog’s additive `skillsEnabled` boolean defaults to `true` when omitted. When `false`, skill inventory discovery and incarnation reconciliation pause; target-Bot catalogs may retain that Bot’s authenticated saved skill IDs as unavailable choices. Clients may preserve or remove those saved choices during unrelated edits, but must not offer unavailable unselected skills as new choices. The Mac enforces exact saved ownership and per-chat narrowing, withholds skills from all runtime contexts, and restores unchanged selections when the global gate reopens. Invalid provided values fail decoding.
 - `PATCH /bots/{botId}/capabilities`: `If-Match` Full/Custom update with the exact current `catalogRevision`. Full requires `confirmedForeground: true` and may carry one exact provider/model pair; omitting both preserves the saved choice for compatibility with older clients, while supplying only one is invalid. Custom contains exactly one currently available provider/model pair plus only exact positive opaque selections from that catalog. Optional `visionModel` uses three-state semantics: omitted preserves the companion, `null` clears it, and an exact provider/model object sets it only when the catalog marks that model image-capable. A supplied pair becomes revisioned durable authority, changing either primary or companion fences active turns, and the canonical persistent chat mirrors only the primary model. An unavailable model remains visibly blocked and is never replaced by fallback.