Tianyi Cui
bf29247fad
V3 permits external event, source and content identities and additional request-tool fields. Copying those values into V4 can give an old plugin named tool a core source identity, turn old tool-addition content into a registry instruction, or activate formerly ignored deferLoading and delivery metadata. Rejecting such collisions would instead refuse valid source logs. Keep historical extensions in the existing extensible JSON representation. Prefix unknown content and ignorable event tags with plugin:, preserving all other content fields and opaque event payloads. Prefix external source identities with plugin:plugin: or plugin:source: so wrapper and direct kinds cannot collide even when original names already contain a category prefix. Known first-party mappings remain explicit and unchanged. Prefix extra request-tool field names and block-start field names with plugin:, retaining exact values and existing-prefix doubling. Core schema parameters, arguments, replay state and nested plugin data are not traversed. Keep future-generation delivery records inactive after header promotion. Pin the V3 event vocabulary independently of the current writer and provide an offline verifier against an explicitly selected historical source commit. Attachment authorization and export inspect declared event content only. Team checkpoints preserve all own keys of unknown JSON blocks while still rejecting malformed known content and retired core tool-result blocks. Exercise physical read/write/reopen, prefix injectivity, own __proto__ keys, provider opacity and retained source-identity snapshots. No generic extension block, metadata wrapper or new schema-tooling type is introduced. V4 type declarations, persistence schema, checkpoint and frozen V0-V3 codecs remain unchanged. Canonical tool-result lifting and incomplete child-catalog policy remain separate concerns. Adapted from the extension-preservation work in 7ba7e174dd1 by Tianyi Cui. Co-authored-by: Tianyi Cui <[email protected]>
description, kind
| description | kind |
|---|---|
| Package map for the application's Remote layer: typed Client-to-Host capability calls, results, and forwarded events, for users and maintainers navigating the group. | package-group |
api/ — Remote API layers
English | 中文
Summary
The api/ group provides the application's Remote layer: a Client environment can call the business capabilities running on the Host — manage goals, run commands, list the plugin inventory, discover file and session references — as typed method calls, and receive the results or forwarded Host events. remotes decides which capabilities are exposed and how each call reaches the right session's agent; gateway carries the calls and their results between Client and Host. The stack runs over the application's shared Connection; streaming session data is deliberately outside it.
Table of Contents
Packages
The packages below provide the Remote layer; the package READMEs own the exhaustive contracts.
| Package | Role | ctx key |
|---|---|---|
remotes/ |
Chooses which Host capabilities and events the Client can consume. | — |
gateway/ |
Carries typed unary calls, multiplexed streams, and forwarded Host events. | ctx.typertGateway / ctx.remote |
session-controller/ |
Owns Session commands, history streams, live control state, and Agent/Session identity policy. | ctx.sessionController / ctx.remote.session |
settings-controller/ |
Owns the configuration-surface reads and writes over the settings-domain seams. | ctx.settingsController, ctx.credentialsController / ctx.remote.settings, ctx.remote.credentials |
workspace-controller/ |
Owns Workspace mutations and the complete Client Workspace projection. | ctx.workspaceController / ctx.remote.workspace |
terminal-controller/ |
Session-owned interactive shells, screen recovery and browser terminal control. | ctx.terminalController / ctx.remote.terminal |
workspace-files/ |
Owns bounded workspace file access — stat, paged read, list, and the instrumented-operation changes feed — and the Client file resource provider over it. |
ctx.workspaceFiles / ctx.remote.workspaceFiles |
Remote calls run Client → Host over the application's shared Connection. API Gateway owns Remote transport, while the controller packages own Session, configuration-surface, and Workspace behavior. Feature packages register exact Connection Fetch routes for responses that do not fit Remote invocation, such as streamed downloads.
Related documentation
Start with the API Gateway reference to see the Remote model end to end, then the Typert subsystem page for the shared definitions and Connection for the physical carrier.
- API Gateway reference — the current-state reference for the Typert API Gateway: programming model, generation pipeline, and runtime invocation.
- Typert subsystem reference — the public contracts shared by protocol, Gateway, and consumer assemblies.
- Connection — the RPC carrier,
/apitrust fence, and response envelopes behind every Remote call.
Dev Note
Working context for maintainers — click to expand
None.