Yixiang TuandTianyi Cui
e0bd7e1960
Session V4 reserves developer-role messages for incremental model-visible session changes. The role, tool addition/removal blocks, and deferred-loading marker need a durable representation before independent provider and UI integrations can emit or consume them. Known developer events must match an open turn and step; unsupported providers and UI consumers fail explicitly. Request headers already capture full tool definitions. Persisting another ToolSchema in each addition would duplicate Session information and create two definitions that could drift. Additions therefore store toolName, and the containing developer event uses headerSeq to select one earlier known request/header for all its additions. A same-name replacement keeps its historical definition identity through restart, fork and surface changes. Removals require no definition copy, and ordinary developer messages omit headerSeq. Generic sourceEventSeqs remains independent derivation metadata. The rejected inline tool field is optional never with @persistenceReserved. The schema extractor retains that uninhabited slot, so permitting a future value requires a format bump instead of being mistaken for compatible optional metadata. Unrelated optional fields remain additive and readable. Native and Session admission reject missing, forward, non-header, unknown, ambiguous and incomplete referenced definitions, and reject the retired inline tool field. Validate complete schema fields only for referenced definitions, preserving unrelated header behavior and extra JSON metadata. Unknown ignorable records remain opaque. Empty developer nodes retain their surface position without producing a message or shadowing the system head. No automatic emitter, provider activation, UI implementation, or speculative public resolver is added. Keep the core-owned developer source binding beside the introduced role, including the request-only type rejection and attribution round trips. Update consumer guards, SDK/snapshot handling, bilingual owner documentation, and the same unreleased V4 acknowledgement. Keep earlier tool/source migration work and its documentation in the parent. Preserve the existing recorded Cordis inspection generation from the original developer change. Integration keeps the final source layer as the sole parent and preserves master's Messages input filtering, empty-user omission, empty tool results, and system-update placement. Developer/deferred guards still run before conversion. Native V4 admission, header references, reservation declarations, and generic tooling match the validated marker candidate. Parent-owned fixture and generator fixes remain in the parent. Earlier feature validation passed full build, full lint, 41 doc-sync gates, and 16 hygiene gates. The unchanged native implementation retains that evidence. The focused Session/V4/request-input run passes 884 tests across 38 files with 100% statement, branch, function and line coverage for the V3-to-V4 package and Session surface. Consumer tests pass 482 with one existing skip; tool, message and optional-field tests pass 146. Cordis inspection and compaction replays pass in both source and built modes (two cases per mode). Ten invalid referenced-definition/unknown-header controls failed before their scoped guards and pass after them. Reservation validation: the actual generated developer root records tool as optional primitive never. Widening it requires a bump, while traceId remains additive and preserved; all 85 focused reader/classifier tests pass. Final-parent validation: 205 tests across eight provider, type, catalog, Session and native-format files pass. The preserved parent fixture verifies Messages input-history replay; runtime/declaration and parent-owned-file comparisons show no loss during the final rebase. 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.