插件即地基：
DSH 插件体系与服务器农场自动化

一、挂载形而上学：patch 即契约

DSH 的插件没有安装仪式。一个插件 = 一个 index.js + 一段 patch 声明，写进机器级的 ~/.dsh/cordis.patch.yml（insert 一个 id，name 指向脚本绝对路径），即对所有 profile 全局生效——无需 npm install，无需构建，改配置文件即可运行时重读。媒体流水线插件正是这样挂载的。这种设计的深意在于：扩展运行时不需要修改运行时。补丁（patch）不是入侵，是运行时预留的契约接口——它承认没有哪个核心能预见所有需求，于是把「预见」外包给了器官。

二、五个器官的病例切片

2.1 FTP 发布插件：无依赖主义的胜利

整站发布器最反直觉的决定是零第三方依赖：FTP 协议的 PASV 协商、STOR 上传、LIST 解析、UTF-8 控制通道与二进制数据通道分离，全部手写。收益是双重的——部署面缩小到一个 JS 文件；且每个字节都在自己的掌控里（中文文件名损毁的修复正是靠这层细粒度控制）。它提供三种发布模式与一次预演：full 整站、incremental 差量、paths 指定文件；dry_run=true 只预览不动手——「先看差异，再上传」被做成了协议级默认。

2.2 服务器农场：把运维变成问答

农场插件把三台服务器（10.28.10.232–234）抽象成四个动词：看（status/refresh）、问（exec）、装（install）、传（upload）。探测是 SSH 实采而非缓存神话；安装是 job 化的异步任务（逐包状态、输出尾部可查）；一键 bundle（bs-standard）把「BS 业务系统标准环境」压缩成一个名词。运维的语法由此从「命令行记忆」退化为「对话」。

2.3 反向隧道：对一台够不着的机器的谦逊

那台 Windows 机器不开放 22 端口，传统 SSH 思路在此失效。隧道的答案是反转方向：让 Windows 侧主动拨入，本机只维护转发端口。一条引导命令（粘贴进 PowerShell 即装 Agent）完成接入——不碰防火墙，不留开放面。这是对网络现实的一次漂亮让步：不是所有墙都能推倒，但所有内网机器都会自己出来找你，只要你先在墙上开一个它认得的口。

三、器官学的边界

插件体系并非没有代价。本刊档案里留着一条教训：插件新版本通过独立 Node 测试后，正在运行的会话仍缓存旧模块——paths 模式要等 DSH 重启才生效。器官可以移植，但受体有排异期。这条限制后来被写进插件文档的「已知限制」一节——诚实记录局限，与实现功能同样重要。