中国独立开发者列表：处理项目提交

处理 1c7/chinese-independent-developer 的项目提交：扫 #160 评论、open issue、open PR，有效的收进对应 README，无效的按类别拒绝，评论区里的意见与建议单独上报。

阅读顺序：本文是流程和硬约束，每次运行完整读一遍。本文写「→ 判例：X」的地方，是历史上踩过的坑，遇到对应情况再去读 references/precedents.md 的 X 节，不要在执行时全量加载判例库。

硬红线（与任何下文冲突时，以本节为准）

1. 不得调用添加 reaction 的 API。
2. 不得删除或修改他人已有条目；唯一例外是产品作者本人要求更新自己的条目（换 URL、改描述）。
3. 合并 PR 前必须 gh pr diff 逐行审查，diff 里出现删他人条目的 - 行，一律先恢复再合并，绝不让删除落进 master。
4. 所有 GitHub 操作只能走 shell 里的 gh / git，保证用的是维护者 1c7 的 PAT；不用 GitHub Connector 或平台原生 GitHub 工具。本地文件读写用当前运行环境自带的工具。
5. 格式问题绝不能作为拒绝 / 关闭理由。 允许拒绝的只有：垃圾广告、非中国开发者、大厂产品、返佣链接、刷量平台。
6. 状态图标、描述文字以提交者为准。 提交者写 🕗 就是 :clock8:，不许改成 ✅；不许拿官网资料重写他的简介。
7. 版面名称固定写「主版面」「程序员版面」「游戏版面」，带「面」字。
8. 每一次拒绝都必须在最终汇报里单列，不许悄悄处理掉；致谢评论不用列。
9. 评论区里的意见与建议只上报、不处置：不改、不删、不回复、不关闭。
10. 版面判断必须点开产品链接实际看一眼，不能凭标题猜。
11. 遇到身份、拒绝、版面、格式、去重、PR、容量、签名、接口任一类判断，先读 references/precedents.md 对应小节再拍板，那是维护者已经定过调的先例；不要让"想当然"覆盖踩过的坑。

0. 预检

0.1 环境自检（先跑这个，不通过就停）

git status --short                                                   # 必须为空
git fetch origin master && git rev-list --count HEAD..origin/master   # 必须为 0
gh auth status | head -5                                             # 必须是 1c7 本人的 PAT

• 落后远端 → git pull --rebase origin master 再开始。
• 工作区有改动 → 多半是上次运行中断，先 git diff 看清是补完还是丢弃，不要直接 checkout --。

0.2 三个计数

SINCE=$(date -u -d '72 hours ago' +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -v-72H +%Y-%m-%dT%H:%M:%SZ)

COUNT_COMMENTS=$(gh api "repos/1c7/chinese-independent-developer/issues/160/comments?since=$SINCE&per_page=100" | tee /tmp/c160.json | jq 'length')
COUNT_ISSUES=$(gh api "repos/1c7/chinese-independent-developer/issues?state=open&per_page=50" \
  | jq '[.[] | select(.number != 160 and .pull_request == null)] | length')   # 另有「已知保留 issue」清单，见第 2 节末尾
COUNT_PRS=$(gh api "repos/1c7/chinese-independent-developer/pulls?state=open&per_page=50" \
  | jq '[.[] | select(.head.ref | startswith("auto-add-") | not)] | length')

echo "新评论: $COUNT_COMMENTS  新Issue: $COUNT_ISSUES  待处理PR: $COUNT_PRS"
wc -c README.md

• 时间窗统一 72 小时（运行间隔不固定，取 3 天余量）。距上次超过 3 天就临时改 -v-240H。
• 评论数偏大是正常的：里面混着我们自己的致谢。
• 三个数字全为 0 不等于收工：仍要跑 0.3 的差集、检查一之二、收尾扫描。
• ⚠️ wc -c README.md 超过 490,000 就地处理，别等到插入条目之后：运行间隔里别人 merge 也可能顶过线。直接按 6.3 跑 migrate_archive.py --write，即使本次空跑也要单独发一条搬迁 commit（2026-09-27 实测：开跑时已是 490,082 字节，只想着"这次没新条目"就会把超标状态原样留给下一次）。

0.3 差集：只看域名和产品名

查重永远只看两样东西：产品域名、产品名。提交者是谁、他以前投过几次、隔了几周几个月，统统不参与判断——同一个作者跨月跨年反复投稿是常态。

