首頁 探索 說明
註冊 登入
liaoxg
/
cfc
1
1
複刻 0
檔案 問題管理 0 合併請求 0 Wiki
分支: task/S-cfc-310
分支列表 標籤列表
cfc
/
docs
/
tdd
/
orchestration
/
DEV_GOAL_user_scenarios.md

DEV_GOAL_user_scenarios.md 10 KB
永久連結 文件歷史 原始文件

开发目标：所有用户场景都能跑通（单一事实源）

定稿：2026-11-05，主理人拍板。本文是 CFC 研发/测试编排的顶层验收口径，所有研发负责人闭环轮次、所有派发出去的开发会话，开工前须读取本文；与本文冲突的旧口径以本文为准。

一、目标定义

让 tests/user-scenarios/应用场景总览.md 列出的全部 241 个应用场景（SC-角色-NN；O-4 裁决 2026-11-06 落地，基线 218→236；O-8 裁决 2026-11-07 落地，236→241）都能端到端跑通。

「跑通」的判定（三者缺一不可）：

  1. 该场景派生的 正常流 / 异常流 / 权限流 三类用例均有实际执行证据（Playwright / pytest / 契约测试报告，或写明步骤与结果的验收记录）；
  2. 支撑该场景的实现代码与用例已 push 到 origin/cfclub，用 git merge-base --is-ancestor <sha> origin/cfclub 可核验；
  3. 工作目录干净（tdd_orchestrate.py --clean-check 退出码 0）。 O-3 收口（2026-11-06 主理人拍板）：判据③按「SC 关联提交级」核验——该 SC 的实现/用例提交须为干净提交（git diff --name-status <parent> <sha> 无删除、无无关文件）且已推 origin/cfclub；主工作树中其他会话/其他域的未提交改动不计入该 SC 的干净判据。

不算跑通：仅代码已提交、仅编译通过、仅接口单测通过、会话自述「已完成」、仅文档用例写完但未执行。

二、场景基线（只读，不改原始文件）

