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（研发负责人）	已裁决（2026-11-06 主理人收口 ffafdb214：判据③细化为「SC 关联提交级」核验——该 SC 的实现/用例提交须为干净提交且已推 origin/cfclub，主工作树其他会话/其他域未提交改动不计入；5 个 SC 转正跑通，累计已跑通 0→5，阻塞 5→0，DEV_GOAL §4.3/sc-key-map 已同步）**
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（研发负责人）	已裁决（2026-11-06 主理人收口 0a50c44cc：顶层目标 218→236 落地，sc-key-map 全量登记同步；SC-X-22 真契约缺口按项登记待补契约+用例后入池）**
O-5	主工作区 WIP 阻断 cfc-backend testCompile（11 个 integration 测试文件未提交）	研发+测试+主理人	主工作区 mvn testCompile 失败：ArticleControllerTest.java:201/215/226 三处编译错误（recordRead 找不到符号，位置 OngoingStubbing<ArticleService>）。根因：11 个 integration 测试文件未提交 WIP，其中 WIP 写法 when(articleService).recordRead(...) 属 Mockito API 误用（when(mock) 返回 OngoingStubbing，无 recordRead 方法），正确写法为 when(articleService.recordRead(...)).thenReturn(...)。测试侧已在干净 worktree（origin/cfclub e4ce9f80a）旁路完成全量 231 类 / 1847 例 / 93.50%（红类 36 / 红例 116），证明非主线回归。诉求：① 研发按正确写法收口 11 个 integration 测试文件；② 是否将「主工作区测试 WIP」纳入 O-3 判据口径；③ 收口顺序：testCompile 0 错 → 全量复跑与 worktree 基线逐类对账	已裁决（2026-11-06 21:50 研发负责人 错峰03·第39轮）：① 主工作区测试 WIP 非主线回归——测试侧已在干净 worktree（origin/cfclub e4ce9f80a）旁路完成全量 231 类/1847 例/93.50%，按 O-3 判据口径（主理人 ffafdb214 已裁决：SC 关联提交级核验、主工作树其他会话未提交改动不计入）不影响 SC 跑通与里程碑判定；② 11 个 integration 测试文件（含 ArticleControllerTest.java:201/215/226 三处 when(mock).method() Mockito 误用）收口归产生 WIP 的研发会话/研发负责人1，按正确写法 when(articleService.recordRead(...)).thenReturn(...) 修正后提交推送——本自动化轮按纪律④不代提交他人 WIP；③ 收口顺序：testCompile 0 错 → 全量 surefire 与干净 worktree 基线（231 类/1847 例/93.50%）逐类对账	2026-11-06 19:10（测试负责人；20:20 细化重建）	已裁决生效（主理人 2026-11-07 03:5x 最终确认）：39 轮裁决意见正式生效——① 主工作区测试 WIP 按 O-3 判据口径（ffafdb214：SC 关联提交级核验）不计入 SC 跑通与里程碑判定；② 11 个 integration 测试文件（含 ArticleControllerTest 三处 Mockito 误用）收口责任维持研发负责人1（截至 03:53 复核：git log --since 21:00 -- *Test.java 无收口提交、115 处他人 WIP 仍含相关文件，本自动化按纪律④不代提交他人 WIP）；③ 收口序不变：testCompile 0 错 → 全量 surefire 与干净 worktree 基线逐类对账
O-6	dispatch.py _git_evidence_sha 证据误配缺陷（P1）：S-cfc-21~26 假标 done 根因未清	研发+主理人	第 38 轮实证取证：.workbuddy/dispatch.py _git_evidence_sha()（L187）仅按 任务号/能力键 grep commit message 取首个 sha、不校验触及文件类型 → S-cfc-21~26 被 backfill 假标 done @ d76d24dcac00/96113648efdc（两者均只触 docs/tdd/orchestration/report-*.md 汇报文档，message 含键名即被误配为实现证据），并派发 1 条无效 testing 部署；15:20 主理人裁决已修复 tdd_orchestrate.py 的 git_evidence()/commit_kind()（7 处）但 dispatch.py 独立函数未覆盖；当前 state.json yellow_sha 已外科式回正（admin.auth.login→6c7e09fe8、health.report.upload→78b72c14f，均 IN CHAIN 复核 ✓），但脚本缺陷潜伏，未来任何派发+backfill 仍会误配。诉求：裁决修复方案并派发脚本修订	已裁决（2026-11-06 21:50 研发负责人 错峰03·第39轮，待主理人派发执行）：修复 _git_evidence_sha()——grep 命中后须用 git show --name-only 校验触及文件类型：YELLOW/GREEN 证据须触 src/main（或 cfc-frontend/src、cfc-web/src、danshop/src 等 main 归口）、RED 证据须触 src/test、docs/ 类汇报文档提交一律跳过；修复后回归核验 S-cfc-21~26 证据 sha 回正（→ 6c7e09fe8/78b72c14f 等实现提交）；修订属工具脚本层（非业务代码），走主理人通道派发	2026-11-06 21:50（研发负责人 错峰03）	已裁决推进（裁决已给：grep 命中后须校验触及文件类型，docs/ 跳过；待主理人派发脚本修订）
O-7	契约补建工作流启动与授权追认：B-1/B-2 开工包 66 SC 端点已 100% 实现（本轮核实 0 缺失），契约补建 = 文档核对 + 测试侧补证据，非研发实现型 RED	研发+测试+主理人	22:11 b6c0e6209 落库 216 个待契约 SC 契约补建计划（15 业务线，P0 133 / P1 40 / P2 43）；22:23 ac1329316 落库 B-1 开工包（测评-方案 43 SC / 44 建议能力键）+ B-2 开工包（报告闭环 23 SC / 19 键），均锚定现有 Controller 端点。本轮核实：B-1 契约接口范围 54 端点 + B-2 端点与 origin/cfclub 359 Controller / 1940 映射端点逐一比对，缺失 0（含 butler 域 ButlerController/FamilyButlerSelectController），即 66 SC 对应接口全部已实现，无真实现缺口。诉求：① 追认契约补建工作流授权（契约定一批→映射入池→测试侧补证据，渐进而非全量）；② 明确契约核对产出契约文档后转测试侧（TR-7）补契约 JUnit + 三类流执行证据；③ 后续 P0 批次（任务 22 / 商城 18 / 家庭 15 / 五维 12 等，P0 共 133）照此节奏推进	已裁决（2026-11-06 23:45 研发负责人1 本自动化第45轮，待主理人最终确认）：① 追认契约补建工作流授权——契约核对 = 文档核对 + 端点比对（防假 RED），产出契约文档后转测试侧（TR-7 已登记）补契约 JUnit + 三类流执行证据，渐进而非全量（契约定一批→映射入池→测试侧补证据→滚动下一批）；② 非研发实现型 RED——66 SC 端点已 100% 实现（0 缺失），不建伪实现任务，杜绝「有实现无证据」假红；③ 后续 P0 批次照此节奏推进（任务 22 / 商城 18 / 家庭 15 / 五维 12，P0 共 133），每批契约文档合入 origin/cfclub 后由研发负责人滚动派发契约核对；④ 本裁决为研发负责人裁决意见，待主理人最终确认后正式生效	2026-11-06 23:20（研发负责人 本自动化第44轮）	已裁决生效（主理人 2026-11-06 23:59 最终确认：追认契约补建工作流授权正式生效——契约核对=文档核对+端点比对防假RED，产出契约文档转测试侧 TR-7 补契约 JUnit+三类流证据；66 SC 端点已100%实现，非实现型 RED 不建伪实现任务；后续 P0 批次（任务22/商城18/家庭15/五维12，P0共133）渐进而非全量滚动推进）
O-8	sc-key-map 台账归一：O-3 转正 5 SC 双行制未归一 + 5 个新 SC（SC-P-94~96/SC-C-26/SC-A-27）未入册（236→241 口径未落地）	研发+测试+主理人	第 46 轮核验：① sc-key-map.md 唯一 SC 计数 = 236（`grep -oE '^| *SC-[A-Z]+-[0-9]+'	sort -u	wc -l），但总行数 241——**O-3 转正 5 SC 双行制**（行 26-30 标「跑通（2026-11-06 O-3 收口）」vs 主表行 107-128 仍「未跑通(实现已闭环,待三类流证据)」），同一 SC 出现两行且状态矛盾，计数口径歧义；② **5 个新 SC（SC-P-94~96 / SC-C-26 / SC-A-27）未入册**——2cc7e3aad` 需求变更已入表，但 sc-key-map.md 全文 grep 无命中，236→241 口径未落地，DEV_GOAL 顶层目标仍 236。诉求：① 归一 O-3 转正 5 SC 双行制（保留「跑通」权威段，主表行同步为「已跑通」或删除重复行）；② 5 新 SC 登记入册（基线 236→241）；③ 同步 DEV_GOAL 顶层目标与计数公式	已裁决（2026-11-07 00:35 研发负责人 本自动化第46轮，待主理人最终确认）：① 双行制归一——以 O-3 转正段（行 26-30）为「跑通」权威，主表行 107-128 的「未跑通(待三类流证据)」统一更新为「已跑通（O-3 收口）」或删除，保证唯一 SC ID 计数（sort -u）与总行数一致，消除 236 vs 241 歧义；② 5 新 SC 入册——SC-P-94~96/SC-C-26/SC-A-27 按 2cc7e3aad 需求变更登记入 sc-key-map.md，基线 236→241；③ DEV_GOAL 同步——顶层目标「全部 236 个」更新为「全部 241 个」，计数公式同步；④ 本裁决为研发负责人裁决意见，待主理人最终确认后生效
O-9	commit_kind main 归口缺 cfc-langgraph/src：AI 域实现键无法 RED→YELLOW（B-34 修复 1b15b67d2 实证被拒）	研发+主理人	实证：commit_kind(1b15b67d2, langgraph.questionnaire.generate) = kind=other（触及 cfc-langgraph/src/graphs/questionnaire.py + cfc-langgraph/src/schemas/questionnaire.py）。main 归口（2026-11-06 15:20 主理人裁决修复 7 处）仅含 src/main、-contract、`cfc-frontend/src	pages、cfc-web/src	pages、danshop/src，**未含cfc-langgraph/src**（Python AI 服务主源码）。后果：① S-cfc-33（B-34 P0）修复已真实落地并推 origin/cfclub（1b15b67d2，git merge-base--is-ancestor=YES ✓，02:46 提交），但--mark-yellow langgraph.questionnaire.generate必被拒（只认 kind==main）→ 状态机卡 RED 无法推进；② 契约补建工作流（O-7 授权）中所有 cfc-langgraph 实现键同受此限。诉求：① 将cfc-langgraph/src/纳入 main 归口、cfc-langgraph/tests纳入 test 归口（与 15:20 前端/web/商城同口径）；② 修复后对1b15b67d2` 回补登记 langgraph.questionnaire.generate 的 YELLOW 证据；③ 修订属工具脚本层（非业务代码），与 O-6 同属脚本缺陷类，走脚本修复通道	已裁决（2026-11-07 02:5x 研发负责人 本自动化第51轮，待主理人最终确认）：① cfc-langgraph/src/ 纳入 commit_kind/git_evidence main 归口、cfc-langgraph/tests 纳入 test 归口（与 15:20 裁决先例一致）；② 修复 tdd_orchestrate.py 脚本层（O-6 同通道）；③ 修复后对 1b15b67d2 回补登记 langgraph.questionnaire.generate YELLOW，dan.report.parseFormat 待 B-35 修复提交后同口径登记
O-10	B-31 安全 P0：application.yml 7 处明文凭据处置方案裁决	研发+主理人	blockers.md B-31（62 轮静态扫描登记）：cfc-backend/src/main/resources/application.yml 存在 7 处 password/secret/api-key/appsecret 明文赋值（数据源口令、微信 appsecret、第三方 key），仓库读权限者可直取凭据且历史提交已残留 git；R50/R51/研发负责人1 R27 连续三份汇报挂「待主理人裁决处置方案」（凭据值不进台账）。诉求：① 裁决配置改造方案；② 已泄露凭据轮换责任人；③ CI 防再犯	已裁决（2026-11-07 05:3x 研发负责人 错峰03·第46轮）：① 改造方案 = application.yml 改 ${ENV_VAR} 占位 + 本地 .env（gitignore）+ testing/production 凭据经部署环境变量注入，值永久不入库；② 历史已泄露凭据必须轮换——新值由主理人/运维侧生成并经环境变量注入，研发侧不得在仓库回填任何明文（轮换为人工运维动作，不可自动化）；③ CI/预提交增加明文凭据扫描（gitleaks 规则集）；④ 属非能力键安全流程项，不进 TDD 任务池；配置改造走研发独立 commit（本自动化按纪律④不代写他人改动）	2026-11-07 05:30（研发负责人 错峰03·第46轮；B-31 登记 2026-11-06 23:10）	已裁决生效（主理人 2026-11-07 07:20 最终确认：① 配置改造方案 = application.yml 改 ${ENV_VAR} 占位 + 本地 .env（gitignore）+ testing/production 凭据部署环境变量注入，凭据值永久不入库；② 历史已泄露凭据轮换 = 人工运维动作，新值由主理人/运维侧生成经环境变量注入，研发侧不得在仓库回填任何明文；③ CI/预提交加明文凭据扫描（gitleaks 规则集）；④ 属非能力键安全流程项不进 TDD 任务池，配置改造走研发独立 commit，凭据值不进任何台账）
O-11	B-33 流程 P1：.gitignore:70 *.py 全局忽略致 Python 度量/解析脚本「写了就丢」	研发+测试+主理人	blockers.md B-33（62 轮实测登记）：.gitignore 第 70 行 *.py 全局忽略，git add 被拒（git check-ignore -v 实证），根因链 B-15（discover_tests.py/test_inventory.py 丢失、历史度量不可复现）→ B-32（口径跨轮漂移）→ B-33；docs/tdd/tools/test_report_metrics.py 已落地但无法入库，docs/scripts/fingerprint_engine.py 等解析脚本同受约束。诉求：裁决 .gitignore 细化方案 + 放行口径	已裁决（2026-11-07 05:3x 研发负责人 错峰03·第46轮）：① .gitignore 第 70 行 .py 细化为 /.py（仅忽略仓库根层临时脚本）+ 追加白名单例外 !docs/tdd/tools/、!docs/scripts/、!tools/（度量/解析脚本显式放行）；② 修订属共享配置，由研发侧统一提交一次（本自动化按纪律④不代提交；主工作树 115+ 处 WIP 不动），测试侧 test_report_metrics.py 随之下次提交自动入库；③ B-15/B-32 随脚本入库自动闭环	2026-11-07 05:30（研发负责人 错峰03·第46轮；B-33 登记 2026-11-06 23:10）	已裁决生效（主理人 2026-11-07 07:20 最终确认：① .gitignore 第 70 行 *.py 细化为 /*.py（仅忽略仓库根层临时脚本）+ 白名单例外 !docs/tdd/tools/、!docs/scripts/、!tools/（度量/解析脚本显式放行）；② 修订属共享配置由研发侧统一提交一次，主工作树 WIP 不动；③ B-15/B-32 随脚本入库自动闭环）
O-12	EVD-10/EVD-11 契约核对缺口处置路径：成长规划师域 G-1/2/3 + 平台运营域 A-04/14/19/20/21 的派发/回收/登记口径	研发+测试+主理人	EVD-10（成长规划师域 32 SC）+ EVD-11（平台运营域 25 SC）契约核对产出已回收 77026df42/9abed8e11，但缺口键（G-1/2/3、A-04/14/19/20/21）处置路径需与 O-7 契约补建节奏对齐	已裁决（研发负责人 错峰03 第47轮，主理人 2026-11-07 1330 轮确认生效）：EVD-10/EVD-11 缺口键按 O-7 契约补建工作流处置——契约定一批→映射入池→测试侧补证据，渐进而非全量	2026-11-07 13:30（研发负责人 错峰03）	已裁决生效（主理人最终确认 2026-11-07 13:30 轮，O-12 闭环）
O-13	B-38④ platform_fee 口径分歧：26 红类归因之一，字段单位/类型裁决	研发+测试+主理人	B-38 全量实测 26 红类/69 红例归因中 platform_fee 相关用例红，根因 = 测试假设口径与实现不一致（字段单位「元 vs 分」、类型 DECIMAL vs 整型、默认值缺省）。诉求：裁决 platform_fee 统一口径供测试侧修订用例、实现侧对齐	已裁决生效（主理人 2026-11-07 17:5x 拍板确认）：platform_fee 统一为单位「分」+ BIGINT NOT NULL DEFAULT 0（与平台现有金额字段口径一致，避免浮点精度/单位换算错误；测试侧按此修订用例，实现侧无需改动——当前实现即分单位）	2026-11-07 16:06（研发负责人 错峰03 意见；17:5x 主理人拍板）	已裁决生效（O-13 闭环）
O-14	D/X 域（华为/小米健康）实现先于设计登记：4344688d2/978d1bc95/4815aae95 已合入 cfclub 但无场景/无测试/未入池	研发+测试+主理人	14:36 检出 feat(xiaomi-health) X1-X5 + feat(huawei-health) D1-D5 + fix isBound 共 3 提交已合入 origin/cfclub（token 表/授权/同步/5接口/mock 通道），但：无对应用户场景（241 SC 基线无 D/X 域条目）、无测试用例、未入 TDD 池。诉求：裁决处置路径（纳入 241 基线 vs 独立契约核对批次）	已裁决生效（主理人 2026-11-07 17:5x 拍板确认）：D/X 域作 O-7 独立契约核对批次（同 EVD 节奏：契约核对=文档核对+端点比对，产出契约文档转测试侧补证据），不纳入 241 基线（当前 DEV_GOAL=241 SC 无 D/X 域条目，基线不膨胀）；实现已合入无需研发重做，仅需设计契约登记 + 测试证据补建	2026-11-07 16:06（研发负责人 错峰03 意见；17:5x 主理人拍板）	已裁决生效（O-14 闭环，D/X 契约核对批次待启动）