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

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

一、目标定义

让 tests/user-scenarios/应用场景总览.md 列出的全部 218 个应用场景（SC-角色-NN）都能端到端跑通。

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

该场景派生的 正常流 / 异常流 / 权限流 三类用例均有实际执行证据（Playwright / pytest / 契约测试报告，或写明步骤与结果的验收记录）；
支撑该场景的实现代码与用例已 push 到 origin/cfclub，用 git merge-base --is-ancestor <sha> origin/cfclub 可核验；
工作目录干净（tdd_orchestrate.py --clean-check 退出码 0）。

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

资产	路径	规模
场景总目录与追溯矩阵（一级权威）	`tests/user-scenarios/应用场景总览.md`	218 个 SC：游客 12 / 家长 93 / 孩子 25 / 规划师 32 / 运营 24 / 服务商 11 / 跨角色 21
角色叙事细节	`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。

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

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

每轮标准汇报 docs/tdd/orchestration/report-dev-YYYY-MM-DD-HHMM.md 除模板必填项（1.2b 会话列表必填，无空闲也列 idle）外，必须增列 「场景覆盖矩阵」：总数 218 / 累计已跑通 / 本轮新增跑通 / 失败 / 阻塞 / 未跟踪，并逐条注明本轮推进的 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。

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