@ziduup/dsh-programming-mode

dsh plugin --profile web add @ziduup/dsh-programming-mode

dsh-programming-mode

  

[English](README.en.md) · 中文

编程模式：一个 DeepSeek Harness 组合包（bundle），在标准模式的全部能力之上强制执行 Superpowers 工程纪律。一条命令即可安装。

0.4.0 起支持 dsh 0.2.0 桌面版（0.3.8 及更早只支持 0.1.x CLI / web profile）；同一个包、同一份组合，安装器按宿主模型自动选通道。

目录

• [这是什么](#这是什么)
• [编程专家面板](#编程专家面板)
• [安装](#安装)
• [升级行为](#升级行为)
• [卸载](#卸载)
• [安全与信任](#安全与信任)
• [自行构建](#自行构建)
• [作者与许可](#作者与许可)

这是什么

编程模式 = 部署自带 standard 模式的全部能力 + 强制 Superpowers 工程纪律的人设：

1. 行动前先查技能（using-superpowers）

2. 创作前先头脑风暴（brainstorming），设计批准后才实现

3. 多步任务先写计划（writing-plans → executing-plans）

4. 实现走 TDD 红绿重构（test-driven-development）

5. 调试先找根因（systematic-debugging）

6. 完成前必须跑验证（verification-before-completion）

7. 重要工作请求代码审查（requesting / receiving-code-review）

8. 需求文档与开发计划一律用中文撰写

9. 首条消息强制注入 using-superpowers：新会话的第一条请求前自动注入技能全文，纪律从第一句就生效

10. 代码量纪律（Ponytail）常驻：默认 full 强度，7 级阶梯（YAGNI → 复用 → stdlib → 原生 → 已有依赖 → 一行 → 最少可用）始终生效；只管实现代码量，不触碰上面的流程规则（测试 / 计划 / 验证 / 审查归 Superpowers），用户可说 "ponytail lite/ultra" 或 "停止 ponytail" 调整

本包捆绑了全部 21 个所需技能，安装即用、无需自备技能。

技能归属：捆绑的 21 个技能中，15 个源自 Superpowers 方法论（MIT），6 个源自 Ponytail（MIT），署名声明见 preset/programming/skills/SKILLS-LICENSE.md。

编程专家面板

进入编程模式会话时，默认在右下角浮出一块可拖动的面板，里面是六位编程专家。点头像 = 把对应技能的调用命令追加进当前输入框，不自动发送：

头像 · 专家 · 插入的命令

问 · 需求拷问者 · /brainstorming

计 · 计划制定者 · /writing-plans

测 · TDD 践行者 · /test-driven-development

排 · 排错专家 · /systematic-debugging

简 · 极简主义者 · /ponytail

验 · 交付前验证员 · /verification-before-completion

• 只追加，不清空：草稿里已经有字时，命令另起一行接在后面。
• 只在编程模式下插入：技能注册在编程模式的 preset 层，标准模式读不到，所以标准模式会话里点头像只提示、不插入。
• 面板和 ✦ 在任何模式下都在：切会话、切模式都不会把面板关掉，只有你自己点 × / 按 Esc 才会关。
• 关掉就关掉：点 × / 按 Esc 关掉之后不再自动弹，输入框右侧的 ✦ 可以随时叫回来。
• 位置会记住：拖动后的位置与开合状态存在本地，刷新后保持。

安装

安装命令只有一种形态：dsh plugin --profile <profile> add <来源>。dsh 在这里是 pnpm 的转发层——它初始化 profile、在 profile 目录里跑 pnpm，再把声明了 dsh.bundle 的依赖并入 dsh.profile.bundles 层栈。没有单独的 npm install 步骤：所谓「npm 渠道」指的是包从 npm registry 解析，和 GitHub、本地 tarball 只是来源不同。包页：npmjs.com/package/@ziduup/dsh-programming-mode。

# 来源 1：npm registry（推荐，registry 通道更稳）
dsh plugin --profile web add @ziduup/dsh-programming-mode

# 来源 2：GitHub（git 直装）
dsh plugin --profile web add github:ziduup/dsh-programming-mode

# 来源 3：本地目录 / tarball
dsh plugin --profile web add ./dsh-programming-mode
dsh plugin --profile web add ./dsh-programming-mode-<版本>.tgz

dsh 0.2.0 桌面版（0.4.0 起支持）：在应用内的插件市场搜索 dsh-programming-mode 安装。桌面 profile 由桌面版独占管理，CLI 会拒绝：profile "desktop" is managed exclusively by the Electron application。

0.5.0 要求 dsh ≥ 0.2.1-rc.5：客户端半边依赖 captureInsertion/insertText，这两个在 0.1.x 上没有。还停在 dsh 0.1.x 的请留在 0.4.1。

手工装的话注意只做了一半：cd ~/.dsh/profiles/web && pnpm add @ziduup/dsh-programming-mode 会把包装进 node_modules，但不会更新 dsh.profile.bundles，模式因此不会出现——这一步调和只有 dsh plugin add 会做。

安装后重启该 profile，模式选择器里即出现 编程模式。dsh 0.2.0 桌面版可能需要重启两次：第一次启动只是把 preset 写成一条声明行，模式选择器要等下一次启动才读得到。

重启后仍看不到时，先分清「没登记」和「登记了但被判 broken」：0.2.0 的选择器不列激活失败的 preset，而激活失败最常见的原因是组合里的某一行解析到了 0.1.x 的旧包、被宿主按 peer 不兼容禁用——它本该提供的服务就永远缺席（例如引擎行缺失会让工作流工具一直等待下去）。0.4.0 起，声明行里的行漂移已按同版本内核的 dsh-web-app/presets/standard.patch.yml 校正（workflow-ptc、tool-ralph 禁用、tool-plugin-manager）；自定义组合时请以该文件为准做同样对照。

模式能选、但一选中就报 本轮运行失败：format v4 message requires a producer-owned source kind，那是 0.3.8 及更早版本的首步注入 source 与 0.2.0 的日志格式 v4 冲突：v4 只承认「生产者自有」的 kind，而 kind: 'plugin' 这一退役形状在写入和读取两条路径上都会被硬拒。0.4.0 起改用宿主自己的 skill-invocation 形状（与 skill 工具注入 <skill_content> 时同款），v0–v4 各代校验器都放行；升到 0.4.0 后新开的会话即可正常运行，已有的旧日志不受影响。

升级行为

安装后在 profile 启动时，本包按宿主模型二选一落地 preset：

宿主 · 发现方式 · 落地内容

dsh 0.1.x · 扫 preset 目录 · 把捆绑 preset 植入 roster 第一个用户根（默认 $DSH_HOME/.agent-presets/）

dsh 0.2.0+ · 读 profile patch 里的声明行 · 植入同一个目录，并在所在 profile 的 cordis.patch.yml 里写一条标记块包住的 - insert: 声明行

0.2.0 起宿主不再读 preset 目录（dsh-agent-preset-registry 只认 AgentPresets.register() 登记的条目），所以目录植入对桌面版不够用——这是「装完看不到编程模式」的原因。两条通道共用同一份 agent.cordis.yml（声明行的 plugins 就是它整块右移 10 空格），不存两份副本。

按宿主判断写入策略（目标目录那一侧按版本戳）：

目标目录状态 · 行为

不存在 · 全新植入，写入版本戳

版本戳 == 本包版本 · 无操作（保留你的本地修改）

版本戳 != 本包版本 · 覆盖文件并刷新版本戳（升级）

存在但无版本戳 · 拒绝触碰（不是我们植入的，可能是你手写的同名 preset）

声明行那一侧同样是「没有块才追加 / 同版本不动 / 不同版本只换块」，你的其他 patch 行一个字都不会被改写。声明行不引用本包名，只引用宿主自带包和我们植入的文件（file:///… 绝对定位）——这是卸载后它还能继续激活的前提。

植入副本是自包含的：本包对 preset 的唯一注入点 force-superpowers 行挂载 preset 目录内的相对模块 ./force-superpowers.mjs，不依赖本包名（也不会 import 本包），不会出现"悬空引用导致会话无法 resume"。

卸载

# dsh CLI / 0.1.x 宿主
dsh plugin --profile web remove @ziduup/dsh-programming-mode

# dsh 0.2.0 桌面版：在应用内的插件市场点卸载（桌面 profile 由桌面版独占，CLI 不能代卸）

卸载分两段，各有一个已知边界：

第一段（dsh 侧）：卸载后 bundles 列表可能悬空。 dsh plugin remove（CLI 路径，0.3.8 实测）会把依赖、node_modules、lockfile 和 dsh.profile.bundles 一起清干净，启动正常；但部分卸载路径不保证清 bundles——本机实测出现过一次卸载后 bundles 条目悬空（依赖已清、列表未清），下一次启动直接报错 cannot resolve profile bundle "@ziduup/dsh-programming-mode" 且整个 profile 拒绝启动。遇到该报错，手动删掉 profile package.json 里 dsh.profile.bundles 数组的那一行即可（只删这一行）。

第二段（本插件）：卸载后的自动结算。 pnpm 不执行被卸载包的任何生命周期钩子，市场也没有卸载事件，因此清理由植入的 preset 自己完成——你点卸载就够了，不需要任何手动收尾。触发时机按宿主持久化通道而不同：

• dsh 0.2.0+：声明行在 profile patch 里，随每次启动激活，所以「卸载 → 重启 → 结算完成」，不需要再开会话。
• dsh 0.1.x：preset 是按会话懒挂载的，只有模式选择器被打开、或 resume 旧会话时才会激活，并不是每次启动都触发。

结算分两半，各自判断：

…(truncated)