xst
8c61209dd4
- 需求 v1.1 + 2026-09-29 需求方确认的 Q7~Q19 决议（含 BR-07/BR-09/6.7/6.9 矛盾表述修订） - 测试点 159 个、测试用例 164 条（P0 55/P1 81/P2 23/P3 5），需求→测试点→用例三级追溯覆盖率 100% - 质量裁决 PASS（首轮 PASS_WITH_FIX，13 项待确认确认后复裁决升级）；评审原始 2 阻断项+9 建议项+3 优化项已全部修复 - 确认单：与 4 个历史需求均为并行关系、0 冲突、0 回写 - 附导出 v1/v2 版本快照、Playwright/Appium 脚本骨架、覆盖率审计脚本与指标、评审修复脚本
子需求冲突确认说明
这个目录用于沉淀“已有需求继续迭代、子需求补充、规则替代、并行生效”这类场景下的人为确认结论。
为什么需要这个目录
当前流水线已经能自动做这些事：
- 识别历史相似需求
- 识别部分规则冲突候选
- 生成
output/analysis/{BASE_NAME}_关联与冲突.md
但当前流水线还不会自动做这些事：
- 自动裁决新旧需求到底是“补充 / 替代 / 并行”
- 自动回写旧需求和新需求的版本边界
- 自动根据确认结论重跑全部受影响需求
所以，涉及跨需求冲突时，必须把最终业务结论沉淀成文件，而不是只停留在聊天记录或口头确认。
建议使用方式
- 新子需求先按正常流程进入
source_docs/requirements_raw/ - 运行
/case_generate ...或prepare - 查看
output/analysis/{BASE_NAME}_关联与冲突.md - 如果存在冲突候选、高风险规则或
> ⚠️ 待确认，新增一份确认单 - 确认结论写清后，执行：
python3 scripts/case_pipeline.py apply-confirmation --requirement <需求文档路径>
- 重跑完成后，正式维护版 Markdown 会同步到
requirements/{BASE_NAME}.md
建议命名
推荐命名：
decisions/{BASE_NAME}_确认结论.mddecisions/{BASE_NAME}_v2_确认结论.md
如果一个子需求关联多个旧需求，也可以用主题名而不是单个需求名：
decisions/member_coupon_rule_merge_确认结论.md
当前状态与目标状态
当前状态：
- 确认单是人工维护资产
prepare会把确认门禁写进 manifestverify和export会在确认单未写明确认状态：已确认时阻断- 是否继续重跑，仍然由人工触发
- 触发后可由
apply-confirmation自动写维护说明并重跑确认单中的目标需求
目标状态：
- 脚本检测到冲突后自动提示进入确认阶段
- 已确认时支持更细粒度地自动回写需求源文件，而不只是写维护说明
在脚本能力补齐前，这个目录的作用是让“冲突裁决”具备可追溯性。