Source Evidence and Project Map
English | 中文
Every conclusion should return to source, tests, or an explicit limitation
This page is not a file inventory. It explains how the bluebook covers the project, what evidence supports eight judgments, and which questions the repository still cannot prove.
Build a capability map from architecture and every first-party package-group README.
Enter source and tests through the Agent path, governance path, and failure boundaries.
Actively seek POC, non-security-boundary, non-recovery, and protocol limitations.
Evidence method
The first pass reads the architecture overview, package-group map, and every first-party package-group README under packages/ to answer which capability families exist and how they compose. The second pass follows Agent creation, model requests, tool execution, session persistence, client projection, subagents, workflows, sandboxing, and protocol entry points into core source and tests to answer how a real task runs and fails.
vendor/ is a manifest-synchronized Cordis upstream copy rather than an independent source for product-innovation claims. native/ and python/ enter coverage through their READMEs and consuming paths. Business value is inferred only where implemented mechanisms support it; market benefit, production scale, and industry completeness are not guessed from code.
Project capability map
| Project area | Primary responsibility | Bluebook location |
|---|---|---|
core/ | Sessions, prompts, tools, Agents, and the agent loop | How one task runs |
api/ and typert/ | Remote BFF, type graph, loader, and RPC registry | Typed capability shared across interfaces |
llm/ | LLM Service Definition, catalog, adapters, and DeepSeek providers | Capability seams and model configuration |
shell/, subprocess/, terminal/ | Commands, process trees, and persistent terminal execution | Tool execution and environment constraints |
fs/ and lsp/ | Filesystem capability, policy, and language servers | Engineering scenarios and file governance |
skill/ and web/ | Skill registration, catalogs, loaders, search, and fetch | Knowledge-work scenarios |
context/ and compaction/ | Request context and model-history compaction | Long sessions and replayable context |
subagent/ and workflow/ | Delegation, continuable children, and dynamic workflows | Long-running collaboration and limitations |
todo/, plan/, goal/, jobs/, schedule/ | Plan state, goals, background jobs, and scheduled work | Observable task progress |
preset/, bundle/, boot/ | Per-session composition, installable bundles, and application startup | Everything is a plugin and platform assembly |
guard/ and interaction/ | Loop hygiene, timeouts, commands, permission, approval, and questions | Tool governance and human control |
session/ | Persistence, projections, titles, telemetry, and queries | Recovery, replay, and evidence |
settings/, credentials/, identity/ | User settings, credential references, and anonymous identity | Configuration governance and secret separation |
client/ and host/ | Browser runtime, UI modules, Host, and API proxy | Plugin-defined business UI |
acp/, sdk/, and python/ | Automation protocol, JSON-RPC, and two SDKs | Multiple access paths |
hooks/ and extensions/ | External-tool bridges and runtime self-modification | Ecosystem integration and trusted dynamic extension |
sandbox/, e2b/, code-runtime/ | File confinement, remote-execution POC, and script runtime | Governance boundaries and current limitations |
examples/, support/, util/ | Runnable compositions, test infrastructure, and zero-dependency utilities | Composition verification and engineering support |
Evidence index for eight innovations
| Conclusion | Primary source or documentation | Representative test evidence | Confidence and limitation |
|---|---|---|---|
| Everything is a plugin | Architecture overview, bundle group, application boot | Preset mount tests | High; plugin trust follows deployment composition |
| Complete capability seams | Capability seam rules, LLM group, E2B POC | Local sandbox tests | High; provider security properties differ |
| Model-visible state is replayable | Session implementation, agent loop | Request reconstruction tests, session property tests | High; compliance retention is outside the log |
| Tool governance pipeline | Tool registry, approval service | Tool behavior tests, approval tests | High; covers actions dispatched through the registry |
| Per-session Agent composition | Agent preset implementation | Session preset tests, discovery tests | High; this is not an enterprise tenant system |
| Observable long-running collaboration | Subagent group, workflow group | Continuation tests, workflow integration tests | High; dynamic workflows do not recover after restart |
| Multiple access paths | ACP, SDK, Python | ACP turn tests | High; each protocol exposes its own subset |
| Client plugin graph | Client modules, Web runtime | Module loader tests, conversation tests | High; domain UX still requires product design |
Locate the critical runtime paths
Agent and model requests
The agent loop records turn/start, step/start, user messages, streaming assistant content, tool calls, and end reasons, and uses deriveMessages() for the next request. The session implementation owns append, surface projection, format loading, forks, and message derivation.
Tools and approval
The tool registry declares guards, execution phases, results, and presentation intent. The approval service declares ask/never, fail-closed behavior, and replayable audit events. Together they prove that “the model proposed a call” and “the action was authorized to execute” are separate stages.
Session composition and recovery
Agent presets own discovery, resolution, standing mounts, recomposition limits, and scoped service reads. Session persistence supplies write, read, and preparation paths; continuable subagents preserve their descriptor and delegated policy in their own sessions.
Interface and protocol
The Web runtime builds conversation and trajectory projections from session windows. ACP publishes a narrower automation interface and emits only committed assistant text. SDKs drive the same Agent and session services over JSON-RPC.
Use falsification to bound conclusions
| If this fact were found | Conclusion it would overturn or narrow | Current check |
|---|---|---|
| Model-visible content had no corresponding session event | “Model-visible state is replayable” | Main request path records first; no exception found |
| A tool could reopen execution after a guard denied it | “Governance tightens monotonically” | ToolGuard has no allow branch |
| A child Agent could prompt for escalation unattended | “Delegated authority is fixed” | Delegation appends approval/policy: never |
| A dynamic workflow resumed after restart | The current non-recovery limitation | README explicitly states no journal or resume |
| SandboxMode restricted network and credentials too | The file-effects-only limitation | Service vocabulary explicitly excludes network, process, syscall, device, and credentials |
What the current repository cannot prove
- It cannot prove that any industry has a complete out-of-box solution; the repository supplies general capabilities and example compositions.
- It cannot prove production scale, availability targets, or unit economics; the target deployment needs capacity tests and billing data.
- It cannot prove session logs automatically meet a specific regulation; compliance depends on identity, storage, and policy.
- It cannot prove arbitrary model-written code is safe to execute; several worker/VM implementations explicitly are not hostile-code security boundaries.
- It cannot prove multi-Agent execution is faster or better for every task; benefits depend on decomposability, synthesis, and resource cost.
Enter the main path from a business conclusion, then read its limitations and tests
Beginners start with “From Task to Evidence.” Architecture and platform readers use this index to enter owner packages. Security reviewers work backward from “Governance Boundaries.” READMEs explain obligations, source confirms implementation, and tests prove critical branches remain exercised.
Evidence status: Confirmed against source, tests, and documentation in the current worktree unless noted. No real DeepSeek API, production load, or target-enterprise system validation was run.