easysdd-feature-acceptance

到这一步代码已经写完了，但流程没结束。这一阶段做三件事，缺一不可：

1. 核对实现有没有偏离方案——逐层对照 {slug}-design.md 的四个节，发现偏差当场修，**不是在报告里"记一下"**就过去
2. 把 feature 归并到整体架构——对照方案 doc 第 4 节，实际去更新架构中心目录下的相关 doc
3. 把变化回写到 requirement——对照方案 doc frontmatter 的 requirement 字段，如果本次实现改变了对应 req 的用户故事 / 边界 / pitch 表述，触发 easysdd-requirements update 把 req doc 一起刷新（纯重构无 req 的 feature 跳过这步）

为什么这三件事都重要？只做第一件，新功能加进去了但项目级架构 doc 还说着老结构，下一个 feature 的设计阶段读到的就是过期信息。漏掉第二件，可能把"实现已经偏离方案"的事实掩埋——架构 doc 写得很漂亮，代码却不是那么回事。漏掉第三件，对外讲这系统"能做什么"的那份文档会慢慢和实际能力脱节，下一个用户来看的时候对不上。

验收报告是工作流的闭环凭证。没产出报告 = 工作流未完成。这条不是仪式——后人查"上次这个功能到底验收时确认了哪些行为"，没有报告就只能去翻 git diff 重新推断。

共享路径与命名约定看 easysdd/reference/shared-conventions.md 第 0 节。

跟 design 的章节强依赖

本技能整套对照表、模板节、提示语都按 design 当前的章节编号和命名硬编码。design 那边重构章节名 / 调整编号，本技能必须同步——否则下面所有"第 X 节 XX"指针都会指错地方。