资产 路径 规模
场景总目录与追溯矩阵（一级权威） tests/user-scenarios/应用场景总览.md 241 个 SC：游客 12 / 家长 96 / 孩子 26 / 规划师 32 / 运营 25 / 服务商 11 / 跨角色 22 / AI 成长教练 10 / 真人管家 7（O-4 裁决 2026-11-06 落地 218→236；O-8 裁决 2026-11-07 落地 236→241 含 SC-P-94~96/SC-C-26/SC-A-27；SC-B/AI 成长教练 10、SC-H/真人管家 7、SC-X-22 CF 预估）
角色叙事细节 tests/user-scenarios/01-guest.md ~ 07-five-dimension.md + README.md 每个场景含用户故事、前置条件、主流程、异常/边界、关联需求/设计、关联用例
派生测试用例 tests/test-cases/*.md（含 cross-role-e2e.md） 729 条 TC
自动化状态台账 docs/tdd/test/automation-status.md 由 test_inventory.py 从 .tdd/test-progress.json 派生
已有脚本 Playwright e2e/integration 70 文件 / 410 方法；Python pytest 12 文件 / 55 方法 可复用，不重造

能力边界：tdd-orchestrator 只做「发现 / 格式化 / 跟踪」，不创建、不发明、不修改 原始测试文件与场景文件；新增脚本/用例由 QA 会话在其独立分支产出并 push。

三、现状（2026-11-05 基线）

  • docs/tdd/test/automation-status.md：结构化测试用例 729 条 → 已执行 0 / 通过 0 / 失败 0 / 未跟踪 729；脚本级自动化尚未接入 CI（无 .github/workflows/、.gitlab-ci.yml、Jenkinsfile）。
  • 因此本目标处于 0 / 241 起步状态；每轮汇报必须如实填写「累计已跑通场景数」，不得用「任务已分派」冒充「场景已跑通」。

四、推进规则（每轮闭环）

  1. 场景即任务池：把未跑通的 SC-角色-NN 作为一级待办，按主链路优先排序： 登录/鉴权 → 家庭成员与双角色 → 任务/心愿 → 五维能量 → 健康报告解析 → 测评订单 → 商城/会员 → 文章审核 → 跨角色 E2E → 运营/服务商/合规。
  2. 不留空闲：所有 idle 会话优先承接「场景打通」类任务（补用例、修实现、接 CI），派发后复查 idle，直到无空闲或达并发上限。
  3. 池空即建任务：没有待办时，从场景总览中挑选未跑通 SC 新建任务，--add-task <key> --requirement "<需求锚点>" --design "<设计锚点>" 两个溯源缺一不可；锚点须回链到 SC 编号 + 场景文件 + 对应需求/设计文档，--design 以已合入 origin/cfclub 的契约为准并标注「实现仅在 feature 分支、不得假定包路径」。
  4. 测试用例变更联动：用例变化 → 重跑 test_inventory.py --project E:/cfc 派生 docs/tdd/test/automation-status.md；跨角色请求写 docs/tdd/dev/test-requests.md，需裁决写 docs/tdd/orchestration/pending.md，并 push。
  5. CI 接入是必选项：脚本级自动化须推动接入 CI 持续回归，否则「跑通」无法持续保持；每轮至少推进一项 CI/回归能力缺口。

4.1 SC → 能力键映射与计数口径（主理人 O-2 裁决，2026-11-05）

本小节是 O-2 裁决的固化（单一事实源），覆盖 00:53 旧口径中「SC 即任务池」的歧义。权威登记表：docs/tdd/orchestration/sc-key-map.md（241 SC 全量，唯一「SC 跑通」计数来源；O-4 裁决 2026-11-06 落地 236；O-8 裁决 2026-11-07 落地 241）。

  1. SC 不作状态机键：--add-task <key> 的 key 一律为合法 unit.domain.action（方案 A 为正本）；SC 编号 + 场景文件写进 --requirement，已合入 origin/cfclub 的契约写进 --design（标注「实现仅在 feature 分支、不得假定包路径」）。
  2. 否决放宽 SC 前缀（方案 B）：不改 skill 脚本 KEY_RE，避免污染全部项目 + 「SC=能力编排组合」与「单一能力」语义错位。
  3. 方案 C 仅为补充：SC 已有实现但缺三类流执行证据时，由测试侧补 e2e/契约脚本；不建 scenario.* / sc_* 等无契约、无用例引用的伪能力键。
  4. 计数分离（关键修正）：能力键 DONE ≠ SC 跑通。一 SC 可映射 N 个能力键（1:N），一能力键可被 M 个 SC 共享（M:1）；state.json 只证明「实现闭环」，「累计已跑通」按 sc-key-map.md 的 SC 计——须同时满足：① 正常/异常/权限三类流实际执行证据；② 实现与用例已 push origin/cfclub（git merge-base --is-ancestor 核验）；③ 工作区干净（--clean-check 退出码 0；O-3 收口 2026-11-06 起按「SC 关联提交级」核验——SC 提交干净且已推 origin/cfclub，主工作树其他域他人 WIP 不计入）。

4.2 O-4 裁决（2026-11-06，主理人拍板）

正本总数 = 241（sc-key-map.md 表格行口径：A25/G12/P96/C26/T32/S11/X22/B10/H7 = 241；O-8 归一后主表行数 = 唯一 SC ID 数 = 241）。

  • 口径来源：以 docs/tdd/orchestration/sc-key-map.md 表格行（含 SC 编号的 | SC-... | 记录行）为唯一计数权威；与 tests/user-scenarios/应用场景总览.md 正文描述/历史演进记录/编号变体引用保持只读一致。
  • 统计方法：grep -oE '\| *SC-[A-Z]+-[0-9]+ *\|' docs/tdd/orchestration/sc-key-map.md | sort -u | wc -l = 241（严格表格行过滤，不含演进记录或正文引用的重复行）。
  • 更正旧误差：2026-11-06 09:35 轮曾以全文 grep -oE "SC-[A-Z]+-[0-9]+" 统计得 237（含表外引用与正文变体引用），本次裁决更正为 236。2026-11-07 O-8 归一后为 241（并消除 O-3 5 SC 双行制 +5 歧义，主表行数 = 唯一 ID 数）。
  • 总览文件残留引用不计入（不修改原始场景文件，仅声明口径）：SC-B-03/SC-B-08（AI 成长教练空号，台账已删）→ 不计入；SC-T-6（=SC-T-06 无零变体，总览 SC-X-22 产出点清单引用）→ 不计入。
  • 历史演进：218（2026-11-05 定稿）→ 230（08-butler 补 SC-B 10）→ 235（09-human-butler 补 SC-H 7 并删 SC-B-03/08）→ 236（SC-X-22 CF 预估入池）→ 241（O-8，2026-11-07：SC-P-94~96 / SC-C-26 / SC-A-27 入册）。
  • SC-X-22 状态：契约（6141c43a2）+ 实现（f14e46f84）+ JUnit 契约（2869d0e8e）已合入，仅缺三类流执行证据 + mark-green（TR-5），入正本不计入已跑通。
  • 后续影响：每轮汇报「场景覆盖矩阵」基数 241；CI_READINESS G2/G3 口径同步；历史汇报不可追改。

4.3 O-3 收口（2026-11-06，主理人拍板）

判据③细化 + 5 个 SC 转正「跑通」。

  • 问题：5 个 SC（G-02/G-06/P-03/P-10/P-11）证据链齐备（三类流执行证据 + 实现/用例已推 origin/cfclub），唯卡「工作目录干净」第三判据——主工作树 25 处 WIP 全部为其他域会话（会员/商城 Membership、DAN 测评前端、文档 PROJECT-OVERVIEW/API_REFERENCE、E2E flow-l1、编排工具 tasks_backlog、家庭归因读本 docs/参考教材）未提交改动，与这 5 个 SC 提交无关。
  • 裁决：判据③由「主工作树全局干净」细化为「SC 关联提交级干净」（见 §一判据③、§4.1-③）。5 个 SC 证据 sha 已核验：8051b64f1（G-02）/df2364ba3（G-06）/f1b0e3ed5（P-03）/f41da2779（P-10）/291955bce（P-11），全部 git merge-base --is-ancestor origin/cfclub ✓ 且提交干净（无删除、无无关文件；P-10 提交 f41da2779 含 automation-run 执行证据 + tests/e2e/api/task-create-scp10.spec.js）。
  • 结果：5 个 SC 转正为「跑通」，累计已跑通 0 → 5；阻塞 5 → 0；未跟踪 236（241−5）。
  • WIP 归属（只读盘点，不代提交）：主工作树 25 处未提交改动已登记于 report-dev-2026-11-06-1018.md 附录 G；各域属主会话自行提交，编排侧不擅自 add -A/checkout/stash。

五、验收与汇报口径

  • 每轮标准汇报 docs/tdd/orchestration/report-dev-YYYY-MM-DD-HHMM.md 除模板必填项（1.2b 会话列表必填，无空闲也列 idle）外，必须增列 「场景覆盖矩阵」：总数 241 / 累计已跑通 / 本轮新增跑通 / 失败 / 阻塞 / 未跟踪，并逐条注明本轮推进的 SC 编号与证据 sha。
  • 阶段推进（RED→YELLOW→GREEN）以场景用例实际通过为准，不得以「实现代码已合入」直接置 GREEN。
  • 收口纪律沿用：只认已推远端 git 证据；严禁 git add -A；提交他人产物先 git show origin/cfclub:<path> 对齐、精确 git add -- <paths>；严禁 checkout/stash/force-push 他人改动，独立提交走 worktree；.tdd/ 本地私有禁推，共享内容只放 docs/tdd/*.md。

六、完成判据

241 / 241 个 SC 均具备三类用例的实际通过证据 + 实现与用例已推 origin/cfclub + CI 持续回归可用 + 工作目录干净。在此之前，任何一轮都不得汇报「开发完成」。