Source run without a managed installer
无需托管安装器的源码运行
A repository-owned source installer can provide a stable launcher, isolated staging worktrees, atomic upgrades, rollback storage, and shared maintenance workflows for personal customizations. It also makes the repository responsible for a second lifecycle beside the package manager: host dependency installation, credential prompting, checkout adoption, symlink ownership, staging branch coordination, upgrade recovery,
English
Problem
A repository-owned source installer can provide a stable launcher, isolated staging worktrees, atomic upgrades, rollback storage, and shared maintenance workflows for personal customizations. It also makes the repository responsible for a second lifecycle beside the package manager: host dependency installation, credential prompting, checkout adoption, symlink ownership, staging branch coordination, upgrade recovery, and continued compatibility between the installer and bundled maintenance skills.
That lifecycle is not required to run or develop DeepSeek Harness from a source checkout. Maintaining it expands the supported filesystem and Git state space without improving the repository-native execution path.
Decision
The repository supports source execution through its root pnpm scripts. The dsh entry in package.json launches apps/cli/src/bin.ts directly through node --import tsx/esm; artifact generation is the separate pnpm run build operation defined by the source-launch/build separation decision. The package script forwards arguments and inherits the caller's environment, including NODE_USE_ENV_PROXY=1 when a supporting Node version must honor HTTP_PROXY and HTTPS_PROXY. Users select Web with pnpm dsh web and headless execution with pnpm dsh --profile headless "task". The independent ACP example remains available through pnpm run demo:acp.
The repository does not distribute a source installer, an installer test suite, or skills that assume a managed current symlink and timestamped staging worktrees. Users own source checkout placement, Git updates, and any launcher they create outside the repository.
Alternatives considered
Keep the installer but document pnpm run as another path. This retains the managed launcher and rollback capability but keeps both lifecycle contracts active, including the installer tests and staging-aware skills.
Keep generic customization and upstream-publication skills. Their safety rules can apply beyond the staging layout, but the shipped workflows form one coupled maintenance system: customization discovers the installed staging checkout, upgrade performs the cutover, and upstream publication is selected from those personal changes. General Git contribution guidance already belongs to repository instructions and does not require product-bundled skills.
Replace the installer with a smaller launcher-link script. This reduces setup behavior but still makes the repository responsible for host PATH mutation and launcher ownership. Source scripts provide the entry points without that state.
Consequences
Source users invoke repository scripts rather than an installed dsh command. The repository provides no atomic upgrade cutover or preserved staging rollback checkout, and it does not automate the integration or upstream publication of personal source modifications. A future distribution mechanism must justify its ownership of installation and upgrade state, define recovery behavior, and add tests and user documentation without making the source-run path depend on it. Any future publication workflow must isolate one approved feature and obtain explicit approval before its first push and draft PR.
Verification covers repository-wide references to the removed entry points, documentation links, generated third-party-notice freshness, the direct package.json source command, and a source CLI smoke through the exact node --import tsx/esm runtime vector.
中文
问题
仓库自带的源码安装器可以提供稳定的启动器、相互隔离的 staging worktree、原子升级、回滚存储，以及用于个人定制的共享维护工作流。与此同时，仓库还必须在包管理器之外负责第二套生命周期：安装宿主依赖、提示输入凭证、接管检出、管理符号链接归属、协调 staging 分支、处理升级恢复，以及持续保持安装器与随附维护 skill（技能）的兼容性。
从源码检出运行或开发 DeepSeek Harness 并不需要这套生命周期。维护它会扩大需要支持的文件系统和 Git 状态空间，却无法改进仓库原生的执行路径。
决策
仓库通过根目录的 pnpm 脚本支持从源码运行。package.json 中的 dsh 项通过 node --import tsx/esm 直接启动 apps/cli/src/bin.ts；产物生成是独立的 pnpm run build 操作，由源码启动与构建分离决策规定。该包脚本会转发参数并继承调用方环境；当支持环境代理的 Node 版本必须遵循 HTTP_PROXY 和 HTTPS_PROXY 时，调用方可设置 NODE_USE_ENV_PROXY=1。用户使用 pnpm dsh web 选择 Web，使用 pnpm dsh --profile headless "task" 选择无头执行。独立的 ACP（Agent Client Protocol）示例仍可通过 pnpm run demo:acp 运行。
仓库不分发源码安装器、安装器测试套件，也不分发依赖受管理的 current 符号链接和带时间戳 staging worktree 的 skill。源码检出的存放位置、Git 更新，以及用户在仓库外创建的任何启动器均由用户负责。
考虑过的备选方案
**保留安装器，但将 pnpm run 记作另一条路径。**这样可以保留受管理的启动器和回滚能力，但两套生命周期约定仍会同时生效，其中包括安装器测试和依赖 staging 布局的 skill。
**保留通用的定制与上游发布 skill。**其中的安全规则也能用于 staging 布局之外，但现有工作流共同构成了一套耦合的维护系统：定制工作流查找已安装的 staging 检出，升级工作流执行切换，上游发布工作流则从这些个人修改中选择发布内容。通用 Git 贡献指南已经属于仓库指令，无需以产品随附 skill 的形式提供。
**用更小的启动器链接脚本替换安装器。**这样可以简化设置过程，但仓库仍需负责修改宿主 PATH 和管理启动器归属。源码脚本无需引入这类状态即可提供入口点。
影响
源码用户通过仓库脚本运行程序，而非使用已安装的 dsh 命令。仓库不提供原子升级切换，也不保留 staging 回滚检出；仓库同样不会自动集成个人源码修改或将其发布到上游。未来的分发机制必须说明为何应由其管理安装和升级状态，定义恢复行为，并补充测试与用户文档，同时不得让源码运行路径依赖该机制。未来任何发布工作流都必须隔离出一项获批功能，并在首次推送和创建草稿 PR（Pull Request）前取得明确批准。
验证范围包括仓库内对已移除入口点的所有引用、文档链接、生成的第三方声明文件的新鲜度、package.json 中的直接源码启动命令，以及通过准确的 node --import tsx/esm 运行方式对源码 CLI 进行的冒烟测试。