Spring Boot + MySQL 需求先行开发
先确认做什么，再用最少的代码把它做对。不得用脚手架、惯例或“最佳实践”替客户决定业务规则。
第一产物：需求快照
每次调用本技能，第一份产物必须是 docs/requirements/<项目或功能>.md 的新建或更新版本；无法写入项目时，在对话中给出完整草案及预定路径。按 requirements-template.md 选择最短适用格式：小改动写增量快照，新项目或跨模块需求写完整文档。
先做最小事实探测：相关构建文件、配置、迁移、接口、安全配置，以及前端 package.json、锁文件、入口、主题和公共组件。将信息分为：
- 客户已确认；
- 仓库已证实，并标注文件路径；
TBD，说明缺失信息会影响什么。
表名、字段名、旧代码和常见行业做法都不能单独证明业务规则。
需求门禁
只询问会改变业务行为、数据、安全、架构、依赖、成本或验收结果的问题。每轮集中问一至三个相关问题，给出有证据的选项、取舍和可撤销的推荐，但不得把推荐写成客户决定。
存在阻塞 TBD 时必须停在需求阶段，不写业务代码、不改表、不安装依赖。以下事项默认阻塞：
- 数据归属、状态流转、保留/删除规则；
- 角色、认证、授权和敏感信息边界；
- 不可逆迁移、金额、配额、外部系统；
- Spring Boot/Java 主版本或持久化方案的新增/切换；
- 新前端的框架、主组件库和布局方向；
- 没有可验证的验收标准。
如果没有阻塞项，且客户已经明确要求实现，可在交付需求快照后继续执行，无需为低风险事实重复索要确认。客户修改需求后，先更新文档和变更记录，再继续。
技术与 UI 选择
新项目或确需改变技术基线时，提供二至三个与约束相容的方案，核对当前官方资料、项目依赖或锁文件，不使用记忆中的版本号。至少明确 Java/Spring Boot、Maven/Gradle、JPA/MyBatis、迁移工具、认证方式和运行环境；已有项目优先沿用已证实的约定。
涉及前端时同时读取 frontend-sources.md 与 ui-delivery.md：
- 已有主组件库且未要求迁移：复用它，不制造选择题；
- 新前端或明确换库：给客户二至四个经官方验证、与框架兼容的大厂组件方案，以及二至三个布局方向，等待客户选择；
- 同一应用默认只用一个主 UI 库；无法核实厂商归属、包名、版本、许可证或 API 时标为未验证，禁止编造。
- 选定后先把页面能力映射到真实组件、交互状态和设计令牌，再写布局计划与页面代码；只有重复使用或承载稳定业务规则的组合才封装为业务组件。
多技能协作
当多个本地技能同时匹配时，读取 skill-coordination.md。本技能统一管理需求快照、TBD、客户决定、开工门禁和完成证据；其他技能只提供对应阶段的专项能力，不能绕过门禁，也不能把示例默认值直接写进项目。
不得自动合并多个脚手架、持久化方案、响应协议或前端组件库。冲突会影响结果时，先按已确认需求与仓库事实裁决；仍无法裁决则询问客户。
最小实现
确认需求后读取 springboot-delivery.md。按以下顺序选择方案：
- 需求是否真的需要这项能力；
- 项目是否已有可复用实现；
- Java、Spring Boot、MySQL 或浏览器原生能力能否完成；
- 已安装依赖能否完成；
- 最后才添加最小的新代码或依赖。
不得为“以后可能需要”创建抽象、模块、配置或目录。新项目也只生成当前需求会使用的包和依赖；Redis、AOP 日志、Knife4j、第三方工具包、自定义响应壳、Service 接口/单实现等均不是默认项。
不能为了少写代码删掉边界校验、授权、数据一致性、迁移安全、错误处理和无障碍基础。
验证与交付
每条验收标准都要对应证据。执行与改动相称的最小验证：编译/构建、相关自动化测试、迁移与约束检查、API 成功和失败路径；有 UI 时使用真实浏览器验证加载、空、错误、权限、溢出、键盘和响应式状态，并保留关键截图或测量结果。非平凡逻辑至少留下一个能复现失败的最小测试。
交付内容保持简短：
- 需求文档路径、版本和决策；
- 变更文件与数据影响；
- 验证命令、结果和必要截图；
- 明确列出未验证项、剩余风险和回滚方式。
没有证据不得声称完成。无法核实的版本、API、包、性能数据、客户偏好或业务规则必须明确写为 TBD 或未验证，禁止胡编乱造。
