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

## 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. 推荐命令模板（单样本）

```bash
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汇总为一张表。