python3 .github/scripts/pending_submissions.py /tmp/c160.json; echo "EXIT=$?"

脚本把窗口内每条非我方评论里的 URL 和产品名抽出来，逐个到 README 系列（主版面 / 程序员版面 / 游戏版面 / 两个分册）比对，按结果打三种标签：

• 输出「无待处理项」→ 本次确实没有新提交，可以空跑。
• 作者主页 / 博客 / 社交页会混在输出里，看一眼跳过。
• 禁止用「提交者 - 已致谢」的用户名差集来查重。撞过两次：huangy7（2026-10-10）、stimQQ（2026-10-21，LayerGrab 已收，又投 Flux3Max）。按人去重会把老作者的新投稿整批遮掉（→ 判例：F）。
• 用户名差集只剩一个用途：交叉核对有没有漏发致谢。不参与「该不该收」的判断。

1. 检查一：#160 的新评论

SINCE=$(date -u -d '72 hours ago' +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -v-72H +%Y-%m-%dT%H:%M:%SZ)
gh api "repos/1c7/chinese-independent-developer/issues/160/comments?since=$SINCE&per_page=100"

对每条评论提取产品 URL，查是否已在任一分册：

grep -rF "<产品完整URL>" README.md .github/pages/README-Programmer-Edition.md .github/pages/README-Game.md

去重规则

• 必须用完整 URL 精确匹配（grep -F），禁止用产品名或关键词判断重复。
• URL 已存在 → 跳过，且不发致谢（说「已添加」会误导）。
• URL 不存在 → 进「通用处理流程」。
• 本次运行中已通过 PR 合并的条目视为已存在。
• 同一产品换域名不算拒绝理由，照常收录，但描述必须写出它独有的功能点（→ 判例：F）。

72h 窗口重叠：被判「拒绝」的评论不会在 README 留痕迹，URL 去重挡不住重复处理。发拒绝回复前先查这条评论之后有没有我们 @ 该提交者的回复：

gh api "repos/1c7/chinese-independent-developer/issues/160/comments?per_page=100" \
  | jq --arg since "<该评论created_at>" \
    '[.[] | select(.created_at > $since and (.user.login=="1c7" or .user.login=="claude[bot]"))]'

处理完记录：作者用户名、产品名、目标版面（供第 7 步逐人致谢）。

1b. 检查一之二：评论区的意见与建议（只上报，不处理）

维护者很少回看原文，这类内容不上报等于消失。每次运行都跑，空跑也跑。

拉 #160 最新 200 条评论，排除我们自己：

TOTAL=$(gh api repos/1c7/chinese-independent-developer/issues/160 --jq .comments)
LAST=$(( (TOTAL + 99) / 100 ))
for p in $((LAST-1)) $LAST; do
  gh api "repos/1c7/chinese-independent-developer/issues/160/comments?per_page=100&page=$p"
done | jq -s 'add' \
  | jq -r '.[] | select(.user.login != "1c7" and .user.login != "claude[bot]")
           | "\(.created_at[0:10])\t\(.id)\t@\(.user.login)\n\(.body[0:300])\n---"'

⚠️ 单 issue 评论接口的 sort/direction 无效、per_page>100 会截断并返回最早的一批。必须按上面的算法倒着取页（→ 判例：J）。

判据：有没有「产品名 + 可访问 URL + 描述」三元组？有 → 是提交，走检查一。没有、说的是列表本身 → 属于本节。

典型内容：指出描述过时/链接失效/分类放错/作者不是中国人/是返佣或刷量站；要求修改或下架自己的条目；质疑收录标准；抱怨重复、排序、分册、格式；建议加版面或字段；版权侵权投诉；对运营方式的不满。

动作（硬约束）

• 不改任何条目、不删、不回复、不关闭、不发 reaction。
• 只登记：链接（https://github.com/1c7/chinese-independent-developer/issues/160#issuecomment-<id>）、作者、时间、原文摘要（保留原措辞，不改写成中性描述）、类别 + 建议选项。
• 涉及版权/侵权/法律、要求删他人条目、指认刷量返佣 → 标「紧急」，汇报里置顶。
• 不许因为「语气冲」「像广告」就当噪音忽略；也不许顺手替他改了再报「已处理」。
• 已上报的 comment id 记进 automation memory 的「已上报意见评论 id」，下次先排除。

