前言¶
DeepSeek Harness（DSH）生态里插件数量已经很大，社区维护的 dsh-plugin 精选目录在 2026-10-04 时收录了 4,412 条条目。每条有分类、一行描述、install 命令、星标与下载量，以及注册表对源码检查得到的十种能力标记和 red line 提示。实际选插件时，常见做法是按关键词搜目录、看星标、逐个打开页面——很难系统回答「DevOps 栈还缺哪一类角色」「这个 pick 为什么会上榜」「装之前要重点看哪些能力」。dsh-stack-composer（GitHub：Tim-ReJet/dsh-stack-composer）把「用途 → 角色 → 对全目录打分 → 报告 + 安装命令」做成只读工作流：不替你安装，也不改被评估的插件，只在 DSH 侧写自己的注册表缓存和可选的 --out 输出。
这是什么¶
维护者 Tim-ReJet，在 SkillHub 等社区目录中分类为工作流。插件一句话定位：根据你声明的用途（例如「一套完整的 DevOps 栈」或「单人 YouTube 频道的内容创作栈」），推断栈需要的角色，用目录里的分类、描述、能力标记与 red line 对每条插件逐角色打分，返回入选插件、打分理由、风险、填不满的缺口，以及每个插件一条安装命令。它不拉取任何插件源码；能力标记表示注册表当时检查到的行为，缺标记只表示「未观察到」，不等于安全。
核心功能¶
推理依据¶
注册表条目侧：分类、描述、install、星标/下载、十种能力（fs-read、fs-write、env、network、llm、shell、dynamic-code、host-runtime、credentials、subagent）及 red line。插件侧不抓源码。
从用途到栈¶
- 用途 → 角色：内置 23 个角色（版本控制、容器、密钥、可观测、告警、采集、发布、记忆、编排等）。若用途匹配 8 个预设之一，采用该预设的角色集；否则按用途命中各角色关键词的数量选角色，并用通用角色补全，避免空栈。
- 全目录 × 全角色打分：加分减分可解释，每条贡献会印在报告里。信号与权重（摘自 README）：
| 信号 | 权重 |
|---|---|
| 分类名与角色名一致 | +6 |
| 插件名中最多 2 个角色关键词 | 每个 +5 |
| 描述中最多 3 个角色关键词 | 每个 +2 |
| 角色需要且已声明的能力 | +2 |
| 角色需要但未声明的能力 | −1 |
| 最多 2 段「明显是别的活」片段 | 每段 −4 |
| 热度 | min(2, log₁₀(stars+1) + log₁₀(downloads+1)/2) |
- 阈值：某角色得分 ≥6 视为填满；3–6 为宽松匹配；<3 记为 gap，并给出最接近的候选。热度最多 +2，低于宽松匹配门槛，不能单靠星标把角色凑满，报告也不会为了「看起来完整」硬凑插件。
- 组装：同一插件只选一次；风险来自注册表 red line；报告汇总能力并集、安装前值得复核的能力标记，以及每个插件一条
install命令。
会话工具与 CLI¶
在已 compose 该插件的 DSH 会话中：
stack_compose：purpose（必填），可选perRole、refresh。返回栈、角色与计数及完整报告。plugin_capabilities：query（必填），可选limit、category、capability。用于装前查单个/一类插件的能力、red line、安装命令与目录页。
命令行与引擎一致，例如：
dsh-stack-composer "a fully equipped DevOps stack" --per-role 2
dsh-stack-composer "a content creation stack" --json > stack.json
dsh-stack-composer --capabilities "browser automation" --limit 5
dsh-stack-composer --capabilities "secrets" --capability credentials
dsh-stack-composer --presets
dsh-stack-composer --roles
常用参数：--per-role（每角色推荐数，默认 2，1–8）、--refresh（重新拉注册表）、--offline（仅用缓存）、--registry（本地文件或 URL）、--json、--out。成功退出码 0，用法或注册表不可读为 2。
配置项¶
通过 cordis.patch.yml 注入 stack-composer 行，可设 perRole、registryUrl、registryPath（本地快照，测试或离线）、offline。本地开发可在 overlay 里把 name 指到 checkout 的 src/index.js 并设 perRole 等（见仓库 README）。
安装与启用¶
当前包尚未发布到 npm，从仓库安装：
dsh plugin --profile web add github:Tim-ReJet/dsh-stack-composer
发布后 README 给出的短形式为：
dsh plugin --profile web add dsh-stack-composer
确认层已加载：
dsh --profile web --dump-config | grep -A 5 stack-composer
运行环境：package.json 要求 Node.js >= 20；版本 0.1.0，许可证 MIT。GitHub 星标数为 0（以目录页线索为准）。
典型用法¶
CLI：按预设用途出报告
下面命令对 DevOps 预设每个角色只列 1 个插件，便于快速浏览（README 示例）：
dsh-stack-composer "a fully equipped DevOps stack" --per-role 1
输出包含 preset 名、角色数、插件数、注册表条目数与更新时间，以及每个角色下的插件、得分、why 理由、能力摘要和 install 行；末尾有 risk notes（例如某 vault 类插件同时读凭证与联网）。
会话：自然语言组合栈并查凭证类能力
在会话中可以类似这样用（README 建议）：「Compose a security review stack and tell me which picks read credentials.」——先 stack_compose 再对照报告里的 credentials 与 risk notes。
装前能力检索
dsh-stack-composer --capabilities "secrets" --capability credentials
仓库在 samples/ 提交了从线上注册表生成的 DevOps 与 content creation 两份样例报告，可用 npm run check:live 重新生成。
适用场景与注意¶
适合谁：需要从零或从模糊目标（「研究栈」「内容创作栈」）快速得到可解释的插件短名单与安装命令的 DSH 用户；希望在同一流程里看到缺口和注册表 red line，而不是只看排序列表的人。
只读边界：不安装报告中的插件，也不检测多个 pick 是否冲突。网络方面：除非需要注册表，否则不发起请求；注册表按 URL 缓存在 DSH home，一日缓存，--refresh 可强制更新。
评分与数据的局限（README「Limits」）：角色与关键词在 src/roles.js，误匹配可在该文件修词表，报告会打印每条 pick 的理由。2026-10-04 时 4,412 条中有 394 条无能力检查数据，报告会区分「注册表未检查」与「未声明」。这不是质量排行榜：进目录本身是主要质量信号，星标/下载只作 tie-break。
安装前必做：DSH 插件以当前 dsh 进程权限运行。composer 只读目录元数据，你按报告执行的 install 会真正加入插件——安装每条 pick 前仍应阅读其源码、许可证与能力声明，并对照本机安全策略；不要仅凭分数自动全装。
结尾¶
dsh-stack-composer 把「用途 → 23 角色 / 8 预设 → 对 4k+ 目录条目可解释打分 → 缺口与风险并列输出」固定成工作流插件，适合在扩栈前先规划再逐条人工确认。社区目录页：SkillHub - dsh-stack-composer；源码与完整说明：GitHub - Tim-ReJet/dsh-stack-composer。
