dsh-plugin-guide 0.3.41 → 0.4.0

package/guide/when-to-retire-a-plugin.md

@@ -1,127 +0,0 @@
-# How I decide whether a DSH plugin should keep being maintained
-
-> Chinese: [when-to-retire-a-plugin.zh-CN.md](when-to-retire-a-plugin.zh-CN.md)
-
-## 0. What I did, and why it is public
-
-On 2026-10-05 I pulled the whole DSH plugin ecosystem from npm — **324 real plugins** — and benchmarked every plugin I publish against its rivals on the same capability surface, by weekly downloads. The outcome: **3 retired, 7 frozen, 1 reclassified**. I am publishing the criteria because "should this keep going" is a question every plugin author meets, and most meet it without data.
-
-## 1. The criteria
-
-One thing first: **this is not a purge, it is a self-audit.** The official project is not eliminating third-party plugins — `CONTRIBUTING.md:19` says plainly that packages in the official repository are not inherently more important than community packages, and that the official showcase is "an idea, an official showcase, and a source of inspiration, but **not a mandate from us**". The pressure comes from other third-party authors. Section 3 shows the data.
-
-**Two hard criteria.**
-
-**Hard criterion A: the same capability has been taken into the host's core.** Wording matters. Not "the official repo has a package with a similar name", but "the official composition **mounts it by default**", or "the official project has made it a **first-class subsystem**". The gap between those two readings is the single easiest mistake to make in this kind of review.
-
-**Hard criterion B: on the same capability surface, a third party has a significantly better-adopted implementation.** "Significantly" means one order of magnitude. Any such comparison is only valid as a **relative** magnitude inside one ecosystem, never as an absolute number.
-
-**One soft criterion.**
-
-**Soft criterion C: maintenance cost versus real usage.** This one is easy to misuse. My own Web profile now runs the stock bundle set and installs none of the family's plugins. So "do I still use it" cannot be the criterion — for me these repositories are **published artifacts**, not **personal tools**. The two questions that can be criteria are: **does anyone out there still need this**, and **is this maintenance cost still worth paying**.
-
-**One meta-rule.**
-
-**Only file-level evidence counts.** Every conclusion has to point at a specific file, a specific line, or a specific npm / GitHub API reading. Anything that cannot is marked "unverified" and stays out of the decision. This rule corrected four of my own starting premises this round, two of them directly about whether the official project has a capability at all — one where it does and simply does not mount it, and one where it does mount it and I had assumed otherwise.
-
-**Three dispositions.**
-
-| Disposition | Count | Packages | Meaning |
-|---|---|---|---|
-| 🪦 **Retired** | 3 | `dsh-background-agents`, `dsh-session-pin`, `dsh-team-rooms` | **Compatibility updates stop**: RETIRED banner at the top of the README, npm `deprecate` applied, GitHub repository archived (read-only) |
-| 🧊 **Frozen** | 6 | `dsh-budget`, `dsh-draw`, `dsh-claude-move`, `dsh-reach`, `dsh-wechat`, `dsh-defend` | **No new features — but still working and not deprecated**; only genuine breakage gets fixed |
-| ✅ **Reclassified** | 1 | `dsh-catalog` | First judged as a retirement; after review, kept: it is an internal family tool and does not compete with third-party catalogs. **Still maintained** |
-
-Two earlier corridor packages, `dsh-plugin-upgrade-015` (stopped at npm `0.1.1`) and `dsh-plugin-upgrade-016` (never published), are also retired; plugin upgrades continue through the single `dsh-plugin-upgrade` line.
-
-## 2. The data, part one: the 3 retirements
-
-This tier used hard criterion A almost exclusively.
-
-| Package | Official counterpart | Why it was judged retired |
-|---|---|---|
-| `dsh-background-agents` | `tool-subagent` (`backgroundMode: continuable`) + `tool-subagent-control` + `tool-jobs` | The official composition **mounts it by default**. And the package's **own README already said so**: the background-agent half is *superseded by DSH's native continuable subagents* |
-| `dsh-session-pin` | the `client-ui-workspace` pin action | Mounted **by default**: the session context menu has `Pin session`, rows have a hover pin button, pins can be reordered by dragging inside the pinned block, and the host persists `pinnedSessionIds` and broadcasts `pinned` delta frames. What is left for the plugin is appearance work — row colours, a pinned panel, a header toggle |
-| `dsh-team-rooms` | `dsh-experimental-agent-team` | The official project turned "teams" into a **first-class subsystem**: an implicit root roster, a persistent mailbox (offline members receive mail on return, with de-duplication), a shared task DAG (compare-and-swap against overwrites, dependency unlocking, file-write conflict warnings), `wait_agent`. It **also** satisfies hard criterion B: its own weekly downloads are **589 — the lowest in the family**, while `@nanmicoder/dsh-agent-teams` sits at **13,273 (22×)** |
-
-One honest qualification on `dsh-team-rooms`: the official `dsh-experimental-agent-team` is **optional**, `disabled` by default in base, and enabling it **requires disabling** `send_message` / `interrupt_agent` / `list_agents`. So this is not a "mounted by default" supersession. It entering the core, plus the third-party 22× adoption, is what makes the case.
-
-One unflattering number I am leaving in: after the host shipped a built-in pin, `dsh-session-pin` **still had 1,015 weekly downloads**. The report offers two readings — appearance enhancements are genuinely wanted, or the download metric carries noise. I cannot separate the two with the data I have, so I retired it on the criteria and left the number standing here.
-
-## 3. The data, part two: the 7 freezes — the multiplier table
-
-Measured 2026-10-05 from the npm registry API. **On method first**: npm weekly downloads are **not** user counts (they include CI, mirrors and repeated installs), so the table below is used purely for the **relative** magnitude between packages, never as an absolute figure.
-
-| Capability surface | My package (weekly downloads) | Third-party rival on the same surface (weekly downloads) | Multiplier | Where the rival is stronger |
-|---|---|---|---|---|
-| Cost / usage metering | `dsh-budget` 1,079 | **`dsh-cost-meter` 33,526** | **31×** | 170+ model price entries and quota lookups for 11 coding plans |
-| Cross-session memory | `dsh-memento` 1,202 | **`@openviking/dsh-memory-plugin` 10,160** | **8×** | An official organisation repository from ByteDance volcengine — company-level resourcing |
-| IM bridging | `dsh-reach` ~0.6k / `dsh-wechat` 752 | **`@xmanrui/dsh-im` 17,384** | **23×** | One package covers 10 channels (WeChat / Feishu / WeCom / DingTalk / QQ / Telegram / WhatsApp / Slack / Discord / Matrix) |
-| Injection and destructive-command defence | `dsh-defend` 937 | **`cc-safety-net` 13,087** | **14×** | Blocks destructive commands and secret-file access directly as a coding-agent CLI hook — a short adoption path and a wide audience |
-| Image generation | `dsh-draw` 973 | **`dsh-image-gen` 7,216** | **7×** | Multi-provider |
-| Session / configuration migration | `dsh-claude-move` 843 | **`dsh-chat-import` 5,111** | **6×** | Covers 25+ AI coding agents |
-
-**Four background readings.**
-
-- **The size of the field.** Two keywords intersected: 8,620 hits, 772 candidates, and after checking the `dsh` field package by package, **324 genuine plugins**. (A note on scope: this counts **only packages on npm that declare a `dsh` manifest and can actually be installed with `dsh plugin add`**. Community directory sites publish much larger entry counts, because they also count GitHub repositories, sub-directories and unpublished candidates. The two figures should not be quoted against each other, and must not be added together.)
-- **This is not an isolated case.** **Of 16 capability surfaces, my packages are not first on 14**, most of them behind by **3–31×**. The widest gap is on context insight: `dsh-fast` 917 against `dsh-context` 38,999 (**43×**).
-- **First in the family is not first on the surface.** `dsh-mcp-panel` at 2,472 is the family's top package, but `dsh-mcp-connector` on the same surface is 7,556 (3×).
-- **Nothing here was abandoned.** Before this review, every affected repository had been pushed on 2026-10-05 itself. The retirements and freezes are a **deliberate judgement**, not a cleanup of dead projects.
-
-**Why these seven?** They satisfy two things at once: the rival is not merely better-adopted but **broader in capability** (multi-provider, multi-channel, multi-agent, or organisation-backed); and further investment from me on that surface is unlikely to produce something only I can provide.
-
-Two counter-examples have to travel with the criteria, or they collapse into "behind means retire":
-
-- **`dsh-fast` (917 against `dsh-context` 38,999, 43×) stays as it is.** It is a lightweight package with a low maintenance cost; freezing it would save very little. **Being behind is not a criterion.**
-- **Hard criterion B alone can be enough, with hard criterion A failing.** For `dsh-draw` the official counterpart is **zero** (`text-to-image` / `image_gen` / `txt2img` have 0 hits across the host repository), and the same is true for `dsh-memento` (there is no memory seam in the official `capability-seams.md`, and `docs/user/guide/mcp-memory.md:5,31` states outright that **no memory server is present in the shipped composition**). **"The official project does not do this" does not mean "I should keep investing"** — the memory surface has at least 10 rivals, and `dsh-memento` sits around 8th.
-
-## 4. Where I am still first
-
-Listing only the losing half would be misleading. This is the contemporaneous "still only me" list (2026-10-05):
-
-| Capability surface | My packages (weekly downloads) | Status |
-|---|---|---|
-| LSP action surface | `dsh-lsp-actions` **1,170** | **No strong rival anywhere in the ecosystem.** The official LSP **deliberately excludes** rename / formatting / diagnostics / symbol lists |
-| Plugin certification, health checks, scoring | `dsh-plugin-doctor` 218, `dsh-score`, `dsh-test-drive`, `dsh-plugin-certification` | **No rival.** The ecosystem only has `dsh-why` (137) and `dsh-fix` (1,503) — tools that repair a broken plugin, not a scoring system |
-| Research / report engines | `dsh-research-report` 1,019, `dsh-industry-research` 926, `dsh-fund-research` 802 | **Essentially unrivaled** (vertical domains) |
-| Data quality | `dsh-data-quality` 769 | Only `dsh-data-cleaning-agent` comes close |
-| Declarative permissions + network policy | `dsh-permission-rules` **1,459** | `dsh-perm-gate` is **slightly higher** at 1,851 (the report marks this row "rival marginally ahead"), but its **process-level HTTP / CONNECT proxy network policy** has not been replicated by anyone |
-| GitHub CI automation | `dsh-github` 359 | No rival (also the lowest, but genuinely nobody else is doing it) |
-
-Two cross-checks:
-
-- **The star leader is not the flagship security plugin — it is the research line.** `dsh-research-report` (215★) and `dsh-industry-research` (212★) are both above `dsh-memento` (139★), `dsh-permission-rules` (118★) and `dsh-mcp-panel` (75★).
-- **"The official project lacks it" and "a third party has not built it" are two independent facts.** The report confirms at least eight surfaces where the official project is still at zero (`dsh-defend`, `dsh-mask`, `dsh-budget`, `dsh-draw`, `dsh-translate`, `dsh-library`, `dsh-autotier`, the `dsh-plugin-*` toolchain). Some of those have been taken by third parties; some are still empty. **An empty space is not a moat. Nobody doing it, and me being able to do it well, is a moat.**
-
-## 5. "Frozen" does not mean "deprecated"
-
-This section is for users.
-
-| Status | Will the package be deleted or unpublished? | Will bugs still be fixed? | npm state | Repository state |
-|---|---|---|---|---|
-| 🪦 **Retired** (3) | No | **No** — including compatibility updates | `deprecate` applied | Archived, read-only |
-| 🧊 **Frozen** (6) | No | **Yes** — but only a minimal compatibility fix, and only when a breaking host change makes the package completely unusable | Normal, **not** deprecated | Normal, **not** archived |
-| Everything else | No | Yes | Normal | Normal |
-
-**If you have one installed, there is nothing you need to do.** The frozen packages install and run exactly as before: no interface changes, no versions pulled. The only thing that would require action is a host upgrade that actually breaks one — in that case, please open an issue and I will fix it. **If what you want is new features, please use the rivals named in the section 3 table.** Every one of them is significantly better adopted on its surface, and that is precisely why the package was frozen.
-
-**Why not express this by deleting packages?** Because deleting them means the next person cannot find the package, and cannot find the reason it was retired either. So the family tables **keep every row and only add a status note**: retired and frozen repositories stay listed in every family table with a `🚫 RETIRED` / `🧊 FROZEN` status column, and their original descriptions are left untouched.
-
-## 6. Eight self-check questions for other plugin authors
-
-1. **Does the official project "have a package", or "mount it by default"?** The official `experimental/*`, `computer-use`, `browser-use`, `lsp` and `speech-to-text` packages are **not in the stock composition**. "The official project has a package" is not "the user gets the capability on install".
-2. **Does a line in `base` mean the user has the capability?** Not necessarily. The Web patch **disables the base process-level model-facing tool rows one by one** and hands them to each agent preset to remount. Reading only `base/cordis.patch.yml` produces a systematically over-optimistic answer.
-3. **Did you search for rivals by capability keyword, or by package name?** Comparing names alone misses every rival: `dsh-cost-meter` and `dsh-budget` share no name at all, and neither do `cc-safety-net` and `dsh-defend`.
-4. **Does the same name mean the same thing?** The official `dsh-experimental-auto-review` and `dsh-auto-review` share a name but invert the security model: the official one reviews with the current agent's own provider/model and says of itself that it *can allow unsafe actions, deny useful work, and spend additional tokens*, with no deterministic exemptions and no persistent grants; mine is an independent read-only second-model reviewer that **fails closed**. That is not a supersession.
-5. **Can a second signal corroborate your download count?** `dsh-budget` has 1,079 weekly downloads and **10 stars** — high downloads look like CI and mirror noise, while low stars look like real appeal. In the other direction, `dsh-auto-review` carries **10 open issues**, which is what real use and real bug reports look like. Download counts alone mislead.
-6. **Is "do I still use it" your criterion?** If you no longer use it, it should not be (my own Web profile runs the stock bundle set today). Replace it with two questions: **does anyone out there still need this, and is the maintenance cost still worth it?**
-7. **How far behind do you have to be?** There is no threshold. `dsh-fast` is 43× behind and stays as it is; `dsh-defend` is 14× behind and is frozen. The price of freezing is admitting you are no longer the best choice on that surface, so it is only worth paying for packages where further investment will not produce anything distinctive.
-8. **Is your decision written into the README?** A decision that lives only in your head, or only in an internal report, does not exist. Each frozen package carries a `## Maintenance status: 🧊 FROZEN` section with the measured comparison table and a note on where the rival is stronger (six, each carrying a `status` of `frozen` in `dsh-plugin-kit/data/repos.json`); each of the three retired packages carries a RETIRED banner at the top of its README. **At a minimum, users should be able to learn from the README why you stopped.**
-
-## 7. Statement of fact
-
-- **The family today**: the family tables list **44 plugin repositories** (45 rows in the tables that include `dsh-plugin-upgrade-015`), of which 🚫 **3 are retired** and 🧊 **6 are frozen**; the rest are maintained as active repositories. Licensing is predominantly Apache-2.0.
-- **Where the repositories are**: https://github.com/PerryLink
-- **Measurement date**: 2026-10-05, from that self-audit — a full npm registry pull, live GitHub REST API measurements, and file-by-file evidence from the host source tree. **The conclusions are checkable**: each one points at a specific file or a specific API reading, and anything that could not was marked "unverified".
-
-One last line, for anyone who might want to take something over: **`dsh-reach` and `dsh-wechat`, the two IM bridging lines, are open for a new maintainer.** The reason they are frozen is specific — `@xmanrui/dsh-im` covers 10 channels in a single package, and that is a better job than mine. If those two lines are useful to you and you want them to keep growing, both repositories carry permissive licences (`dsh-reach` is Apache-2.0, `dsh-wechat` is MIT); please open an issue and we can talk about the handover.