2. 检查二：所有未关闭的 Issue（排除 #160）

不限时间窗（2026-10-19 调整）：原来只查「最近 72 小时开启」的 issue，一旦某次运行没跑到这步，issue 就永久滑出窗口、再也不会被看到。

gh api "repos/1c7/chinese-independent-developer/issues?state=open&per_page=50" \
  | jq '[.[] | select(.number != 160 and .pull_request == null)]'

• 有效提交 → 进通用处理流程 → 在该 issue 本身（不是 #160）发致谢并 PATCH 验证 → 关闭 issue（不能漏）。
• 垃圾广告、无关内容 → gh issue close <number>。
• 对列表本身的意见 / 纠错 / 投诉 → 不是垃圾，不许关。保持 open，按 1b 的格式登记进汇报。
• 内容不清、信息缺漏 → 不是关闭理由，尽力提取收录；确属纯广告无任何可定位产品才关。
• 确凿是老外 → 按第 4 步拒绝流程。
• 明显是维护者自己的公告 / 征集 / 置顶帖 → 不关闭，把这个 issue 编号记进 automation memory 的「已知保留 issue」清单，下次运行直接跳过，不要每次都重新判断一遍。

检查二的提交者已在各自 issue 收到致谢，不需要在第 7 步再 @。

3. 检查三：所有未关闭的 PR（排除 auto-add- 分支）

gh api "repos/1c7/chinese-independent-developer/pulls?state=open&per_page=50" \
  | jq '[.[] | select(.head.ref | startswith("auto-add-") | not)]'

每个 PR 的处理顺序：

1. gh pr diff <number> 逐行看。有删他人条目的 - 行 → 先恢复（maintainer_can_modify 为 true 就推到贡献者分支；否则本地合并时恢复），让最终 diff 回到纯新增（→ 判例：G）。
2. 新增行若落在「### 子版面」清单里 → 照常合并，合并后单独 commit 挪到正确位置（普通产品进当天日期区块；基于本列表数据源的产品进 README 底部专属区块）。
3. gh pr merge <number> --squash。报 Base branch was modified 不是真失败，sleep 5 后重查 mergeable/mergeable_state，true/clean 就重试一次（→ 判例：G）。
4. 合并成功后在该 PR 发致谢（POST → PATCH → GET），说清收录到哪个版面。PR 和 issue 共用编号空间，致谢必须发在 PR 自己的号上；同一次运行里既有 issue 又有 PR 时逐条核对目标号（→ 第 7 节的串号事故）。
5. 合并失败（冲突）：由我们解决，绝不要求提交者 rebase。优先改他分支再 --merge；推不了才本地 git merge --no-ff + git push + gh pr close 兜底（→ 判例：G）。冲突复杂到分不清该保留什么（不只是新增条目，而是改了已有结构）→ 不要瞎猜、不要删任何已有内容，在 PR 里说明冲突原因、保持打开等人工介入。

# 先取分支信息（冲突路径和推送都靠这两个值）
HEAD_REF=$(gh api repos/1c7/chinese-independent-developer/pulls/<number> | jq -r '.head.ref')
HEAD_REPO_URL=$(gh api repos/1c7/chinese-independent-developer/pulls/<number> | jq -r '.head.repo.clone_url')
MAINTAINER_CAN_MODIFY=$(gh api repos/1c7/chinese-independent-developer/pulls/<number> | jq -r '.maintainer_can_modify')

# maintainer_can_modify=true：改他的分支，让 PR 保持紫色 Merged
git fetch origin master
git fetch origin pull/<number>/head:pr-<number>
git checkout pr-<number> && git merge origin/master --no-edit
# 手工解决冲突：双方新增的条目都保留，冲突标记清干净
git add <冲突文件> && git commit --no-edit
git push "$HEAD_REPO_URL" "pr-<number>:$HEAD_REF"
gh pr merge <number> --merge

# 推不了才兜底（PR 会显示为 Closed，评论里不要提这件事）
git fetch origin master && git fetch origin pull/<number>/head:pr-<number>
git checkout master && git reset --hard origin/master
git merge pr-<number> --no-ff -m "合并 PR #<number>：<项目名>"
git push origin master && gh pr close <number>

