crm-backend-matt/.scratch/opportunity-bugfix/issues/11-testdata-refresh.md

11: 测试数据集刷新（跨部门场景 + 状态流转样例）

Type: task Status: resolved Blocked by: 09

任务

刷新精简可用的测试数据集，覆盖本轮全部新能力（可与票 10 并行）：

1. 基线升级：seed-opportunity.py 在上轮 12 条（待领取2/推进6/暂缓2/关闭2 跨 3 部门）基础上补：
   • 关联客户样例：每条推进中商机挂 2-3 个关联客户、恰 1 个主要意向（票 04 新端点的数据底座）。
   • 团队成员样例：至少 2 条商机有完整团队（负责人 + 方案/现场/商务角色，对齐原型 8 角色矩阵的精简版）。
   • owner_dept_id 全量落值（票 03 修好后创建路径自动落；seed 直造的数据也要补齐该列）。
   • 部门专用公海规则样例：1 条部门专用（配合 D-09 禁领回归）。
2. 状态流转样例：保留上轮状态覆盖 + 确保「暂缓态不可编辑/关闭」有专用样例（一条长期暂缓的商机供前端联调按钮态）。
3. 幂等与清单：脚本保持幂等可重跑（先清后造）；seed-data-manifest.md / seed-manifest.json 同步刷新（含新表数据说明 + 各账号可见矩阵 MANAGE/POOL/MINE/FOLLOWED 计数）。
4. 若票 07/08 有新模块实现，其测试数据并入本票（工作计划样例 / 客户池样例）。

约束

• 脚本一律 Python requests（中文 body mojibake 纪律）；DB 直插仅限 API 覆盖不到的关联数据（上轮模式）。
• 远程共享库：e2e- 前缀幂等重跑，不碰他人数据。

验收

• seed 重跑 2 次结果一致（幂等）。
• manifest 三件套齐备；账号可见矩阵计数实测对得上。
• 前端联调视角抽查：A 赖永利登录能看到带完整团队 + 关联客户的商机详情（含 owner_dept_id 部门字段回显）。

Answer

已完成（20260830）。seed-opportunity.py 升级完毕，四遍实跑全绿（缺陷 0 / 跳过 0）。

交付内容

1. 关联客户 API 化（替掉票 05 的 DB 直插豁免）：走票 04 customer/add + set-primary；6 条推进中商机每条 2 个客户、恰 1 主要（共 12 行）；a2 完整剧情：园科集团为主 → 建工设计院普通 → set-primary 切主要（原主要自动降普通，实测主表 primary_customer_name_snapshot 同步刷新）。customerId 用占位 id（A4 未建，add 无存在性校验仅查重 66011）。脚本先 customer/list 查重保 --skip-db-clean 重跑不撞。
2. 团队成员 API 化：走票 04 team/add（DTO 批量统一角色）；a2 加 B（方案工程师 project_role_05/perm3）+C（现场专员 project_role_02/perm2）、b1 加 A（报价专员 project_role_04/perm2）+C（协同负责人 project_role_06/perm1）；快照服务端回显实测正常。DB 里 team 16 行 = 12 负责人行（创建自动落 project_role_01/perm4）+ 4 API 行。
3. 部门专用禁领规则：ensure_dept_claim_rule 发布 e2e-seed冠军团队禁领（applyScope=2 + deptIds=[冠军团队 744841308677341184] + allowFreeClaim=0 + autoRecycleEnabled=0 只干禁领防误回收）；幂等复用，不碰他人规则。
4. 禁领回归实测：b4（B 抛公海，E3 保留 owner_dept_id=冠军）→ A 领取实测 66014 ✓；a4 对照（特战走通用规则）领取放行后立即抛回恢复公海样例 ✓。
5. owner_dept_id 全量落值：DB 终验 12/12 行无空值，与负责人主部门一一对应（A=特战…54976、B=冠军…341184、C=职员…133440，含公海/关闭行保留）；上轮 observed 的 dept 漂移现象（历史多轮跑残留）随全量重造消失。
6. 长期暂缓样例：a3 预期重启 2027-01-15（远期，按钮态联调）；b3 保留 2026-10-15 近期对照。
7. verify/manifest 升级：三账号 MINE 计数（A=4/B=4/C=2，均不含公海）+ A_FOLLOWED=1 + spot_a2 详情抽查（ownerDeptId/团队数/客户数/primaryCustomer）进 checks；账号矩阵表补实锤 dept_id；DB 豁免从两处降为一处（仅清理级联删）。

幂等与计数（四遍实跑一致）

• MANAGE=12 PUBLIC_POOL=2 A_MINE=4 B_MINE=4 C_MINE=2 A_FOLLOWED=1；board summary 3/2/1 稳定。
• 客户 12 行、团队 16 行、跟进 2、勘察 1、方案卡 1（已提交）；自定义视图 viewId 复用不新建。
• 规则/模板三前置全部复用幂等（ensure_pool_rule 修正为优先复用通用规则 applyScope=1，避免 page 倒序拿到专用规则致 manifest 语义跑偏）。

验收对照

• ✅ 重跑一致：实跑 4 遍（含补齐客户口径后的终态），计数与状态分布全一致。
• ✅ manifest 三件套齐备：seed-opportunity.py / seed-manifest.json / seed-data-manifest.md（票 11 版），计数实测对上。
• ✅ 前端联调抽查：A 登录 a2 详情 ownerDeptId=744841308564094976（特战回显）+ 团队 3 人 + 关联客户 2 个 + primaryCustomer=920000000000000200。

备注

• 票面任务 4（票 07/08 新模块数据并入）不适用：07/08 为研究票尚未拍板实施，无工作计划/客户池数据可并入；实施后重跑本脚本再补。
• 侦察实锤沉淀：用户主表 crm_auth_user（dept_id 列）、project_role 字典（dict_group.code=project_role，item code=值同码 01~06）、opportunity_pool_rule_dept 外键列 rule_version_id 指向规则版本行 id。
• 环境插曲：跑第一遍前 Redis 远端瞬断一次（lettuce 自动重连恢复），与服务无关。