starRiverProperty/docs/testing/release-visitor-noauth-verify-v20260430/执行流程设计-简化版.md

访客楼层策略验证执行流程（简化版）

1. 目标

按固定顺序完成两组验证，并输出汇总结果：

1. 基线组（广发基金）：新增“黄平访客 -> 被访人蒙海文（personId=964454497399468032）”，再查询该访客楼层权限；
2. 对照组（其他公司多样本）：从数据库筛选多个公司/多个部门被访人，分别新增“黄志平访客”，再查询各自楼层权限；
3. 最终输出“每个样本是否成功、楼层数量与楼层清单”。

说明：本流程强调顺序和可复核性，不再依赖复杂自动推断。

2. 统一原则

• 只以 personId 作为最终查询键，不以姓名直接判定权限。
• 姓名查询仅用于“定位候选人”，不用于最终业务判定。
• 判定顺序固定：先写（add/visitor），再读（passRule/image）。

3. 执行总流程（必须按顺序）

步骤A：准备参数与样本

• 访客固定：黄平/黄志平（按现场实际确认对应 visitorPersonId）
• 先准备两类样本：
  • 样本1（广发基金基线）：businessId=252463...，被访人 964454497399468032
  • 样本2（多公司多部门对照）：在与目标验证环境一致的组织库/MySQL 上筛选多个公司和部门被访人（禁止使用开发库数据去打生产接口）

步骤B：执行样本1（广发基金基线）

1. 调 add/visitor 新增访客；
2. 紧接着调 passRule/image 查询楼层；
3. 记录基线组结果（期望仅 28F，若策略开启）。

步骤C：执行样本2（多公司多部门）

对每个被访人样本重复：

1. 调 add/visitor 新增“黄志平访客”；
2. 调 passRule/image 查询该访客楼层；
3. 记录结果到汇总表。

步骤D：输出总结果

按样本输出字段：

• 公司
• 部门
• 被访人 personId
• 访客 personId
• add/visitor 结果码
• 楼层数量
• 楼层清单

4. 异常分流（必须遵守）

4.1 add/visitor 失败（任何样本）

结论：该样本不具备“策略生效验证条件”。

动作：

1. 查同时间窗口服务日志；
2. 定位具体失败点（远程超时、依赖服务不可用、SQL异常等）；
3. 修复后仅重跑失败样本。

4.2 add/visitor 成功但楼层不符

动作：

1. 查策略读取日志（policyDecision、allowFloorSize、effectiveFloorSize）；
2. 查策略表配置是否匹配租户；
3. 查 image_rule_ref 当前 person_delete=0 记录是否包含历史残留。

5. 为什么采用该顺序

• 先做广发基金基线，可快速判断策略主路径是否正常；
• 再做多公司多部门对照，可评估是否存在租户间差异或历史规则干扰；
• 最后统一汇总，避免单条日志或单个样本误导结论。

6. 推荐命令模板（单样本）

python3 python/quick_verify_visitor_floor_policy.py \
  --mode noauth-probe \
  --org-base-url "http://10.0.22.207:8089" \
  --elevator-base-url "http://10.0.22.207:16112" \
  --business-id "2524639890ba4f2cba9ba1a4eeaa4015" \
  --meng-person-id "964454497399468032" \
  --visitor-person-id "1102270499947507712" \
  --probe-with-businessid

多样本场景建议外层脚本循环调用本命令，并将结果JSON汇总为一张表。