6. 合并后：跑 wc -c README.md 容量检查；格式硬伤单独发整理 commit；当天区块顺序不对另发排序 commit。

• 多个 PR 必须串行，每处理完一个立即 git fetch origin master。禁止「手动誊抄 + 批量关闭」。
• PR 写错版面 → 照常合并，再单独 commit 搬到正确文件。
• 格式乱 → 不是关闭理由，合并后整理。

4. 身份判断：只收中国独立开发者

默认能收就收，只有确凿证据是老外才拒绝。满足任一条即判为中国人：

1. 中文留言，通顺自然，不是机翻腔。
2. 名字是拼音或明显中国人姓名（含港澳台）。
3. GitHub 主页有中国元素：中文 bio、中文仓库描述、location 写中国城市。

gh api users/<username> | jq '{name, bio, location}'
gh api "users/<username>/repos?sort=updated&per_page=10" | jq '[.[] | {name, description}]'

• 不能只看单一信号；name 是外文名但仓库全中文 → 收（→ 判例：A）。
• location 在国外不能单独当拒绝依据，中国留学生照样收；写中国城市也不能单独当收录依据。
• 三条都拿不到结论 → 照常收录，不要为了稳妥而拒。

确凿是老外时的处理：检查一不收录、只在评论下礼貌说明；检查二礼貌评论后关闭 issue；检查三礼貌评论后关 PR（不用 merge）。用提交者的语言，只给结论不给判断依据，POST 后同样 PATCH + GET 验证。

感谢分享 <产品名>！不过本仓库只收录中国独立开发者的项目（README 开头写明"聚合所有中国独立开发者的项目"），所以暂时不在收录范围内，抱歉。祝 <产品名> 发展顺利！

Thanks for sharing <product>! This repo specifically curates projects made by Chinese independent developers, so it's outside the scope of this list. Good luck with <product>!

每一次拒绝都必须出现在最终汇报里。

5. 补充拒绝类别

除垃圾广告和老外，以下三类也拒绝：

1. 大厂 / 上市公司产品：官网归属某公司且该公司是上市公司或有规模团队（如 seko.sensetime.com = 商汤）。
2. 分销返佣链接：落地 URL 带渠道参数（cg_click_id、cgv、utm_source=cakegrowth_gzh、ref=、invite=、aff=）。
3. 刷量 / 互赞平台：按 Star/Watch/Fork 计价；承诺「不掉赞 / 掉赞返积分」；站内每个仓库的 Star 与 Watch 数字完全相同。

⚠️ 判据要逐条比对，不要用观感扩大化：

• affiliate 多数是「not affiliated with X, Inc.」免责声明，不是联盟计划。
• ref= 指向本仓库且提交者就是作者 → 只是来源追踪，正常收录。
• 站内有 affiliate 但落地 URL 干净、内容无付费墙 → 正常收录。
• GEO / AI 可见度优化 / 真人测试这类推广服务，不按 Star 计价就不是刷量。
• 超出这三类的「看着有点问题」不算拒绝理由，默认收录；要拒先问维护者（→ 判例：B3）。

必做核查（任何可疑链接）：

curl -sL --max-time 20 "<url>" -o /dev/null -w "HTTP:%{http_code} FINAL_URL:%{url_effective}\n"
curl -sL --max-time 20 "<url>" | grep -oE '<title>[^<]*</title>|og:url[^>]*' | head -5

• 落地域名与提交域名不同 → 看归谁；带渠道参数 → 返佣；title 暴露的公司与提交者无关 → 大厂。
• curl 打不开 不能据此判站点有问题，必须换 WebFetch 复核一次。000/SSL_ERROR、503 限流页、403 Cloudflare 拦截都不等于站点挂了（→ 判例：C）。
• 双通道都失败时查根域；根域可达且明确指向该子域产品，就算核实通过。
• *.pages.dev / *.github.io / *.vercel.app / *.netlify.app 只是托管，不是大厂。
• 提交者描述与站点不符时以站点 meta description 为准，尤其数量词、输入模态、是否带音频、计费单位。

拒绝模板（只给结论）：

@<用户名> 感谢推荐！不过本仓库只收录中国独立开发者自己的项目，<产品名> 是 <公司名> 的产品，暂时不在收录范围内，抱歉。祝 <产品名> 发展顺利！

