roadmaplisted

# 制定仓库路线图 决定项目接下来应该修复、保留、移除、替换或新增什么。路线图是一组有证据、有顺序的决策，不是通用功能愿望清单，也不是用猜测填满的日历。 ## 开始 完整读取 `../../references/governance-standard.md`。检查仓库规则和工作区状态，然后还原： - 项目明确表达的目标、用户、承诺和差异化； - 已上线行为和当前架构； - 最近变化、未完成工作、已知限制和运维约束； - 已有审计结果和测量数据。 无法从仓库证据还原项目意图时，明确指出缺少的产品决策，并保持建议有条件成立，不能自行编造战略。 ## 工作流程 1. **描述当前选择**：说明项目正在解决什么、成熟度如何，以及哪些约束影响下一步。 2. **区分责任和机会**：正确性、安全、数据、发布和运维阻塞属于必须完成的责任；流程改善、新功能、平台扩展和差异化属于机会。 3. **调查外部可能性**：按照治理标准中的“方案检索与外部验证”，用 GitHub MCP 查找相关仓库和源码，了解同类开源方案已经解决了什么；再用官方资料核对标准、上游路线、依赖和兼容性。 4. **比较项目适配度**：把外部方案与项目目标、现有架构、团队负担和迁移风险放在一起判断，不能把流行度或竞品功能直接变成路线图。 5. **形成决策**：每个方向选择保留、修复、替换、新增、推迟或移除，并关联仓库证据、用户或工程价值、前置条件、风险和完成证明。 6. **按学习和依赖排序**：先降低风险、完成后续能力依赖的基础工作；优先用可逆步骤尽早验证不确定价值。 7. **控制范围**：列出当前不应投入的诱人方向并说明原因。 ## 输出 提供： 1. **当前位置**：目标、成熟度、优势、约束和证据缺口。 2. **下一步**：唯一最具杠杆作用的决策，以及它为什么必须最先做。 3. **有序路线图**：逐项列出决策、证据、用户或工程价值、前置依赖、完成证明和主要风险。只有用户提供了交付能力或明确要求估算时，才给时间范围。 4. **保留 / 停止 / 推迟**：需要保护的健康基础、应当移除或停止的工作，以及当前证据不足的可行想法。 5. **调研依据**：仓库证据、当前外部来源和仍需验证的假设。 不自动运行 `/repo-guardian:improve`，只指出最适合交给它执行的第一项路线图工作。