xinyin025/LangBot
1
0
Fork 0
mirror of https://github.com/langbot-app/LangBot.git synced 2026-11-05 07:12:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

refactor(api): route management and runtime consumers through application APIs

Browse Source
This commit is contained in:
huanghuoguoguo
2026-10-29 15:48:15 +08:00
parent 8f2f537e34
commit 82486225a6
86 changed files with 2532 additions and 2043 deletions
Download Patch File Download Diff File Expand all files Collapse all files
dev-docs/architecture/application-api.md
+18 -7
View File
@@ -2,9 +2,10 @@
The application package provides a callable business boundary inside Core. A
consumer supplies a trusted identity and operation arguments, then receives a
validated result or a stable application error. HTTP, MCP, the management
assistant and `lbctl` retain their existing entrypoints in this change; their
adoption of this boundary belongs in separate changes.
validated result or a stable application error. Workspace HTTP routes, MCP tools
and management-assistant tools invoke this boundary. Their external paths,
response projections and authentication remain owned by each transport; `lbctl`
continues to use the same HTTP interface.
## Workspace operations
@@ -109,10 +110,20 @@ messages remain with their owning boundaries. Composite HTTP response layouts
(such as a combined monitoring page) are consumer projections of these
operations. This does not add new platform APIs or new instance-level powers.
Existing routes do not call the new application dispatcher. No SDK protocol or `lbctl` command is
changed by this foundation.
Workspace management consumers call the application dispatcher explicitly. HTTP
keeps its established business-error responses and rich request audit; the
application dispatcher does not duplicate that audit. Background assistant tools
record their own operations after the initiating HTTP request has finished.
Runtime business actions invoke `ExecutionAPI` before reaching the secured Host
action table. The transport separates trusted caller/run identity from business
arguments and preserves SDK response frames, structured errors and cancellation.
Internal handshake and stream-control messages retain their own boundary. No SDK
wire protocol or `lbctl` command changes are required.
Consumer adoption should verify the same operation through each selected
transport, including denied access, missing resources, invalid inputs,
cancellation and secret handling. The existing Core smoke exercises current
consumers; it does not by itself prove a new consumer integration.
cancellation and secret handling. The Core smoke exercises the HTTP and Runtime
protocols. Direct application tests also verify validation, isolation and business
effects; consumer regression tests retain the established HTTP/MCP response and
streaming contracts.