cfc/docs/tdd/orchestration/pending.md

主理人待办 / 协调清单（正式通道）

纪律：主理人写入并 push；每项必须有「主理人裁决」列，避免悬而未决。 编号单调递增（O-*），不复用、不跳号；与状态机解耦，不改变 state.json 的 stage。

编号	主题	涉及角色	背景与诉求	主理人裁决	记录时间	状态
O-1	TDD YELLOW 收口：研发 YELLOW 证据已齐（4 键/7 sha 在 origin/cfclub），但测试 --mark-green 复验被 B-10 P0 编译回归阻断	研发+测试	证据层已满足：研发负责人1（01:15 轮，6f86cae9a）确认 4 键置 YELLOW——dan.assessment.getActiveMaterial（c3e32460a）/ dimension.registry.getTree（57e162242）/ dimension.registry.mapLegacyCode（57e162242）/ health.report.createReport（1767d4414），4 键 DONE（addMember/listMembers/getPlanDetail 55caf6966/getPlanList）；7 个证据 sha 经测试侧逐条 git merge-base --is-ancestor 核验全部已在 origin/cfclub ✓。新阻塞：测试侧 01:36 复跑 16 契约测试 @ testCompile 因 B-10 编译回归（unit/CfBalanceControllerTest.java 7 处错误）BUILD FAILURE，无从验证、无法 --mark-green。诉求：① 研发优先修复 B-10（P0，改测试 7 处调用或回退 44b2f0d42）→ ② 测试复跑 16 契约 + 全量 surefire 后对 4 YELLOW 键 --mark-green 收口 → ③ 本地 state.json 3 键（createReport/getActiveMaterial/getPlanDetail）按 git 证据同步阶段	研发修复 B-10（P0，阻断全模块测试验证）→ 测试复验 mark-green；主理人裁决 B-10 优先级（高于普通任务，因连带阻断 4 YELLOW 收口）。升级 P1：YELLOW 证据已齐但复验通道被 P0 编译回归卡死	2026-11-05 05:37（测试负责人轮更新）	已裁决推进：B-10 已于 02:30 由研发正式修复（37f29a5df 推远端），测试侧 03:30/05:35 连续 2 轮复验 testCompile 205 源 0 错、16 契约 16/16 全绿，复验通道稳定；2 个 YELLOW 键（getActiveMaterial c3e32460a / createReport 1767d4414）测试 第 2 次独立复验通过，证据已推远端（研发 05:02 轮仍 2 YELLOW 待 mark-green）；待本地 state.json 与研发侧状态机同步后由测试 --mark-green 落库收口。08:12 测试侧更新：55 例契约测试（16 契约 + createTask 7 + review 32）全绿，2 YELLOW 键（createReport/getActiveMaterial）连续第 4 轮复验通过；2 个新 RED 键（createTask 2a1f72ff5 / review 291955bce）契约测试落地并实测全绿，8 sha 全部在 origin/cfclub；但本地 .tdd/state.json（3 伪 RED，11-04 10:14）与研发侧状态机（RED 2/YELLOW 2/DONE 9）键集与阶段深度不同步——测试侧 --mark-red（键不在状态机）与 --mark-green（当前 RED 须先 YELLOW）均被拒，落账缺口由 B-10 编译回归转为纯状态机同步缺口（责任：编排侧/主理人同步，非测试侧可自解）。10:45 测试侧更新：契约复验 8 类 71 例（68 绿/3 红，3 红全为 P-2 MapContract 口径），testCompile 216 源 0 错（B-10 连续第 5 轮无复发），2 YELLOW 键（createReport/getActiveMaterial）连续第 5 轮独立复验通过；研发 10:15 已 DONE 11/YELLOW 2/RED 0，SC-P-10/SC-P-11 已上线三端 200；--mark-green 实测仍被拒（本地 state.json 3 伪 RED 第 14 轮）。13:58 测试侧更新：契约复验 8 类 71 例（68 绿/3 红，3 红全为 P-2 MapContract 口径，与 10:45 轮完全一致，非新回归），testCompile 216 源 0 错（B-10 连续第 6 轮无复发），2 YELLOW 键（createReport/getActiveMaterial）连续第 6 轮独立复验通过；研发 13:26 已 DONE 11/YELLOW 2/RED 0 且 SC-P-10/11 已上线三端 200；--mark-green 实测仍被拒（本地 state.json 3 伪 RED 第 15 轮），缺口维持纯状态机同步（责任：编排侧/主理人同步）。16:59 测试侧更新（重大新发现）：独立 git merge-base --is-ancestor 复核发现研发登记的 2 个 YELLOW 实现 sha（1767d4414 / c3e32460a）均在 origin/cfclub 祖先链之外（提交时间 2026-06-09/06-12，git log origin/cfclub 无命中，仅存在于 cfclub-jiapu/recovered-* 旁支）→ 研发 14:59/16:45 汇报「4 sha 均在 origin/cfclub」与测试侧 13:58 记录均被推翻；而 RED 证据 sha（81d8883f7/faf3ca174）在链上 ✓。功能方法（getActiveMaterial/createReport）确认已合入 origin/cfclub 源头，但登记 sha 失效（疑历史 force-push/rebase 重写）。卡点由「纯状态机同步」升级为「同步缺口 + YELLOW sha 失效」双卡点：即使状态机同步，--mark-green 仍会因 git 真理校验拒绝。诉求新增：研发重新登记 origin/cfclub 祖先链上的有效 YELLOW 实现 sha 20:14 研发负责人1 澄清（双卡点实为单卡点·测试侧 16:59 判定为浅克隆假阴性）：上市重验（完整 sha 展开后 ① git rev-list origin/cfclub 前缀匹配 ② git merge-base --is-ancestor <full> origin/cfclub ③ git branch -r --contains <full> 三重验证）确认 1767d4414（createReport 实现）与 c3e32460a（getActiveMaterial 实现）均在 origin/cfclub 祖先链上 ✓。误判根因：本仓库为浅克隆（.git/shallow 边界 2026-10-24，e582b4b79…/e7b8d68bf…），git log origin/cfclub 默认不遍历浅边界前的提交 → 6 月提交（2026-06-09/06-12）grep 无命中，被误判「外链」；`log
O-2	SC 场景入池断层（顶层目标 P0）：SC 编号 → 能力键映射方案追认	研发+测试+主理人	DEV_GOAL_user_scenarios.md 要求 218 个 SC-角色-NN 作一级任务池，但 --add-task 的 KEY_RE 只接受 unit.domain.action，00:58~05:02 共 8 轮因此挂「待裁决」零派发（218 SC 停留 0/218）。本轮（05:25）按主理人「池空不收手·不留空闲」硬要求临时采用方案 A：场景→能力键展开——SC 编号与场景文件写进 --requirement，已合入 origin/cfclub 的设计契约写进 --design 并显式标注「实现仅在 feature 分支、不得假定包路径」，key 用合法 unit.domain.action 命名；已建 4 个 RED 任务（S-cfc-9~12：SC-G-02/SC-G-06/SC-P-03/SC-P-10）并全部派发。诉求：请主理人追认方案 A 为正本，或改判「放宽 SC 前缀」/「场景层测试侧先行」，以便 218 SC 全量入池	已裁决（2026-11-05）：方案 A 为正本（唯一入池路径）——SC 不作状态机键，--add-task 一律合法 unit.domain.action，SC 编号/场景文件入 --requirement；否决方案 B（放宽 SC 前缀，改 skill 全局 KEY_RE 污染所有项目 + SC=能力编排组合语义错位）；方案 C 降级为补充（仅 SC 已有实现但缺三类流执行证据时，测试侧补 e2e，不建伪能力键）。新增 SC 台账层（关键修正）：新建 docs/tdd/orchestration/sc-key-map.md 作为「SC 跑通」唯一计数来源，218 SC 全量登记，能力键 DONE ≠ SC 跑通（一 SC 可 N 键 / 一键可 M 个 SC，state.json 只证实现闭环）；「累计已跑通」= 三类流实际执行证据 + 实现/用例推 origin/cfclub + 工作区干净	2026-11-05 11:16（主理人）	已裁决（方案 A 为正本 + SC 台账层）
O-3	「SC 跑通」第三判据（工作目录干净）被主工作树卡死：5 SC 证据链齐备但无法转正	研发+主理人	11:15 轮起 5 个 SC（SC-G-02 / SC-G-06 / SC-P-03 / SC-P-10 / SC-P-11）已具备「三类用例实际执行证据 + 实现与用例已推 origin/cfclub」两判据，但第三判据「工作目录干净（--clean-check 退出码 0）」被主工作树 E:/cfc 持续未过：① git status --porcelain 20 处（M DEV_GOAL/pending.md 与 origin 一致仅本地落后；?? sc-key-map.md 等同 origin 版本；?? docs/参考材料/家庭归因分析-v2.x.* 属用户新交付产物；?? report-dev-0845/1015/1030.md）；② 本地分支 cfclub 含 2 个本地专属提交（3036a0bd4 主工作树 WIP 落库、ff6b3ff23 同步 .model_state.json），HEAD ff6b3ff23 落后 origin/cfclub（ae01be79d）3 提交且不在同一线性历史。按纪律主工作树严禁 checkout/stash/add -A，研发负责人无法自行清场。诉求：请主理人裁决 ① 是否同步主工作树到 origin/cfclub（协调 20 处 WIP + 2 本地提交归属）；或 ② 对「SC 跑通」第三判据改用「已推远端 git 真理」口径（origin/cfclub 干净、merge-base --is-ancestor 可核验），不依赖本机工作树；或 ③ 明确主工作树收口责任人	（待裁决）	2026-11-05 11:45（研发负责人）	待裁决
O-4	SC 基线演进 218→236 与 DEV_GOAL 顶层目标口径差异；SC-X-22（P0 跨角色 CF 预估）缺设计契约与用例	研发+测试+主理人	origin/cfclub 2026-11-05 午后新增 4 提交（53a74dd53/e927d7850/6a2345860/aa2a72268），场景基线 235→236；此前 08-butler.md（SC-B-01~12，空号 03/08）+ 09-human-butler.md（SC-H-01~07）合入，基线 218→235。sc-key-map.md 台账本轮已同步至 236（计数口径 + 18 行登记）。差异：① DEV_GOAL 顶层目标仍 218；② SC-B/SC-H 实现已在 origin/cfclub（controller/butler/ButlerController、controller/ai/AIChatController、entity/Butler* 等），仅缺三类流用例（按 O-2 方案 C 属测试侧）；③ SC-X-22（CF 值获取预估，P0 跨角色全局规范）为真契约缺口——后端 RewardRuleService/expectedCf 字段不存在于 origin/cfclub（仅前端 cfRule.js/CfRuleConfig.vue），且现有 CF 设计文档（2026-10-25-cf-value-single-source-of-truth/2026-09-01-cf-commission-redesign）均未定义 expectedCf 预估契约，TC-X-22 用例待补。诉求：① 确认顶层目标是否更新为 236（含 SC-B/H/X-22）；② SC-X-22 先立设计契约（docs/superpowers/specs/）+ 测试侧补 TC-X-22，二者齐备才可入 TDD 池派开发（防假 RED）；③ 刷新 O-3 现状（主工作树 26 处 WIP、本地 HEAD ff6b3ff23 落后 origin/cfclub 41 提交）	（待裁决）	2026-11-05 13:26（研发负责人）	待裁决