Yichen Jiang
590b76a7f0
Two had real security consequences: The bootstrap rejection ran on npm dotenv's parser while process.loadEnvFile applied the file with Node's own. Two independently maintained dialects meant the check and the thing it guards could disagree: a name Node accepts but the checker misses would reach process.env unchecked, and BASH_ENV there runs a file of the project's choosing on every `bash -c` the bash tool issues. Parse once with node:util's parseEnv — the same engine loadEnvFile uses — and assign the entries already checked, which also drops the dotenv dependency. llm-pi-ai still returned a literal profile.apiKey ahead of everything, and it registers a settings namespace, so the defect removed from llm-deepseek survived intact in its design twin. The field is gone from the profile schema, the resolution path, and the tests. The rest are consistency and documentation defects the review named: - verify-config-source-ownership did not scan the Python runtime's bundled cordis.yml, which still inlined apiKey and baseURL. Both are covered now, and the line-anchored INLINE_DENY documents that it is a tripwire, not a parser. - The deny list missed NODE_TLS_REJECT_UNAUTHORIZED, the askpass hooks, the GIT_CONFIG_* redirections, and PYTHONHOME — all implied by its own stated rule about what a variable does. - Snapshot lookups folded case on Windows, where environment names are case-insensitive and an exact-match Map could miss a higher-ranked layer. - The credentials note claimed a read-time permission check was "not taken" while this PR implemented it; the credentials-local README still described two layers, live process.env reads, dotenv-era limitations, and a renamed anchor; the llm-deepseek README still advertised the removed literal apiKey; and web.ts and base.cordis.yml kept personal-overlay wording. - The ownership note's literal-apiKey claim now names its scope: the web-search providers keep a literal field but register no settings namespace, so nothing can shadow a stored credential through them.
ui/ — human and SDK-client integration surfaces
English | 中文
Human-facing channels and the out-of-process SDK server. These are product packages: real interfaces that a person or SDK client drives.
| Package | Role | ctx key |
|---|---|---|
commands/ |
Human-command registry: shared discovery metadata, scoped shadowing, cancellation, and direct UI dispatch | ctx.commands |
user-approval/ |
One-shot user-approval mechanism, closed outcome vocabulary, audit events, and per-session approval policy | ctx.approval |
permission/ |
User-facing permission presets (workspace-write/danger-full-access): one product-level select bundling the sandbox-mode and approval-policy knobs, written through to their session events |
ctx.permission |
user-interaction/ |
Abstract human question/answer seam used by UI-backed confirmation tools | ctx.userInteraction |
tool-ask-user/ |
Model-facing ask_user_question tool over ctx.userInteraction |
(registers on ctx.tools) |
jsonrpc/ |
Stdio JSON-RPC server for out-of-process SDK clients | (drives ctx.agents) |
app-boot/ |
Shared boot glue for the app bins: .env loading, fail-loud Loader guards, snapshot-aware config resolution, the settle-the-tree boot sequence |
(library for the bins) |
A UI integration is a client-driver plugin, not a loop change: it consumes the existing agent/* event taxonomy and the dsh-agent factory. jsonrpc serves out-of-process SDK clients, while non-interactive one-shot tasks use cli-demo. commands is the human-only discovery and dispatch plane for interactive adapters; command input and output do not become model messages.
user-approval, user-interaction, and tool-ask-user live here because asking a human is a UI-backed product affordance, not part of the providerless core spine. user-approval owns the one-shot ctx.approval decision mechanism and its policy tier; answerers remain with the channel or automation transport that owns the agent. user-interaction remains provider-neutral (ctx.userInteraction), while tool-ask-user is its model-facing consumer and interactive app packages provide concrete providers.
The runnable app bundles composed over agent-spine-demo live in examples/ (cli-demo, acp-demo, jsonrpc-demo), each with its own entry contract. The product dsh CLI uses no demo bundle. ui/ keeps the reusable human/SDK channel plugins and shared app-boot glue; the automation-only ACP transport lives in acp/. Each front door owns its stdout policy, and a leaf cordis.yml supplies backends and optional tools.