Expand description
ALwith’s app-side Rust: the types of the alwith-runtime-v1 protocol (always present) and the
client (feature client, on by default).
Protocol definitions are exported from the Runtime binary; Runtime never depends on this client
crate.
Modules§
- process
- Platform details for spawning child processes (hiding the console on Windows, etc.), shared by
module subprocesses and the host.
Platform details for spawning child processes: no console window pops up on Windows spawn. The
client spawning Runtime and modules spawning their own
child processes both use it; it is a no-op on non-Windows, so call sites need no
#[cfg(windows)].
Structs§
- Agent
Metadata - Attach
Info - Pending
Agent Request - Agent requests still unanswered at attach time (
session/request_permissionetc.); the new owner answers them withacpRespondusing the sameid. - Response
Error - The
errorin a response frame, in JSON-RPC shape. Runtime’s own errors use the codes below; ACP errors returned by the agent (acpRequestetc.) pass through unchanged,code/datacome from the agent. - Runtime
Client - Session
Event Frame - One frame in the journal.
lineis the raw ACP JSON-RPC text (before the Runtime envelope). - Session
Lifecycle Frame - Session
RunState - Session
Task
Enums§
- Client
Event - An event frame coming from Runtime. Protocol events are decoded as
RuntimeEvent; host extension events go toOther. - Frame
Direction - RunState
- Session run state. The first three are values of ACP v2
StateUpdatedirectly (reported by the agent, no longer derived by Runtime from traffic);Doneis a product state we synthesize ourselves: the protocol has no notion of “finished but unseen”. It = idle + unread, synthesized byupsert_run_stateon a running/done -> idle transition and consumed only bymarkRead. - Runtime
Event
Type Aliases§
- Request
Handler - The answer to
cliStatus. How to answer requests coming from the peer (Runtime): a module subprocess uses it to serve calls forwarded frommodules/<name>/<method>.