7f24a344d0
承接目录治理：上轮只压缩内容未减文件数，闭线工作记录仍平铺致目录看着仍一堆(创始人指出)。本次执行 B2 归档。 64 个 ≤06-15 闭线档(25 压缩桩 + 闭线 review/report/纪要/edit-plan)git mv 入 docs/agent-specs/_archive/(文件名不变、仍 git 跟踪可查)。热目录 ≤06-15 仅留 13 活档(决策/纲领/SoT/活spike)+13 个 06-16 在飞。 活资产 20 处旧路径引用(.agents/docs/memory/_index)同步改 _archive/，引用断裂复测=0；_index 活地图 + 治理档状态收口。约束：0 个 06-16 被移、orchestrator 等未跟踪在飞档零误纳。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
16 KiB
16 KiB
Wave4（community + biz）评审版 spec · 两轮对抗评审纪要
关联 spec：
2026-06-11-Wave4-community-biz-review.md（编号 HJ-WAVE4-001） 类型：评审纪要（findings 列表 + 逐条处置存档）｜ 2026-06-11 范围：第一轮（R1，24 条）+ 第二轮（R2，6 条）对抗评审 findings 全量列出与逐条处置。 结论：两轮全部接受或部分接受/重定向，无「拒绝」条目；spec 已据此定稿（状态=已定稿待创始人拍板）。 说明：spec 正文末已内嵌「评审整改纪要（R1）」「评审整改纪要（R2）」两段为 spec 自洽；本文是独立存档，把两轮原始 findings 与处置归并一处，供审计与后续波次复用。
0. 两轮总览
| 轮次 | findings 数 | 严重度分布 | 处置结论 | 最大变更 |
|---|---|---|---|---|
| R1 | 24（含合并近重复） | blocker×1 / high×多 / medium×多 / low×多 | 全接受/部分接受/重定向，无拒绝 | community 触达机制定型=同进程 -api notify-push（取代「事件驱动/MQ」含糊口径），消除 MQ/事件契约整组前置依赖 |
| R2 | 6 | medium×2 / low×4 | 全接受（含 1 条事实订正后仍采纳改进诉求），无拒绝 | 校正 6 处精度/口径 + 新增 §0.1 三项战略决策置顶（D-A biz 形态 / D-B community 优先级 / D-C ip seam 是否本波接） |
两轮共性：findings 多为「口径不一致 / 落点不精确 / 缺中央登记 / 范式引用错」类精度问题，无方向性推翻——印证「克隆零创新」范式判断成立。R1/R2 各有 1 条触及事实订正（R1：无 ProjectStateService.java；R2：M5 实有定义），均以「采纳问题但按实情调整解法」处置。
1. 第一轮（R1）findings 逐条处置
处置口径：接受=已改对应节；部分接受/重定向=采纳问题但解法按实查证据调整；拒绝=保留原口径（本轮无）。多条近重复 finding 合并处置（标 ⊃，主条吸收子条）。
1.1 贯穿性裁决（一处定死多条收敛）
本轮多条 finding（blocker events.schema.json / high「事件基建不存在」/ R1 风险项 / 多条 medium 触发机制）实为同一未决架构点的不同侧面：community 用什么机制触达。R1 据实查证据一次定死 = 同进程 -api notify-push（spec §3.3）。连锁后果：
- (a) community 不走 events.schema.json，故 blocker「先在 events.schema.json 注册三事件」的前置门禁不再需要——底层关切（只改契约不改枚举=静默 rejected）以「保留口径」写入 §3.3 备未来 MQ 路线；
- (b) 上游不发域事件，改为新增 3 个 notify 调用点，工作量画像在 §3.3 表与 §4 显式登记；
- (c) INC-01 计数权威源改 project、记账留 M4，消除孤儿子链路。
1.2 R1 逐条表
| # | Finding（severity｜定位） | 处置 | 改了哪 / 理由 |
|---|---|---|---|
| R1-1 | 事件基建整体不存在，应框为「机制未建+选型未定」（high｜§2.2/§3.3/R1） ⊃ blocker（events.schema.json 三事件未注册） ⊃ medium（事件消费手工触发形态未明） | 接受（核心整改） | §0/§2.1/§2.2/§3.3 全面重写：机制定型为同进程 -api notify-push；§3.3 新增四维对比表+工作量画像+staging mock-trigger 端点；R1 风险行改「已缓解」。blocker 关切以「保留口径」并入 §3.3，不再设 events.schema.json 前置门禁 |
| R1-2 | P-INC-01 触发+记账依赖 trade 发放/feed 流量是半截孤儿链路（medium｜§2.2/AC-CMU-5） ⊃ high（feed 流量包/trade 发放无 -api 契约） ⊃ medium（INC-01 计数权威源歧义 A/B） | 接受 | §2.2 新增「P-INC-01 落地形态」：计数权威源定为 project 发布成功（二选一 project notify / ProjectApi.countPublishedByCreator），不依赖 feed 计数 seam；「记入钱包/流量包」本波只写自有 reward 触发表，跨模块写留 M4；AC-CMU-5 收紧 |
| R1-3 | AC-BIZ-3/5 硬依赖 game-admin UI 而 admin 端零视图（medium｜§6.2/R5） ⊃ high（AC-BIZ-5 依赖 WS4 未排期 UI 违反独立可交付） | 接受 | §6.2 加「UI 落点与跨工位」说明 + AC-BIZ-3/5 拆两层（后端 API 本波独立验收 / UI 入口列增强项绑 WS3·WS4 走 UI 走查）；§1 非目标补「两类债分开记账」；§7-6 同步 |
| R1-4 | biz 模板预览只描述 happy path，缺取包失败影子路径（medium｜§2.3/AC-BIZ-2） | 接受 | §2.3 加「B-02 模板预览影子路径」（无产物/编译失败/versionId 缺失降级 + 状态机不许无 demo 推进）；AC-BIZ-2 补负路径必验 |
| R1-5 | Flyway V12/V13、错误码、yaml 文件名缺中央预占登记动作（low｜§4/R6/R8/§8） | 接受 | §8 新增「§0 全局单序列资源预占登记」为 execution 开篇第一节（字节一致 + 前置校验 + 单 agent 收口） |
| R1-6 | 异步写链路 staging 实测未点名 community 通知/biz 状态机两条（low｜§6.3/R3） | 接受 | §6.3 把两条异步/系统身份写链路逐条点名为必测项；R3 同步具体化 |
| R1-7 | §2.4「唯一公共装配点」与 §4 blast radius 不一致，漏 root 聚合 pom（high｜§2.4/§4） ⊃ high（克隆 pom 注册点不清，未明 game-cloud vs huijing-server） | 接受 | §2.4 改「公共装配点=两处」（① root game-cloud/pom.xml 注册 <module> ② huijing-server/pom.xml 注册 -server 依赖）；§4 首行同步；§8 把 root pom 注册列独立一步 |
| R1-8 | P0 计数术语含糊，未陈述 Wave4 总新增 P0 数（high｜§2.3/§7-4） | 接受 | §0 与 §2.3 明确「Wave4 总交付=11 P0=community 5 + biz 6；P-BIZ-11 经 Doc C 划归 compliance（compliance +1）」；§7-4 同步 |
| R1-9 | BIZ-02 轻量状态机「替代 BPM」是缩水还是等价替代表述不清（high｜§2.3/R2） | 接受 | §3.1 新增「轻量状态机 vs BPM 等价替代而非缩水」澄清段（本波 6 P0 仅需单线性五态、多线流程留 M4+Flowable）；R2 风险行重写 |
| R1-10 | Flyway V12/V13 三处一致性未验证（medium｜§4/R6/§6 脚注） | 接受 | §6 脚注记两处 ceiling=V11 一致；§8 §0 补 grep 校验 + 字节一致校验 |
| R1-11 | BIZ-03 客户端入口形态未明（medium｜§2.3/§6.2） | 接受 | §2.3 表 P-BIZ-03 + AC-BIZ-3 明确客户侧入口=game-studio /biz-orders/my-orders（WS3）或邀请链 |
| R1-12 | §1 非目标（资金流 M4）与 R5（UI 入口缺失）混为一个债项（medium｜§1/R5/§7） | 接受 | §1 非目标新增「两类留债分开记账」（①资金流债→M4 ②前端 UI 入口债→跨工位并行）；§8 M4 留债段同结构分离 |
| R1-13 | feed↔community 计数回流机制不清（反写/读表/异步事件）（medium｜§4） | 接受（重定向） | 采纳「机制须写死」，但计数权威源改 project 后此 seam 取消：§4 加澄清「feed.yaml line84 指归属权非反写」，旧「feed 信号→community 计数串行依赖」项删除 |
| R1-14 | §6.3 工程门缺 exact CLI（medium｜§6.3） | 接受 | §6.3 补三组精确 CLI（mvn -DskipTests clean install -pl ... -am / curl .../v3/api-docs?group=community / staging 两链路实测） |
| R1-15 | §8 遗漏 Nacos 模块配置注册落点（low｜§8） | 接受 | §8 补 Nacos 配置注册条（community.sms.enabled / community.level.publish-threshold / biz.state-machine.timeout-hours + deploy/nacos 导入验证） |
| R1-16 | P-BIZ-12 P0 子集「可下单+进度看板」模糊、与 01/03 是否重叠（low｜§2.3/§7） | 接受 | §2.3 表 P-BIZ-12 + AC-BIZ-6 + §7-5 收紧为「场景需求 CRUD + 模板复用 + 专属看板（与 01/03 同能力栈、无额外定制）」；P1 列 M4 |
| R1-17 | T-PRJ-06 轻量状态机引用不精确，缺代码路径（low｜§2.4/§3.1/§8） | 接受（含修正事实错误） | 实查无 ProjectStateService.java——全文将「复用 T-PRJ-06/ProjectStateService」更正为「复用 project 范式=ProjectStatusEnum（流转判定）+ ProjectServiceImpl（写前流转校验）」（§2.1/§2.3 图/§2.4/§8）。原 finding 建议落点亦不存在，按实情改 |
R1 小结：24 条（合并后呈 17 行，含 ⊃ 吸收的近重复子条）全部接受/重定向。3 条（R1-13 feed↔community 计数机制、R1-1 内 blocker events.schema.json 前置门禁、R1-17 T-PRJ-06 引用）采纳问题本身但解法与原 suggestion 不同——实查证据显示原 suggestion 落点（feed 反写 / events.schema.json 路线 / ProjectStateService.java）与本仓现状或更优范式不符。
2. 第二轮（R2）findings 逐条处置
输入：R2 findings JSON（6 条：medium×2 + low×4）。每条均先实查仓库核实再处置，逐条证据见 §3「R2 实查证据」。
| # | Finding（severity｜定位） | 实查核实结论 | 处置 | 改了哪 |
|---|---|---|---|---|
| R2-1 | §8 §0 预占校验 grep -r 'V12|V13' 不返 0（会命中 V11 让位声明注释 2 行），实现者开篇第一步被自身注释绊住（low｜§8 §0 行334） |
属实：实测返 2 行（V11…invite.sql:13 两处副本各一行，内容匹配非文件名匹配）；ls V12*/V13* 实测 exit=2 空 |
接受 | §8 §0 校验改「按文件名」：ls contracts/db-schemas/V12* … V13* …（应空/exit≠0）；显式标注「不要用 grep 内容匹配，命中仅 V11 让位声明注释属预期非占用」；错误码段仍用 grep -rn '1_107|1_110'（应返 0） |
| R2-2 | add-business-module.md 旧版仅列「步骤5=huijing-server pom」、未把 root game-cloud/pom.xml <modules> 注册列独立步，与 spec §8「装配点=两处」口径不一致，只读 skill 者漏 root pom 注册触发 compile 失败（low｜§2.4/§8/skill 行66） |
属实：grep 'game-cloud/pom.xml|<modules>|聚合 pom' 该 skill 零命中；步骤表开头明写「无需改 Application/yaml，只需 huijing-server/pom.xml 加依赖」 |
接受（不改 skill 内容、加 spec 提示——回写 skill 维持「本波收口后」原计划，避免开工前动 canonical） | §2.4 加 ⚠️ 硬提示：『skill 步骤表尚未含 root pom 注册（待本波收口回写），本波克隆以本节「装配点=两处」为准，勿以旧 skill 为唯一依据』；execution 版克隆步骤开篇须复述 |
| R2-3 | biz 取包端点写 /app-api/runtime/package/{versionId}，真实路由带 /manifest 后缀；属端点精度问题不影响可行性结论（low｜§2.3 B-02 行161/AC-BIZ-2 行293） |
部分属实：实查 AppRuntimeController 两端点都存在——GET /package/{versionId}(line60, 清单 meta)+GET /package/{versionId}/manifest(line75, 原始 JSON)；原稿写的是真实端点之一，但漏列 /manifest 那条 |
接受（按真实双路由钉准，不止补 /manifest） | §2.3 B-02 新增「取包端点真实路由」段（两端点真实路由+用途+门禁同源）；AC-BIZ-2 同步双路由；提示 execution 版端点清单两条写全 |
| R2-4 | §266 兼容性段把 events.schema.json 列为「须串行收口的公共写点」，与 §239/§322「本波零改该文件」自相矛盾（medium｜§266 vs §239 vs §322） | 属实：§239 影响面表标「本波零改/无」、§322（§7-7）标「本波不改」，§266 却列入公共写点 | 接受 | §266 改写：公共写点仅 root pom/huijing-server pom 须串行收口；events.schema.json 本波零改、无写点竞争、不在串行收口范围（显式标 R2 校正消歧义） |
| R2-5 | §7 第 2 项「community 被 M5 依赖」中 M5 未在全文定义，理由对拍板无参考且不可验证（medium｜§312 待确认项 2） | 订正：M5 实有定义（mvp-scope-and-milestones.md:101/MVP进度总账.md:32=MVP 全链路交付里程碑 6/27 Day15）；但「被 M5 依赖」确属同义反复（M5 含全部模块） |
接受（采纳 suggestion(b)：改自洽可验证表述） | §7-2 改：以「触达机制最独立、无外部业务卡点、复用面集中、风险最低」排序；补注 M5 定义 + 说明不以「被 M5 依赖」作依据（同义反复） |
| R2-6 | P-INC-01 计数权威源「二选一」(project notify vs ProjectApi.countPublishedByCreator) 在待确认项未显式决策，execution 期或重复思考（low｜§2.2/§7-2~4） | 属实：原稿仅在 §2.2 正文列二选一，§7 无对应决策行 | 接受（采纳 suggestion：补 §7 决策点 + 标「可由 execution §0 单 agent 直接拍 (a)」） | §7 新增第 8 项（计数权威源二选一，推荐 (a) project notify，标可单 agent 定无须创始人介入）；§8 §0 同步标「单 agent 拍 (a)」 |
R2 顺带补强（非 finding 直接要求，同一处自洽性收口）： ① 新增 spec §0.1「待创始人拍板的关键决策」汇总段，提炼 D-A（biz 形态）/D-B（community 功能优先级）/D-C（ip seam 是否本波接） 三项战略决策置顶供拍板； ② §7 表给战略项标 ⭐ 并与 §0.1 互链，区分「创始人决策项 vs execution 单 agent 可定的实现细节」； ③ 据实查（D5 决策「ip 寄宿 compliance」+ Wave4 仅 P-BIZ-02 沾 T-IP-09 且本波复用 aigc 模板绕开）补 D-C 推荐「本波不接 ip seam、维持 D5 推迟」，并入 §7 第 10 项。
3. R2 实查证据（2026-06-11 仓库核实）
| 证据 | 命令 / 文件 | 结论 |
|---|---|---|
| ① §0 预占校验口径 | grep -r 'V12|V13' contracts/db-schemas/ game-cloud/huijing-server/.../db/migration/ |
返 2 行（V11.0.0__create_passport_player_invite.sql:13 让位声明注释，两处副本各一行），非「应全返 0」；ls V12*/V13* 实测 exit=2、空（确未占用）→ 改按文件名判定 |
| ② runtime 取包真实路由 | AppRuntimeController.java |
两端点：@GetMapping("/package/{versionId}")(line60, 返 RuntimePackageRespVO 清单 meta) + @GetMapping("/package/{versionId}/manifest")(line75, 返原始 JSON)；门禁同源（同走 getPackageManifest 做 scene+status 权威判定）。原稿写其一、漏 /manifest 那条 |
| ③ skill 缺 root pom 注册步 | .agents/skills/add-business-module.md 步骤表（行66 起）；grep 'game-cloud/pom.xml|<modules>|聚合 pom' |
步骤表仅「步骤5=huijing-server/pom.xml 加 -server 依赖」，开头明写「无需改 Application/yaml」；root pom 注册 零命中 → skill 待本波收口回写，本波以 spec §2.4「装配点=两处」为准 |
| ④ M5 定义 | .agents/knowledge/mvp-scope-and-milestones.md:101 / docs/mvp/MVP进度总账.md:32 |
M5=「MVP 交付」全链路交付里程碑（6/27 Day15）。M5 有定义，但「community 被 M5 依赖」属同义反复（M5 含全部模块）→ 改独立性/风险理由排序 |
| ⑤ ip seam（D-C 决策证据） | docs/mvp/MVP进度总账.md:53/:95；需求模块映射.md:207 |
D5 决策「ip 不独立建、seam 寄宿 compliance」、line95 标推迟 TODO；Wave4 11 P0 中仅 P-BIZ-02 协同含 T-IP-09 模板市场，community 5 P0 零 ip 关联；本波 P-BIZ-02 复用 aigc 4 模板即不触 T-IP-09 → D-C 推荐「本波不接、维持 D5」 |
| ⑥ §266 矛盾 | spec §239 / §266 / §322 | §239 影响面表标 events.schema.json「本波零改/无」、§322（§7-7）标「本波不改」，§266 却列入「须串行收口的公共写点」→ 自相矛盾，已订正 |
4. 拍板与遗留
- 拍板项（创始人，详见 spec §0.1 + §7 标 ⭐ 行）：
- D-A biz 形态：轻量 lead form 先行（推荐）vs 全 biz；
- D-B community 功能优先级：通知底座最小集（推荐）vs 全量 T-CMU；
- D-C 是否本波即接 ip seam（寄宿 compliance）：推荐本波不接、维持 D5 推迟。
- 可由 execution 版单 agent 直接定的实现细节（spec §7 未标 ⭐ 行）：建设次序（先 community）、P-BIZ-12 P0 子集、UI 入口排期、并行/串行收口、P-INC-01 计数权威源（拍 (a) project notify）。
- 残留风险（不阻塞拍板，execution 期管控，见 spec §5 R1-R10）：匿名/非 Web 线程写审计列雷（staging 必测两链路）、Flyway 撞号、@Primary Bean 冲突、错误码段误复制、「骨架编译过≠真实可验收」。
- 收口回写计划：Wave4 收口后把克隆实证回写
.agents/skills/add-business-module.md（107/110 升「已落地」、补 root pom 注册独立步、补「跨模块通知优先同进程-apinotify-push 而非 MQ」范式）+ 新踩坑，更新.agents/README.md索引。