@robota-sdk/agent-cli 3.0.0-beta.96 → 3.0.0-beta.99

package/CHANGELOG.md

@@ -1,5 +1,52 @@
 # @robota-sdk/agent-cli
 
+## 3.0.0-beta.99
+
+## 3.0.0-beta.98
+
+## 3.0.0-beta.97
+### Minor Changes
+
+- 0d43f37: **An editor can reopen an earlier conversation over ACP and offer the agent's slash commands.**
+
+  `@robota-sdk/agent-transport-acp` sends `available_commands_update` once the editor holds the session
+  id — the runtime's commands and the user-invocable skills, each with its argument hint — and again
+  after a prompt that changed the list (a plugin reload, a preset). A host can supply `loadSession`;
+  the agent then offers `session/load`, checks it exactly like `session/new` (the served directory, no
+  editor MCP servers or extra roots, workspace trust), refuses it while a prompt runs, and replays the
+  loaded conversation — what was typed, what the agent answered, and each finished tool call, a reused
+  call id getting a row of its own — before it answers. The port makes the stored session current in
+  the object the transport was attached to, so a host attaches a forwarder such as a session slot.
+  The published narrow `IAcpTransportSession` contract remains supported: command listing and history
+  display reads are optional capabilities. Loading is offered only with both the host port and the
+  history read, so a session cannot be replaced without replaying its conversation.
+
+  `robota acp` supplies the load: the editor may load a stored session of the folder it serves that
+  this version can read, and the agent replaces its session with it and shuts the old one down. A load
+  is refused while the current session has work in progress, and for a stored session with an active
+  goal, a live loop or a schedule that restore would re-arm to fire, which would otherwise run unseen
+  by the editor. With `--no-session-persistence` nothing is stored, so loading is not offered.
+
+### Patch Changes
+
+- e5a4254: **An editor that offers its file system carries the file tools' reads and writes.**
+
+  `Read`, `Write` and `Edit` take an optional `editorFiles` port (`IEditorFileAccess`), asked at each
+  call. On the host, after the tool's containment check (the permission gate has already decided),
+  `Read` returns the editor's text, unsaved changes included, and `Write` hands the content to the
+  editor; `Edit` reads where `Read` reads and writes where `Write` writes. The editor's text keeps
+  `Read`'s byte budget, binary refusal, formatting and cancellation, and an editor failure becomes the
+  tool's error result. `Glob` and `Grep` still search the disk and end their result with a note saying
+  so while an editor is attached. A sandbox with its own filesystem still carries every file tool, and
+  commands never use the editor. `createDefaultTools` and `createCodingPack` pass `editorFiles` through
+  to those tools only.
+
+  The ACP agent transport records the editor's `clientCapabilities.fs` and, once `session/new` binds the
+  session, hands the host an access through the new `onEditorFileAccess` option that sends
+  `fs/read_text_file` and `fs/write_text_file` for that session, for what the editor offered; stopping
+  the transport withdraws it. `robota acp` connects the two, so Read, Write and Edit go through the
+  editor in an editor that offers `fs`; `terminal/*` is not used.
+
 ## 3.0.0-beta.96
 ### Minor Changes