POST → 捕获 ID → PATCH 覆写 → GET 验证正文。拒绝后的动作同第 4 步：检查一只回评论、检查二评论后关闭 issue、检查三评论后关闭 PR（不 merge）。

6. 通用处理流程（检查一、二通过身份判断后）

6.1 提取与格式化

必须有：制作者名字（没写用 GitHub 用户名）、产品名、可访问 URL、一句话描述。拿不到 URL 时从仓库或正文里找，只有纯广告无任何可定位产品才算垃圾。

可选：城市、GitHub、博客、更多介绍链接。

#### 制作者名字(城市) - [Github](url)
* :white_check_mark: [产品名](url)：一句话描述 - [更多介绍](url)

格式规范

• 提交者明确说「不要改我的简介」→ 一字不动照用，跳过下面所有清理规则。
• 提交者已写好 README 格式的条目 → 那是定稿，逐字保留，只改半角全角、句尾句号、缺失空格、[更多介绍] 前缺的「 - 」。
• 状态图标原样沿用：🕗→:clock8:，✅→:white_check_mark:，❌→:x:。不许升级、降级，不许拿官网资料重写简介（→ 判例：E）。
• 日期标题用北京时间：TZ=Asia/Shanghai date +"%Y 年 %-m 月 %-d 号添加"。
• 描述末尾不加句号；去掉「高效、简洁、强大、快速、好用、一款、一个」等填充词；「免费」是核心特征时保留。
• 不以「免费的」开头：免费的间歇计时器 → 间歇计时器（免费）。
• 「在线」一般删掉，除非是用来区分客户端/离线版。
• 产品名提到最前；描述不要以「产品名是一款…」开头；形态、平台放句尾用「 — 」带出。
• 严禁加粗（不用 **）。

6.2 分类

桌面 App 看服务对象：面向普通用户/创作者 → 主版面；额度监控、依赖清理、Agent/IDE 管理器、菜单栏开发工具 → 程序员版面（→ 判例：D）。

个人博客、内容站不算产品，不收（→ 判例：B5）。作者另有产品时，博客写成作者信息行里的链接（#### 名字(城市) - [Github](url), [博客](url)），不单独占一行。把「博客」链接点开核实，实为导航站/资源站的不收。

6.3 插入与提交

• 新条目插在当天日期区块顶部；区块不存在则在最新区块之前新建。绝不写进 README 顶部的「### 子版面」清单——那里只放本仓库自己的页面（程序员版面、游戏版面、更早的项目），外部产品一律不进。
• 同一作者当天已有作者行 → 追加到他的条目列表末尾，不另起重复 ####。
• PR 带来的条目一律并入处理当天的区块，贡献者写在哪不算数。
• 当天区块内按「最新收录在最上」排序；三个文件分别用 git log 核对：

for f in README.md .github/pages/README-Programmer-Edition.md .github/pages/README-Game.md; do
  echo "== $f"; git log --date=local --format="%h %ci %s" -8 -- "$f"
done

容量：插入后 wc -c README.md。超 490,000 就搬迁，一次剪到 487,500 留余量：

python3 .github/scripts/migrate_archive.py            # 预演，看到「行级校验通过」
python3 .github/scripts/migrate_archive.py --write

只有脚本不可用时才手剪，且必须按日期定位插入、兼容「日/号」两种标题、不重排分册（→ 判例：H）。分册自己接近 500,000 字节时，把较新的一半拆成 README-Earlier-Projects-2.md，编号一旦定下就冻结。

• 余量不足 1 KB 就算超标：即使当时还没到 490,000（如 489,970），下一次收录必然顶过线，当场搬迁，别留给下一次。
• 脚本报「行级校验失败」时先看丢失行样例：若只是「（2018 年 ~ 2024 年）」→「（2018 年 ~ 2025 年）」这类年份范围改写，那是校验未归一化年份文字导致的误报（脚本已在 2026-10-21 修好），不是真丢内容，不要手改 README 去凑校验。注意顶部子版面清单那行写的是「（2018 ~ 2024 年）」（没有第一个「年」字），脚本正则匹配不到，搬完要手工改成新年份。

提交：git pull → 改文件 → git add → 一次 commit → git push origin master。pull 必须在 commit 之前（合并过 PR 后本地是落后的，先 commit 再 push 会被拒）。用 git pull --rebase 的，rebase 完必须 grep 确认本次新增的条目还在——冲突合并有可能把它弄丢。不建分支、不开 PR；PR 来源不走这条。

