@di-code/builtins

Reference namespace plugins used by the composable profiles. The package exposes only public workspace dependencies and contains no CLI-specific legacy loader path.

Every published subpath in package.json is a namespace entry with apiVersion, name, version, and apply; composition imports the exact subpath instead of using an aggregate factory. Consumers may import root exports for types and helpers, but a narrow composition should select only the entry it needs.

Provider composition is split into provider-openai, provider-anthropic, provider-deepseek, provider-kimi, provider-zhipu, and provider-faux; model-catalog, credential-env, runtime-selection, and provider-onboarding provide neutral selection/configuration services. Each adapter only contributes the @di-code/ai Provider and Model contracts to ProviderRegistry.

The default print profile mounts the registry, catalog, credential and selection entries before agent-loop. Provider entries with unavailable credentials are optional and leave a diagnostic inventory entry; selecting one still reports the normalized missing-key error. Environment variables take precedence over global then project settings for provider/model selection. provider-faux is deterministic and offline. image-generation and tool-generate-image are mounted before agent-loop; without an image API key the optional factory contributes no tool. session-memory and the Agent subscription are owned by their plugin Fibers and are released during reverse-order composition disposal.

Tool composition is split into workspace, process, network, tool-read, tool-write, tool-edit, tool-bash, tool-glob, tool-grep, tool-load-skill, tool-approval, tool-policy, and tool-output. Every executable tool is registered through ToolRegistry; a snapshot binds the workspace, process, and network capabilities, then runs policy, approval, and output presentation around tool execution. The file tools continue to canonicalize the allowed root and reject escaping symlinks, while tool-bash keeps structured process execution, bounded output, timeout, and abort handling. Capabilities are a boundary for composition and auditing, not an in-process sandbox.

createSessionToolPolicy() creates an isolated policy for one Session. Its stable catalog is still sent to the model, while authorize() is enforced immediately before approval and execution. read_only rejects write, edit, and bash with ToolPolicyError code POLICY_DENIED; cancellation, persistence timeout, and disposal use distinct codes. Mode changes are serialized, repeated changes are idempotent, and the coding-agent host persists them as di-code.tool-policy:mode_changed Session events so resume and fork rebuild state from the event log. Projection and plugin-state readers are sampled at the authorization boundary.

image-generation optionally installs an OpenAI Images-compatible generator when DI_CODE_IMAGE_API_KEY or OPENAI_API_KEY is available. tool-generate-image exposes that generator to Agent sessions, saves results under the user-level .di-code/artifacts directory, and returns validated ImageContent blocks. DI_CODE_IMAGE_BASE_URL and DI_CODE_IMAGE_MODEL support compatible third-party image gateways.

tool-registry and tool-read are standalone namespace modules: loading a read-only composition does not import the aggregate @di-code/builtins entry or the write, edit, and bash implementations. The root entry re-exports the same public symbols for SDK consumers.

CLI and presentation composition is exposed through CommandRegistry, ModeRegistry, and RendererRegistry. The cli-parser, command-*, mode-print, mode-json, mode-interactive, output-json, tui-renderer, theme, and interactive-context entries are owner-disposed and contribute no second Agent loop. Command help is generated from the command inventory; JSON output is rendered as version 2 records.

RPC composition provides the built-in rpc-protocol-v1 and rpc-events entries. @di-code/coding-agent owns the product session-factory and process-facing rpc-server entries, so the RPC bootstrap only consumes their service contract. RpcMethodRegistry owns the accepted method inventory; the v1 entry registers prompt, cancel, and get_state in the di-code.rpc-v1 namespace before the server starts.

Session persistence is split into a session-store-jsonl registry entry and the product-owned JSONL implementation entry. Consumers resolve SessionStoreRegistry.get("jsonl") instead of constructing SessionManager directly, so an interactive composition can replace the persistence implementation without changing the Agent session factory. The session-migrations entry owns an atomic schemaVersion: 0 -> 1 upgrade for built-in plugin records; incompatible session headers remain rejected by the v2 decoder.

The base composition also exposes session-migrations, compaction-tool-result, and the RPC mode entry. compaction-tool-result is consumed by the SessionFactory and truncates tool-result message content before the Agent selects a compaction cut, while preserving the message count and branch ids. DiagnosticSinkRegistry receives redacted runtime diagnostics; plugin-profiler, plugin-invariants, and plugin-test-runtime are loaded only with the development observability profile and are owner-disposed with their Fibers.