fec-source-driven-developmentlisted

# 来源驱动开发 ## Purpose 在前端实现、评审和架构决策中优先依据项目内事实、官方文档和当前版本行为，避免沿用过时经验或未经验证的假设。 ## Procedure 1. 判断是否需要查源 - 涉及框架新版本、路由、渲染模式、缓存、构建工具、浏览器 API、包发布格式、鉴权协议或公共接口时必须查源。 - 涉及项目约定时先读本仓库 README、配置、模板、已有实现、测试和迁移记录。 - 只是稳定语言语法或明显局部重构时，可使用项目现有模式作为事实来源。 2. 收集权威材料 - 首选官方文档、规范、源码、release notes、migration guide、类型定义和项目内测试。 - 第三方文章只能作为线索，不能作为最终依据。 - 对快速变化的库记录包名、版本、文档日期或页面标题。 3. 提炼决策 - 写清当前版本推荐做法、弃用做法、限制条件和迁移注意事项。 - 对多个可行方案说明选择理由、兼容性、维护成本和回退方式。 - 若文档和项目现状冲突，优先解释冲突并给出渐进调整，不直接推翻已运行系统。 - 对依赖升级、框架迁移和公共 API 变化，记录 release notes、migration guide、版本范围、破坏性变更和回滚方案。 4. 落到实现 - 将外部行为隔离在适配层、配置层或小型工具函数中，避免在组件里散落版本假设。 - 公共接口变化要保持命名、错误形状、默认值和兼容策略清晰。 - 代码注释只记录非显而易见的来源约束，不粘贴大段文档。 5. 验证假设 - 用类型检查、最小复现、单元测试、组件测试、E2E、构建或浏览器验证证明关键假设。 - 如果无法验证，报告不确定性、风险范围和需要用户或团队确认的信息。 6. 留下轻量决策记录 - 当结论会影响公共接口、依赖版本、目录规范或团队工作流时，补充 ADR/变更记录或交给文档同步流程。 ## Source Priority | Priority | Source | Use | | -------- | ------ | --- | | 1 | 项目内配置、测试、已有实现 | 判断本仓库真实约定 | | 2 | 官方文档、源码、类型定义 | 判断当前推荐行为 | | 3 | 标准规范、浏览器兼容数据 | 判断平台能力和兼容边界 | | 4 | Issue、讨论、第三方文章 | 辅助排查，不能单独定案 | ## Constraints - 不凭记忆给版本敏感结论。 - 不把过时教程当作当前最佳实践。 - 不引用无法复核的来源作为关键依据。 - 不为追新而改动稳定项目约定；必须说明收益和迁移成本。 - 不在交付中复制长篇外部文档；只保留必要结论和链接或文件路径。 - 不把“查过文档”停留在口头；版本敏感决策需要能追溯到具体版本、路径或官方页面。 ## Expected Output 输出来源清单、版本或项目事实、决策结论、实现影响、验证命令和未决风险。若修改代码，关键行为应有测试或构建验证支撑。