Feature Point Implementation - 基于开发规格的功能点实现

输入: spec.md(开发规格) | checklist.md(验收标准) | test-cases.md(测试用例,可选) | ui/DESIGN.md(界面设计规范,前端必读) 输出: 代码文件 | 验收报告

技能集成

• software-engineer：代码实现、单元测试、重构、缺陷修复
• 专家（按需）：expert-ruoyi（若依）、expert-activiti（工作流/BPMN）、expert-mysql（SQL）、expert-code-quality（质量）

流程步骤

1. 读取开发规格：从 dev-specs/FP-{序号}/spec.md 读接口/数据模型/业务逻辑/测试用例
2. 读取界面设计规范（前端前置，v3.3.0）：检查项目根 ui/DESIGN.md 是否存在——存在则前端编码前必须通读：颜色 token、状态色板（状态→色族映射）、间距密度（4px 基准）、组件模式、Element Plus --el-* 变量覆盖；生成的前端必须与 DESIGN.md 对齐，状态值显示用「彩色圆点+中性文字」而非色字。不存在则输出一次提示 未找到 ui/DESIGN.md，建议先运行 /pdd-design-spec 生成界面设计规范（WARN，不阻塞后端实现）
3. 上下文注入（关键）：生成代码前扫描项目已有代码，避免孤岛效应——扫描 models/ 的Model、api/ 的路由、schemas/ 的Schema、config/bug-patterns.yaml 的Bug模式、PRD命名约定；建立{后端路径→前端调用文件}映射、{状态值→使用文件}映射。确保 new代码正确import、路由不冲突、Schema字段一致、前端API路径与后端Controller一致、新增状态值各映射文件同步（防 PATTERN-C4/C3/002/R008/R011）。
4. 读取验收标准：checklist.md
5. 确定实现顺序：数据模型→数据库脚本→后端接口→前端页面
6. 生成数据库脚本：SQL 含审计字段 create_time/update_time/create_by/update_by/del_flag/status
7. 生成后端代码（委托 software-engineer）：Domain(@Data/@TableName) | Mapper(@Mapper/BaseMapper) | Service(@Service/ServiceImpl) | Controller(@RestController/@RequestMapping)
8. 生成前端代码（委托 software-engineer，遵循 DESIGN.md）：API(request封装) | Vue组件——布局密度/间距用 DESIGN.md spacing token、状态标签用状态色板映射表、交互模式用 pattern-library 对应模式
9. 实现业务逻辑：处理流程/校验规则/状态转换/异常处理
10. 微验证（关键）：每完成一个功能点立即执行（约30秒）——①后端启动 python -m uvicorn app.main:app --reload 无报错 ②GET /docs 可见Swagger ③Schema创建+查询各1次确认datetime/Enum序列化 ④npm run build 无报错 ⑤curl GET /{module}/options 返回非空。失败必须立即修复，不得继续下一个功能点。
11. 运行完整测试：单元/接口/集成测试
12. 更新验收状态：更新 checklist.md
13. 生成验收报告：业务验收/技术验收/问题日志/结论

代码标准

• 后端：类名PascalCase、方法camelCase、常量UPPER_SNAKE_CASE、Javadoc注释
• 前端：组件PascalCase、方法camelCase、CSS类kebab-case、ES6+
• software-engineer 标准：先读现有代码风格、错误处理优先、保持最小化、PR-ready

PR管理提示（不自动调用）

功能点完成后提示用户可手动调用：/pdd-pr-create {change-id}、/pdd-pr-review {change-id}、/pdd-pr-merge {change-id}。PDD框架不会自动调用 pdd-pr- 技能，需用户手动决定。*

错误处理与回退

• 错误分级：Critical(阻塞)/Warning(非阻塞)/Suggestion(可选)
• 重试策略：每功能点最多3次，超限暂停等人工决策
• 回退：code-reviewer审查失败→返回重新实现；verify-feature验证失败→返回重新验证
• 失败记录：dev-specs/FP-{模块}-{序号}/review-report.md（时间/阶段/原因/次数/日志）

Guardrails

• 代码符合项目标准；实现规格所有接口与异常；通过全部验收项才算完成；变更后同步更新规格文档
• 遇到技术问题必须咨询专家；代码实现遵循 software-engineer 标准；完成后提示PR管理但不自动调用

Iron Law 铁律

1. 规格即法律：严格遵循 spec.md，不擅自添加，不遗漏接口/字段。
2. 委托不替代：框架特定问题必须调用对应 expert 技能。
3. 错误处理优先：先做参数校验/异常/边界，不只写"快乐路径"。
4. 代码标准对齐：风格与项目一致，先读同类模块现有代码。
5. 验收驱动开发：每完成一个接口立即对照 checklist 自检。
6. 上下文感知生成：生成前扫描已有 Model/Schema/路由，避免孤岛效应。
7. 微验证即时反馈：每功能点必须微验证，不得跳过。
8. Bug模式库约束：遵守 config/bug-patterns.yaml，已知陷阱不重复触犯。
9. 设计规范对齐（v3.3.0）：ui/DESIGN.md 存在时前端必须对齐其 token/状态色/密度/模式；不得凭感觉自造颜色与间距。

• 违规：❌功能蔓延 ❌不调expert-ruoyi ❌只写正常流程 ❌命名风格不一致 ❌写完才运行发现编译错 ❌不扫已有代码 ❌跳过微验证 ❌datetime声明为str(PATTERN-001) ❌/options在/{id}后(PATTERN-002) ❌无视DESIGN.md自造样式
• 合规：✅按spec接口列表逐一实现 ✅调expert-ruoyi ✅Service方法开头校验参数 ✅先读TransferApplyController保持风格 ✅逐个Controller方法测试 ✅生成前扫models/、schemas/ ✅每功能点微验证 ✅datetime用field_serializer ✅/options在/{id}前 ✅前端编码前先读ui/DESIGN.md

Rationalization 陷阱

• "规格偏离"：实现逐渐偏离规格→建立实现清单逐项打勾对照
• "框架硬扛"：反复尝试不求助→"3次尝试规则"，3次未解决必须调expert
• "快乐路径"：只实现正常流程→每个public方法必须有try-catch
• "风格割裂"：新代码与项目风格不一致→"先读后写"

Red Flags 红旗

• L1 输入：INPUT-IMPL-001 spec/checklist 不存在→🔴；002 spec缺接口/数据模型→🔴；003 项目路径不可访问→🔴
• L2 执行：EXEC-IMPL-001 实现规格外接口→🟡；002 框架问题未调expert硬编码→🔴；003 空指针风险→🟡；004 SQL注入→🔴；005 未扫描已有代码(Step 3)→🔴；006 跳过微验证(Step 10)→🔴；007 DESIGN.md 存在但生成前端未对齐（自造颜色/间距/状态标签样式）(Step 2)→🟡
• L3 输出：OUTPUT-IMPL-001 语法错误→🔴；002 规格接口未全实现→🔴；003 路径不符→🔴；004 datetime为str(PATTERN-001)→🔴；005 /options在/{id}后(PATTERN-002)→🔴
• 处理：🔴立即停止上报 | 🟡记录警告尝试修复 | 🔵记录正常继续