package/guide/when-to-retire-a-plugin.zh-CN.md

@@ -1,127 +0,0 @@
-# DSH 插件生态实测：我怎么判断一个插件该不该继续做
-
-> English: [when-to-retire-a-plugin.md](when-to-retire-a-plugin.md)
-
-## 0. 我做了什么，为什么公开
-
-2026-10-05，我把 npm 上的 DSH 生态全量拉了一遍（324 个真插件），把自己每个插件与同赛道对手比了周下载量：**3 个退役、7 个冻结、1 个改判**。公开判据，是因为「该不该继续维护」人人都会遇到，却大多无数据可依。
-
-## 1. 判据
-
-先讲清楚一件事：**这不是一次清理门户，是一次自我审计。** 官方没有要淘汰第三方插件——宿主 `CONTRIBUTING.md:19` 说，官方仓里的包并不天然比社区包更重要；官方展示的作用是「一个想法、一次官方展示、一种灵感来源，但不是来自我们的命令」。压力来自第三方作者。这一点在第 3 节用数据说。
-
-**两条硬标准。**
-
-**硬标准 A：同一能力已被官方做进内核。** 措辞很重要。不是「官方有一个同名包」，而是「官方**默认挂载**」或「官方已把它做成**一等子系统**」。这两者的差别，是这次审查里最容易搞错的地方。
-
-**硬标准 B：同能力面上，第三方存在采用度显著更高的实现。** 「显著」量级定为「高出一个数量级」。判据只用同生态内的**相对**量级，不用绝对值。
-
-**一条软标准。**
-
-**软标准 C：维护成本 vs 真实使用者数。** 这条最容易被误用。我现在自己的 Web profile 跑的是 stock 组合，一个家族插件都不装。所以「我还用不用」不能当判据——这批仓对我来说是**发布物**，不是**自用工具**。能当判据的是两句话：**对外是否还有人需要**，和**这份维护成本是否还值**。
-
-**一条元规则。**
-
-**只承认文件级证据。** 任何结论必须能指到具体文件、具体行，或具体的 npm / GitHub API 读数；指不到的一律标「未证实」，不进决策。这条规则在本轮纠正了 4 处我原本的前提，其中两处直接关于「官方到底有没有这个能力」——一处是官方做了、只是没挂载，另一处是官方挂了、而我原以为没有。
-
-**三档处置。**
-
-| 档位 | 数量 | 包 | 含义 |
-|---|---|---|---|
-| 🪦 **退役** | 3 | `dsh-background-agents`、`dsh-session-pin`、`dsh-team-rooms` | **停止兼容性更新**：README 顶部 RETIRED 横幅、npm 已 `deprecate`、GitHub 仓已归档（只读） |
-| 🧊 **冻结** | 6 | `dsh-budget`、`dsh-draw`、`dsh-claude-move`、`dsh-reach`、`dsh-wechat`、`dsh-defend` | **不发新功能；但仍然可用、没有废弃**，只有真实故障才修 |
-| ✅ **改判** | 1 | `dsh-catalog` | 原本判退役，复核后改判：它是家族内部工具，不与第三方目录竞争，**继续维护** |
-
-另有两支早期走廊线 `dsh-plugin-upgrade-015`（停在 npm `0.1.1`）与 `dsh-plugin-upgrade-016`（从未发布）已退役；插件升级由 `dsh-plugin-upgrade` 一条线独家继续。
-
-## 2. 数据（一）：3 个退役
-
-这一档基本只用了硬标准 A。
-
-| 包 | 官方对应物 | 判定依据 |
-|---|---|---|
-| `dsh-background-agents` | `tool-subagent`（`backgroundMode: continuable`）+ `tool-subagent-control` + `tool-jobs` | 官方**默认挂载**。而且这个包**自己的 README 已经写了**：后台代理那一半 *superseded by DSH's native continuable subagents* |
-| `dsh-session-pin` | `client-ui-workspace` 的 pin action | 官方**默认挂载**：会话右键菜单有 `Pin session`、行悬停有 pin 按钮、支持在置顶块内拖拽排序、宿主侧持久化 `pinnedSessionIds` 并广播 `pinned` 增量帧。插件这边剩下的只有行颜色 / 置顶面板 / 头部总开关这类外观增强 |
-| `dsh-team-rooms` | `dsh-experimental-agent-team` | 官方把「团队」做成**一等子系统**：隐式根 roster、持久邮箱（离线成员恢复后收信、去重）、共享任务 DAG（CAS 防覆盖、依赖解锁、文件写冲突告警）、`wait_agent`。**同时**满足硬标准 B：自身周下载 **589（家族最低）**，第三方 `@nanmicoder/dsh-agent-teams` **13,273（22×）** |
-
-关于 `dsh-team-rooms` 有一处必须说清楚：官方那个 `dsh-experimental-agent-team` 是**可选项**，base 里默认 `disabled`，而且启用时**要求禁用** `send_message` / `interrupt_agent` / `list_agents`。所以它不是「默认挂载式」的覆盖。它进内核、加上第三方 22× 的采用度，两条合起来才是这条判据成立的原因。
-
-一处不好看的数据我照实写：`dsh-session-pin` 在官方内置 pin 之后**仍有 1,015 周下载**。报告给了两种解释——外观增强确实有真实需求，或者下载量口径本身有噪声。我无法从现有数据里区分这两者，所以按判据退役，但把这个数字留在这里。
-
-## 3. 数据（二）：7 个冻结 —— 倍数表
-
-采集时间 2026-10-05，来源 npm registry API。**先说口径**：npm 周下载量**不等于用户数**（含 CI、镜像、重复安装），所以下表只用**包与包之间的相对量级**，不用绝对值。
-
-| 能力面 | 我的包（周下载） | 同赛道第三方（周下载） | 倍数 | 对手强在哪 |
-|---|---|---|---|---|
-| 成本 / 用量计费 | `dsh-budget` 1,079 | **`dsh-cost-meter` 33,526** | **31×** | 170+ 模型价目、11 家 Coding Plan 额度查询 |
-| 跨会话记忆 | `dsh-memento` 1,202 | **`@openviking/dsh-memory-plugin` 10,160** | **8×** | 字节跳动 volcengine 官方组织仓，有公司级资源投入 |
-| IM 桥接 | `dsh-reach` ~0.6k ／ `dsh-wechat` 752 | **`@xmanrui/dsh-im` 17,384** | **23×** | 一个包覆盖 10 个通道（微信 / 飞书 / 企微 / 钉钉 / QQ / TG / WA / Slack / Discord / Matrix） |
-| 注入与破坏性命令防护 | `dsh-defend` 937 | **`cc-safety-net` 13,087** | **14×** | 作为 coding-agent CLI hook 直接拦破坏性命令与密钥文件访问，接入路径短、覆盖人群广 |
-| 图像生成 | `dsh-draw` 973 | **`dsh-image-gen` 7,216** | **7×** | 多供应商 |
-| 会话 / 配置迁移 | `dsh-claude-move` 843 | **`dsh-chat-import` 5,111** | **6×** | 覆盖 25+ 个 AI coding agent |
-
-**补四条背景读数。**
-
-- **生态盘子。** 两个关键词交叉取并集：8,620 条命中、772 个候选，逐个核对 `dsh` 字段确认真插件 **324 个**。（口径说明：这个数**只算 npm 上声明了 `dsh` 清单、真的能被 `dsh plugin add` 装上的包**。社区目录站公布的条目数会高得多——它们把 GitHub 仓、子目录、未发布的候选都计进去，所以两个数字不该互相引用，也不该相加。）
-- **不是个别现象。** **16 个能力面里，我的包在 14 个面上不是第一**，多数落后 **3–31 倍**；差距最大的一处在上下文洞察面：`dsh-fast` 917 对 `dsh-context` 38,999（**43×**）。
-- **家族内第一不等于赛道第一。** `dsh-mcp-panel` 2,472 是家族内第一，但同赛道 `dsh-mcp-connector` 是 7,556（3×）。
-- **没有一个是放任不管的仓。** 在这份报告之前，全部相关仓在 2026-10-05 当天都还有推送。退役和冻结是一次**主动判断**，不是清理死项目。
-
-**为什么是这 7 个？** 它们同时满足两件事：对手不只是下载量更高，而是**在能力面上做得更宽**（多供应商 / 多通道 / 多 agent / 官方组织资源）；而我在这些面上继续投入，已经不太可能产出「只有我能给」的东西。
-
-也有两个反例必须一起说，否则判据会变成「落后就退」：
-
-- **`dsh-fast`（917 对 `dsh-context` 38,999，43×）留在现状。** 它是轻量包，维护成本本就低，冻结省不下多少力气。**落后不是判据。**
-- **硬标准 A 不成立、只成立硬标准 B，也足以冻结。** `dsh-draw` 这类包，官方对应物是**零**（`text-to-image` / `image_gen` / `txt2img` 在宿主全仓 0 命中），`dsh-memento` 也一样（官方 `capability-seams.md` 里没有 memory seam，`docs/user/guide/mcp-memory.md:5,31` 明写 shipped composition 里**没有** memory server）。**「官方没做」不等于「我该继续重投」**——记忆赛道至少有 10 个对手，`dsh-memento` 大概排在第 8 位。
-
-## 4. 我在哪些面仍然第一
-
-只列输的那一半，是误导。这一节是同时期的「仍然只有我」清单（2026-10-05）：
-
-| 能力面 | 我的包（周下载） | 状态 |
-|---|---|---|
-| LSP 动作面 | `dsh-lsp-actions` **1,170** | **全生态无强力对手**。官方 LSP **刻意排除** rename / formatting / diagnostics / symbol 列表 |
-| 插件认证 / 体检 / 评分 | `dsh-plugin-doctor` 218、`dsh-score`、`dsh-test-drive`、`dsh-plugin-certification` | **无对手**。生态里只有 `dsh-why`（137）、`dsh-fix`（1,503）这类「修坏插件」，不是评分体系 |
-| 研究 / 报告引擎 | `dsh-research-report` 1,019、`dsh-industry-research` 926、`dsh-fund-research` 802 | **基本无对手**（垂直领域） |
-| 数据质量 | `dsh-data-quality` 769 | 接近的只有 `dsh-data-cleaning-agent` |
-| 声明式权限 + 网络策略 | `dsh-permission-rules` **1,459** | 下载量上 `dsh-perm-gate` 1,851 **略高**（报告原文标注为「对手略高」）；但**进程级 HTTP / CONNECT 代理网络策略**无人复制 |
-| GitHub CI 自动化 | `dsh-github` 359 | 无对手（也是最低的一个，但确实没人在做） |
-
-两条交叉验证：
-
-- **star 冠军不是旗舰安全插件，是研究线。** `dsh-research-report` 215★ 与 `dsh-industry-research` 212★ 都高于 `dsh-memento` 139★、`dsh-permission-rules` 118★、`dsh-mcp-panel` 75★。
-- **「官方没有」和「第三方没做」是两件独立的事。** 报告确认官方至今为零的面至少有 8 个（`dsh-defend`、`dsh-mask`、`dsh-budget`、`dsh-draw`、`dsh-translate`、`dsh-library`、`dsh-autotier`、`dsh-plugin-*` 工具链）——其中一部分被第三方占了，一部分还空着。**空缺本身不是护城河；没人在做、且我做得动，才是。**
-
-## 5. 「冻结」不等于「废弃」
-
-这一节是写给使用者的。
-
-| 状态 | 会删包 / 撤版吗 | 还会修 bug 吗 | npm 状态 | 仓库状态 |
-|---|---|---|---|---|
-| 🪦 **退役**（3 个） | 不会 | **不会**（含兼容性更新） | 已 `deprecate` | 已归档，只读 |
-| 🧊 **冻结**（6 个） | 不会 | **会**——但只有当宿主破坏性变更让它完全不可用时，才做最小兼容修复 | 正常，**没有** deprecated | 正常，**未归档** |
-| 其余 | 不会 | 会 | 正常 | 正常 |
-
-**已安装的用户该怎么做：什么都不用做。** 冻结的包照常安装、照常运行，接口不变、版本不撤。只有当某次宿主升级真的把它弄坏了才需要动作——那种情况请开 issue，我会修。**如果你要的是新功能，请去用第 3 节表里那些对手**——它们在各自赛道上的采用度都明显更高，这也是我冻结自己这几个包的原因。
-
-**为什么不用「删包」表达态度？** 因为删了之后，下一个人搜不到这个包，也看不到退役原因。所以家族表**行不删、只加状态备注**：退役与冻结的仓全部保留在每一张家族表里，用状态列标注 `🚫 已退役` / `🧊 已冻结`，描述原文照旧。
-
-## 6. 给其他插件作者的 8 个自查问题
-
-1. **官方是「有这个包」，还是「默认挂载」？** 官方 `experimental/*`、`computer-use`、`browser-use`、`lsp`、`speech-to-text` **都不在 stock 组合里**。「官方有包」不等于「用户装完就有」。
-2. **`base` 里有这一行，等于用户有这个能力吗？** 不一定。Web 补丁会把 base 进程级挂载的模型面向工具行**逐条 disable**，再交给每个 agent preset 重新挂载。只查 `base/cordis.patch.yml` 会得出偏乐观的结论。
-3. **你搜对手时用的是能力关键词，还是包名？** 只比包名会漏掉全部对手：`dsh-cost-meter` 与 `dsh-budget` 名字完全不同，`cc-safety-net` 与 `dsh-defend` 也是。
-4. **同名等于同一件事吗？** 官方 `dsh-experimental-auto-review` 与 `dsh-auto-review` 同名，但安全模型相反：官方用当前 agent 自己的 provider / model，并自述 *can allow unsafe actions, deny useful work, and spend additional tokens*，没有确定性豁免、没有持久授权；我的是独立只读的第二模型 reviewer，失败即 **fail-closed**。这不算被替代。
-5. **你的下载量能被第二个信号验证吗？** `dsh-budget` 周下载 1,079，star 只有 **10**——高下载更像 CI / 镜像噪声，低 star 才是真实吸引力。反过来 `dsh-auto-review` 有 **10 个 open issue**，那是真有人在用、在报障。单看下载量会骗人。
-6. **「我还在用吗」是不是你的判据？** 如果不用了，它不该当判据（我的 Web profile 现在就跑 stock 组合）。换成这两句：**对外是否还有人需要？维护成本是否还值？**
-7. **落后多少倍才该退？** 没有阈值。`dsh-fast` 落后 43× 留在现状，`dsh-defend` 落后 14× 被冻结。冻结要付的代价是「承认自己不再是这条赛道最好的选择」，所以只值得对「继续投入也不会产出独特东西」的包付这个代价。
-8. **你的决定写进 README 了吗？** 只写在脑子里、或只写在一份内部报告里，等于没写。冻结的包各自有 `## Maintenance status: 🧊 FROZEN` 一节，含实测对比表与「对手强在哪」的说明（6 个，各自在 `dsh-plugin-kit/data/repos.json` 里 `status` 为 `frozen`）；退役的 3 个 README 顶部有 RETIRED 横幅。**使用者至少应该能从 README 里知道你为什么不做了。**
-
-## 7. 事实陈述
-
-- **家族现状**：家族表现在列 **44 个插件仓**（含 `dsh-plugin-upgrade-015` 的表为 45 行），其中 🚫 **已退役 3 个**、🧊 **已冻结 6 个**，其余按活跃仓维护。许可以 Apache-2.0 为主。
-- **仓库位置**：https://github.com/PerryLink
-- **数据采集时间**：2026-10-05。来源为那份自查报告——npm registry API 全量拉取、GitHub REST API 实测、宿主源码逐文件取证。**结论是可复核的**：每一条都能指到具体文件或具体 API 读数，指不到的一律标「未证实」。
-
-最后一句，说给可能想接手的人：**`dsh-reach` 与 `dsh-wechat` 这两条 IM 桥接线，欢迎接手维护。** 它们被冻结的理由很具体——`@xmanrui/dsh-im` 在一个包里覆盖了 10 个通道，那是一件比我做得好的事。如果这两条线对你有用，而你想让它们继续长下去，两个仓都是宽松许可（`dsh-reach` 为 Apache-2.0、`dsh-wechat` 为 MIT），欢迎开 issue 谈接手。