7. 致谢评论（仅检查一的提交者）

每位提交者单独一条，一人一评，不合并。正文只写结果，不加「谢谢」等结尾客套，不提冲突/手动处理等过程。

@<用户名> 感谢提交，已将你的产品 <产品名> 添加到 <主版面/程序员版面/游戏版面>！

每条都 POST → 立即 PATCH 覆写 → GET 验证正文，且版面名必须带「面」字。

⚠️ 一次处理多个提交时最容易串号：PR 在 API 里也是 issue，编号相同，issues/<号>/comments 打错一个数字就把 A 的致谢贴到 B 下面（2026-10-21 事故：SliceLoft 的致谢被贴到 Issue #1622 Notebook Generator 下，PR #1620 反而没收到，维护者当场发现）。

• 批量发时必须一条命令只对应一个目标号，别在循环里拼号；发完把每条评论 id 反查回它所属的编号：gh api repos/1c7/chinese-independent-developer/issues/comments/<id> --jq .issue_url。
• 只按 id GET 正文验证是不够的——正文对、位置错照样是事故。位置错了就 -X DELETE 删掉自己那条（删自己的不算违反红线 2），再往正确的号重发。

8. 收尾扫描（每次都做，含空跑）

for p in 1 2 3 4 5; do
  for try in 1 2 3; do
    gh api "repos/1c7/chinese-independent-developer/issues/comments?sort=created&direction=desc&per_page=100&page=$p" \
      > /tmp/sig_scan_$p.json 2>/dev/null && break
    sleep 3
  done
done
jq -s 'add' /tmp/sig_scan_[1-5].json > /tmp/sig_scan_all.json
jq -e 'type == "array" and length > 0' /tmp/sig_scan_all.json >/dev/null \
  || { echo "扫描接口没拿到数据，本次扫描无效，必须重试后再判断"; exit 1; }

jq -r '[.[] | select(.body | test("Generated by")) | select(.user.login as $u | ["1c7","claude[bot]"] | index($u)) | .id] | unique | .[]' \
  /tmp/sig_scan_all.json > /tmp/sig_dirty.txt
echo "已扫评论: $(jq 'length' /tmp/sig_scan_all.json) 条"
echo "检出待修: $(grep -c . /tmp/sig_dirty.txt) 条"

扫到就逐条 PATCH 并 GET 复核；空正文保护；只修我们自己发的（贡献者用 > 引用的是他的评论，不许动）；修完必须重新扫一遍确认残留为 0（→ 判例：I）。

9. 运行结束向维护者的汇报

只列结果，不列过程：

• 按版面分组：「主版面新增：A、B」「程序员版面新增：C」「游戏版面新增：D」
• 作者本人更新条目：「主版面更新：X（作者本人改的）」
• 未收录必列：产品X（原因：老外 / 垃圾广告 / 大厂产品 / 带返佣链接 / 刷量平台 / 重复提交 / 信息无法定位）；被维护者推翻改为收录的，如实写翻转。
• 必须有一节「需要你处理的意见/建议（N 条）」：链接 + 谁说的 + 原文摘要 + 建议选项，紧急项置顶；没有就写「无」，不许省。
• 结尾：「共 N 项收录，M 项未收录，全部处理完毕。」空跑写「本次无新收录，本次无未收录项」。
• 除此之外不写过程：跳过的重复项、diff 审查、URL 去重、致谢、签名扫描、容量数字、commit 哈希一律不写。

**主版面新增**：Unit Converter for Science、Jev AI

**程序员版面新增**：Agents Anywhere

**未收录**：书径 EbookNest（原因：信息无法定位）

**需要你处理的意见/建议（1 条）**
- [issues/160#issuecomment-123456](链接) @someone：说主版面某条链接 404 —— 建议：核实后改 URL

共 3 项收录，1 项未收录，全部处理完毕。

10. 注意事项

• gh 不在 PATH 时先 export PATH="/opt/homebrew/bin:$PATH"。
• 幂等性靠 URL 精确 grep，不依赖 reaction 标记。
• 判例库：references/precedents.md（A 身份 / B 拒绝 / C 网络核查 / D 版面 / E 格式 / F 去重 / G PR / H 容量 / I 签名 / J 接口 / K 意见）。只在遇到边界判断时查，不要每次全读。