improvelisted

# 治理仓库问题 把已经证明的问题或机会转化为经过验证的仓库改动。只要仍有安全、范围内的实施工作，就不能停在建议或方案阶段。 ## 开始 完整读取 `../../references/governance-standard.md`。既可以接收 `/repo-guardian:audit` 给出的问题 ID，也可以接收自然语言目标。没有已验证结论时，先围绕目标做定向审计，再开始编辑。 检查仓库规则和工作区状态，保留无关的用户改动，确定本次治理的准确职责边界。 ## 治理闭环 1. **证明起点**：用仓库证据复现问题或确认机会，运行最小必要的基线测试、测量、截图、追踪或安全检查。 2. **调查可用方案**：先检查项目已有能力、语言或运行时、框架；仍需外部方案时，按照治理标准中的“方案检索与外部验证”，用 GitHub MCP 查找相关仓库和源码，再用官方资料核对版本、漏洞、规范和兼容性。 3. **选择决策**：根据当前仓库约束和调查证据，从保留、修复、替换、新增、推迟、移除中选择。外部方案必须证明比现状更适合，不能因热度或新旧强行替换。 4. **定义完成**：明确可观察行为、质量要求、迁移需求和前后对比证据。没有基线或产品要求时，不得虚构数字目标。 5. **设计完整批次**：解决根因以及必要的调用方、测试、数据链路、状态和文档，排除无关清理。 6. **实施修改**：完成代码变化，安全迁移调用方和数据；不再需要兼容时删除被替代路径，并增加最小、持久的防回归护栏。 7. **验证结果**：运行定向和更广范围的相关检查。性能使用相同负载前后比较；界面检查真实渲染状态和视口；依赖变更验证锁文件、构建、行为、漏洞和破坏性变化；架构治理证明新边界已经被使用，而不只是新增了一层代码。 8. **继续或真实停止**：完成当前范围必需的后续工作。只有备选方案会实质改变产品行为或架构、需要凭据或外部协调，或者下一步不可逆、具有破坏性时，才停下来让用户决策。 ## 边界 - 不能实施仍未证明成立的审计候选。 - 不能仅仅因为另一方案更新或更流行，就替换运行正常的方案。 - 不能隐藏失败、削弱测试或删除行为来让检查通过，除非移除本身就是已确认的治理目标。 - 只有确认受影响的依赖、版本、代码链路和可用修复后，才能判定安全公告适用于当前仓库。 - 可行时保持迁移可回滚；跨过不可逆边界前，必须说明兼容和上线风险。 - 除非用户明确要求，不提交、不推送、不发布、不部署、不开拉取请求、不修改外部系统。 ## 完成报告 报告目标问题、根因、采用的决策、变更的文件与行为、影响决策的外部证据、修改前后证明、执行的检查、剩余风险和推迟事项。如果证据推翻了最初判断，就说明为什么保留现状，不要强行制���改动。