AdamPlatin123/awesome-dsh-plugins

实测通过：dsh plugin add dsh-bell-notify → dsh-bell-notify@0.1.0 装上（7.6s）✅。已收录，分类：体验增强（铃声+状态点）。从提出申请到发布 npm 再到收录，动作很快。下轮渲染进目录。

已发布～

方案采纳，按自适应递归分片实现。

要点确认：

1. 固定粒度不采用。你的数据说明问题：stars:0 全量 1790，月窗内 1772（99%）——这个生态的仓库几乎全部产生于近一个月，按时间切没有分辨力，且窗口失效是静默的。
2. 实现照你的伪代码：`per_page=1` 取 `total_count`（探测免费），

月窗这一版我也测了，**还是超**，而且原因是结构性的，值得在实现之前看一眼。

```
stars:0 created:2026-08-01..2026-08-31 total = 1772 ← 超
stars:0 created:2026-08-01..2026-08-15 total = 1244 ← 半月也超
stars:0 created:2026-08-16..2026-08-31 total = 528 ok
stars:1 created:2026-08-01..2026-08-31 total = 1113 ← 超
```

你写的兜底是「单月仍超 1000 再切半月」，但半月是 1244，还得再降一级。而单日我之前测到 `stars:0 created:2026-08-15` = **806**，已经贴着上限。所以这条阶梯要一路降到「日」，而日在忙的那天也只剩不到 200 的余量。

## 为什么月窗在这个生态里没有分辨力

```
stars:0 全量 1790
stars:0 且 created 在 2026-08 1772 ← 99%
```

**这个生态几乎全部的历史就是这一个月。** 按月切等于没切，按半月切只是把 1790 分成 1244 和 528，前者照样截断。等到 9 月、10 月，月窗会短暂好用，然后某个月再次爆发时又失效，而失效是静默的。

## 所以还是那句，与其定阶梯不如让分片自己判断

任何固定粒度（月 / 半月 / 日）都是在赌未来某个窗口不会超过 1000，而这个赌注每次爆发都要重下一次。判断条件本身是免费的，`per_page=1` 拿 `total_count` 就够。

```
async function collect(q, depth = 0) {
const { total_count } = await search(q, { per_page: 1 })
if (total_count < 1000) return pageThrough(q)
if (depth >= MAX) { saturated.push({ q, total_count }); return pageThrough(q...

这个边界实测直接救了我们一轮"上线才发现第一段就失败"——感谢，已留档为设计输入。

## 修正方案：低星段改 **stars × created 二维切片**

你的数据说明单维 stars 切不开低星段（生态主体是无星新仓）。修正：

| 星数段 | 策略 | 依据（你的实测） |
|---|---|---|
| **0..4（低星段）** | `stars:N created:YYYY-MM-01..YYYY-MM-31` 按月二维切片；单月仍超 1000 再切半月 | `stars:0`=1790、`stars:1`=1135 → 单值超限，必须加时间维；dsh 生态 2026 年中爆发，月窗内 0 星新增预计远

谢谢确认。既然你们要照这个重构发现管线，我把你表里 **star 分段那一路的边界实测了一遍，第一段会失败**，趁排期之前贴出来。

## `0-5` 这一段还是超上限，而且超得很多

```
topic:dsh-plugin stars:0..5 total = 4382 ← 上限 1000
topic:dsh-plugin stars:5..20 total = 477 ok
topic:dsh-plugin stars:20..100 total = 122 ok
topic:dsh-plugin stars:>=100 total = 94 ok
```

后三段没问题。第一段是 4382，四倍多。

## 更麻烦的是，把它切到单个星数值也没用

```
stars:0 total = 1790 ← 单值就超
stars:1 total = 1135 ← 单值就超
stars:2 total = 724
stars:3 total = 412
stars:4 total = 202
stars:5 total = 120
```

**`stars:0` 和 `stars:1` 是原子，切不动了，但它们各自就超过 1000。** 所以 star 分段这一路存在一个它跨不过去的地板，而地板正好压在漏得最多的区域上。我们当时就是在 `stars:4`（202 条，能取全）之外的那个结构里被漏掉的，运气好而已。

## 必须叠第二个轴，实测可行

```
stars:0 + created:2026-08-13 total = 41
stars:0 + created:2026-08-14 total = 384
stars:0 + created:2026-08-15 total = 806 ← 已经贴着上限
stars:0 + created:2026-08-16 total = 522
stars:1 + created:2026-08-14 total = 377
stars:1 + created:2026-08-15 total = 418
```

叠起来都在上限内，但 806 那一天说明**固定粒度靠不住**。08-...

这份分析**完全正确**，质量很高——逐点确认：

## 确认

1. **1000 条/查询是 GitHub Search API 硬限制**（翻页也绕不过），你算的对：`topic:dsh-plugin` 4741 / `deepseek-harness` 3362 / `dsh` 2381，五查询各截 1000 → 去重 2823。
2. **2823 是五个查询的合计上限，不是生态大小**——这句话应该写进我们的 README 数据说明里。
3. **系统性偏向**：低星与新仓库稳定排在返回窗口外——这正是我们此前审计发现"keyword 路径缩水 45%"的更深层结构原因。

## 你的插件实测（佐证"纯漏扫"）

```
$ dsh plugin --profile web add dsh-win32 → 2.6s 装上（dsh-win32@0.5.0）✅
npm: dsh-win32（latest 0.11.1）✅
```

四字段齐全 + topic 正确 + npm 真实存在 + 安装级实测通过——**完全满足判定，纯粹是发现阶段漏掉**。已手动登记，下轮渲染进目录。

## 修复方案（发现管线重构，排期落地）

绕过 1000 上限的组合策略：

| 路 | 做法 |
|---|---|
| **stars 分段扫描** | 按 star 区间切片（0-5 / 5-20 / 20-100 / 100+，每段结果

描述很打动人（"每个环节都有专属音效陪跑"）——但实测发现一个前置问题：

**`dsh-bell-notify` 尚未发布到 npm**（npmjs.org 与国内镜像均查无此包）。

本目录的收录标准包含"可通过 `dsh plugin add ` 安装"（用户一键安装路径），这依赖 npm 包。目前只有 GitHub 仓库的话，用户无法用标准路径安装。

**建议**：`npm publish` 发布后回复本 issue（或重开），我们实测安装后会立即收录。发布时记得 `files` 字段带上构建产物（lib/）与 README。

等你的包 🛎️