Author Remediation

插件作者整改通知

哪些项目会收到通知

成功的 Catalog 扫描会为不符合准入条件、暂缓上架或候选项目生成原因明确的整改记录。通知覆盖符合直接整改条件的新发现项目，也会跟踪已通知项目在 canonical 仓库是否出现新的默认分支 Commit。

每轮计划还会把 registry/candidates.json 的全部 canonical 仓库写入机器可读覆盖台账。每个候选只能归入一个状态：直接整改、公开待复检、公开整改原因、公开基础设施暂缓或公开发现记录。候选记录数与台账归类数不一致、或未覆盖数不为 0 时，工作流拒绝执行。这样一千多个候选不会从公开清单和后续复检中遗漏。

每次工作流最多新建 3 个整改 Issue，避免短时间大量通知。已有记录会复用并更新，不会为同一项目无限创建重复 Issue。

全量台账不代表向一千多个作者群发广告。GitHub 直接通知只用于用户提交、固定 Commit 复核、已有修复协作或当轮确定性拒绝，并且必须给出具体技术原因。纯雷达发现的历史候选继续公开展示和复检，但不主动 @mention，不发送纯推广内容，也不去第三方仓库批量开 Issue。DSH STORE 链接只作为整改状态入口附在有实际技术内容的修复单中。

通知中包含什么

• 当前失败或暂缓原因；
• 最小可执行修复建议；
• build-dsh-plugin 的只读检查与修改入口；
• DSH STORE 官网；
• 上架契约与自动化证据链接。

常见整改包括：补充公开许可证、标准 dsh.bundle.patch、唯一入口 ID、显式运行文件、兼容最近三个 DSH 版本之一、移除隐藏生命周期脚本、减少运行时源码体积，或明确 monorepo 插件目录。

如何判断作者是否修改

自动化保存上次观察到的仓库默认分支 Commit。后续运行会分为：

• 未检测到新提交；
• 首次建立基线或暂无法判断；
• 检测到修改但仍未通过；
• 检测到修改且原阻断已清除。

这只能证明 canonical 仓库是否出现新 Commit 以及门禁结果变化，不能证明作者阅读了邮件、理解了建议或完成了真实运行测试。

关于“邮件”

仓库通过 GitHub Issue、评论和 @mention 触发 GitHub 通知。接收者是否收到电子邮件取决于其 GitHub 通知设置，DSH STORE 无法验证实际投递或阅读。每次自动报告会分别列出 GitHub 整改消息数量、GitHub 邮件通知触发数量和作者修改结果，不把触发量冒充送达量。

报告还会列出候选总记录、canonical 仓库、已归类、未覆盖、符合直接通知、已建修复单、本轮安排、待限速发送和仅公开展示的数量。完整项目清单以公开 Candidate Registry 为准。