Files
deepseek-harness/packages/api
imccyu 027cbdfe5d refactor(faces): keep the generated contributions out of the Host aggregate
The Gateway and the carrier each compiled both halves under one tsconfig, so
the Host aggregate built their browser faces — including the face that owns
`ctx.remote`, the most likely future consumer of a generated `/remote`
contribution. Both packages now expose a host and a client face, and each
aggregate references only its own; three modules the halves share appear in
both file lists, as api/remotes already does.

The two apps/web specs in the Host aggregate restate the conversation engine's
Context key format instead of importing the Client runtime for it. A drift
makes the key miss its rendered node, so the assertion fails loudly.

The Host aggregate now reaches one Client project, the carrier's host face,
which the Gateway's own dispatch face needs; no generated contribution is
reachable from it.
2026-08-11 23:33:16 +08:00
..

api/ — Remote API layers

English | 中文

The application-facing Remote stack. remotes owns BFF policy and the selected business API, while gateway implements the TypeRT unary RPC endpoints shared by Host and Client environments.

Package Role ctx key
remotes/ Host Agent/Session lookup policy and Client Remote contribution assembly no service; configures ctx.typert and consumes ctx.remote
gateway/ Host TypeRT dispatcher and Client Remote endpoint ctx.typertGateway / ctx.remote

The runtime dependency direction is remotes → gateway → connection → webserver: the BFF consumes the shared TypeRTClientRemote contract, Gateway delegates transport to Connection, and Connection mounts on the HTTP server. Cordis service injection and Client module metadata preserve this order without importing the concrete Gateway from the Remotes Client entry.

Known Limitations and Deferred Work

  • Connection and WebServer remain at client/connection and host/webserver; a later package-only move can place them under api/connection and api/webserver without changing their service contracts.
  • The legacy API Proxy remains at host/apiproxy as the fallback for methods not yet migrated to Remote. It consumes the Host resolver owned by api-remotes so migrated and legacy methods retain one Agent/Session identity policy.