package/index.d.ts

@@ -1,32 +0,0 @@
-// Type declarations for the bundle entry point (`index.js`).
-//
-// `index.js` is plain ESM JavaScript and is intentionally not part of the
-// TypeScript program (`tsconfig.json` includes only `src`, `tests` and the build
-// configs, with `allowJs` off). `tests/entry.test.ts` imports it, so without this
-// file `noImplicitAny` rejects the import as an untyped module.
-//
-// The declaration is deliberately loose: this module exists to be loaded by the
-// host's Cordis loader, not consumed as a typed library, and the shapes it
-// touches (`ctx.effect`, `ctx.skills.register`) belong to the harness rather
-// than to this package. Pinning them here would create a second, drifting copy
-// of the host contract — the exact failure mode `guide/family-toolchain.md`
-// warns about. The test asserts the runtime shape instead.
-
-/** Cordis plugin name contributed by this bundle. */
-export declare const name: string
-
-/** Services this plugin requires before `apply` runs. */
-export declare const inject: string[]
-
-/**
- * Split a SKILL.md document into its frontmatter description and instruction
- * body. Falls back to `{ description: undefined, body: text }` when there is no
- * well-formed frontmatter block. Tolerates both LF and CRLF line endings.
- */
-export declare function splitFrontmatter(text: string): {
-  description: string | undefined
-  body: string
-}
-
-/** Register the knowledge-base skill. Registration is an effect. */
-export declare function apply(ctx: any): void

