DSH 插件脚手架

问题

DSH 插件开发常卡在形态选择、构建验证和发布回滚之间：先写了 src/，才发现该用 pure、bundle 还是 bundle-client；本地能跑，发布后却出现 plugin tree failed to load 或 slot entry crashed。这类问题往往不是单点 API 不熟，而是缺少从目标、能力面到最终安装验证的一致约束。

工作方式

这个技能把 DSH 插件开发拆成 7 个阶段，每个阶段都有明确产出和决策门：

• 阶段 0：明确目标与能力面。先确定插件名、一句话目标、能力面（工具、服务、HTTP 路由、浏览器 UI、根布局、skill、MCP、静态资源等）和目标 profile，默认 web。
• 阶段 1：选择形态。按能力面选择 --kind pure、bundle 或 bundle-client，同时确定分发方式和包管理器。若需接管默认 web shell 根布局，由实现阶段注册 ctx.slots.register({ name: 'root' })。
• 阶段 2：生成脚手架。运行脚手架后进入目录验证骨架可用，并把阶段 0/1 的决策写入 docs/plugin-plan.md。
• 阶段 3：实现业务。只按既定形态生成 src/index.ts 或 src/client/index.ts；注册工具、路由、服务或事件时使用 ctx.effect() 并返回 cleanup；不要手改 lib/，每次改 src/ 后运行 pnpm run bundle。
• 阶段 4：本地验证。按顺序做构建、门禁、包内容、安装冒烟和浏览器验证；业务错误回到实现阶段，形态或合同错误才回到形态选择。
• 阶段 5/6：发布准备与最终验证。初始化真实 git remote、替换 README 占位 ref、提交 lib/ 产物、补 UI 截图，再根据分发方式执行 git push 或 npm publish，最后必须从最终分发源重装并重启 web，确认无加载失败、无 slot 崩溃、功能符合目标。

适用边界

• 适合需要按 DSH 合同、Cordis 构建和 web shell 分发模型开发插件的工程场景。
• 如果只是排查某个局部问题，例如“为什么挂载失败”，不必重跑全流程，直接查看 references/ 中的合同、坑位或验证章节即可。
• 该流程强调决策门：能力面没列全、形态未确定、骨架未验证、本地冒烟未通过，都不要直接进入下一阶段。