package/references/cli-positioning-decision.md

@@ -1,78 +0,0 @@
-# CLI 定位决策：`dsh-plugin-dev check` / `verify` 该不该存在（2026-10-13）
-
-> **本文回答一个具体的工程质疑**（来自 `_analysis/v2-6-forward-compat.md` §5）：
-> 同族已有 33 项、带裁定语义与退出码契约的 `dsh-plugin-doctor`，本库的 16 项检查是不是**更弱的重复**，
-> 该不该削减甚至删掉？
->
-> **结论：保留，但把分工写成不可含糊的三条。** 下面是判据与"什么情况下该反过来削减"的触发条件。
-
----
-
-## 1. 先摆事实（实测，不是估计）
-
-| 事实 | 值 | 来源 |
-|---|---|---|
-| 本库检查项 | **16** | `src/cli/skill-sections.ts` 的引用表，`check-facts.mjs` 断言 |
-| 同族 `dsh-plugin-doctor` 检查项 | **33**（规范门禁 21） | `guide/family-toolchain.md` §2 |
-| 本库**独有**的检查 | **5** | `guide/family-toolchain.md` §3.2 交叉对照表 |
-| `check` 是否跑在任何工作流里 | **否** | `.github/workflows/` 无任何步骤调用它 |
-| `dsh-plugin-doctor` 是否是本仓 CI 门禁 | **是** | `plugin-doctor.yml` 以精确版本钉住调用 |
-| 本库 `check` 的代码量 | 781 行 + 13 个测试块 | `src/cli/commands/check.ts` |
-
-**光看这张表，"砍掉"是合理结论**：11 项是更弱的重复，且它不在任何门禁里——一份没人跑、又和别人重叠的检查，维护成本是纯支出。
-
-## 2. 但有三个事实让"砍掉"不成立
-
-### 2.1 独有 5 项里有 1 项是家族唯一的检测器
-
-`redline-async-apply-registration` 检测 **async `apply()` 在首个 `await` 之后注册**——这个缺陷在卸载窗口内
-静默丢失注册，表现为"装了、日志全绿、能力时有时无"。同族 `dsh-plugin-upgrade` 的 `legC` 走廊卡
-**明确点名本库这个 lint** 作为 seam E2 的预防门（见 `guide/family-toolchain.md` §3.2）。
-`dsh-plugin-doctor` 的 `K5` 只查 `apply` 的**返回形态**，查不到注册顺序。
-
-删掉它，家族内就没有任何东西能机械发现这个缺陷。
-
-### 2.2 本库的检查**每一项都链回可读章节**
-
-`dsh-plugin-doctor` 的裁定有严格的退出码契约与降级语义，但它的输出是**判定**；
-本库 `check` 的每一项都带 `skillRef`，指向该规则在知识库里的**正文**。
-两者面向不同需求：**"过没过" vs "为什么、该改哪一行"**。这是本库存在的理由，不是重复。
-
-> 这条承诺此前**部分是空的**——审计发现 2 项引用了根本没写该规则的章节，11 项引用的标题已漂移。
-> 本轮已全部修正，并加 `tests/skill-sections.test.ts` 防再漂。**承诺现在是可验证的。**
-
-### 2.3 `verify` 的价值不在强度，而在**零依赖自足**
-
-`verify` 在 D 组各轴都弱于 doctor（D9 甚至是反的：它删掉自己的沙箱）。
-但它**只用 Node 内置模块**，能在没有 network、没有 pnpm 全局状态、没有 doctor 安装的机器上跑完
-`pack → 干净 DSH_HOME 安装 → 启动 → 卸载`。对"第一次接手的作者"和离线环境，这是唯一能跑的那条。
-
-## 3. 因此的分工（写死，不再含糊）
-
-| 问题 | 用哪个 | 为什么 |
-|---|---|---|
-| "我这项改动过没过？给个裁定和 CI 退出码" | **`dsh-plugin-doctor`** | 33 项、有裁定语义、有降级检测、已是本仓门禁 |
-| "为什么这条规则存在？我该改哪一行？" | **本库 `check`** | 每项带 `kb` 引用，指向正文 |
-| "我这台机器什么都没有，先自证一下" | **本库 `verify`** | 零依赖、离线可跑 |
-| "这个缺陷同族还有谁能发现？" | **本库 `check`** 的 async-apply lint | 家族唯一 |
-
-**发布前建议两个都跑**，`SKILL.md` 与 README 已这样写。
-
-## 4. 反过来：什么情况下应该削减
-
-本文不是"永远保留"。以下任一条件成立，就该重新裁定：
-
-1. **`dsh-plugin-doctor` 获得异步注册顺序检查**（例如 `K5` 扩展为同时校验注册时序）——
-   那 2.1 的唯一性消失，本库的 `check` 就退化为"带文档链接的 doctor 子集"，应削减到文档链接层。
-2. **doctor 的裁定输出开始携带正文引用**——那 2.2 的差异消失。
-3. **本库 `check` 连续 3 个版本没有新增或修正任何检查**——说明它已停止演化，
-   而维护成本（781 行 + 13 测试块 + 约 45% 的历史 churn）仍在支付。
-
-**触发条件应定期核**：`guide/family-toolchain.md` 的交叉对照表是唯一需要更新的地方。
-
-## 5. 本轮已做的、与此决策无关的改进
-
-- 修掉 11 处 citation 漂移与 2 处"引用不存在的规则"（`tests/skill-sections.test.ts` 现在守着）。
-- `check --stirct` 这类拼写错误此前静默退出 0，现在报 `UsageError` 并以退出码 2 结束。
-- `manifest-files` 此前无条件要求 `lib`/`dist` 目录，导致 `new --lang js` 过不了自己的 `check`；已修，
-  并在 `verify-artifacts.mjs` 里加了 **scaffold → check 往返断言**——这正是当初漏掉它的原因。