danyang-match/docs/governance/open-questions.md

# 开放问题 — open-questions.md

> **版本**：V1.0.1 配置与规则纠偏基线 · **生效**：2026-09-20 · **owner**：产品负责人
> 未决项在此登记；**产品正式确认后**移入 `decision-register.md`，并同步更新
> `config-register.md` 的「产品正式确认」列与 `PENDING_DECISIONS.md`。
> 状态：`TBD`（待产品裁决）/ `IN_PROGRESS` / `RESOLVED`。

---

## OQ-IDENTITY-001 · 是否在正式运营阶段启用人脸/活体核验？

- **状态**：TBD
- **当前技术默认**：canonical 键 `identity.liveness.enabled`（V051 起为 `feature_flag_overrides` 唯一正式键；实现字段 `livenessEnabled`）= `false`，provider = `none`
- **说明**：活体**不是 V1.1 首发强制规则**。默认关闭时不得阻断实名主流程、不得误提示「必须人脸」。
  开关已接真实业务判定点（`GET /verification/liveness-status` → `enhancedVerified`），消除「假开关」。
  是否启用、选用哪家合规第三方 Provider（选型未定）由产品/合规裁决。
- **关联**：`IdentityPolicy`、`UserIdentity.livenessVerificationStatus`、V016、V051。

## OQ-PROFILE-001 · 用户最多可上传多少张个人照片？

- **状态**：TBD
- **当前技术默认**：`profile.photo.maxCount = 6`（头像 + 生活照合计）
- **说明**：6 仅作为技术默认值，**必须保持配置化**（已配置化 + 服务器端强校验 + 并发安全）。
  不得写死；产品确认正式值后改配置即可，无需改代码。
- **关联**：`ProfileProperties` / `ProfilePolicy` / `PhotoService.ensureWithinPhotoLimit`。

## OQ-MATCH-001 · 推荐最低评分阈值最终采用多少？

- **状态**：TBD
- **当前技术默认**：`matching.recommendation.minScore = 60`（`match.default-score-threshold`）
- **说明**：60 **不代表产品正式确认**。阈值已配置化；推荐记录自 V050 起携带
  `threshold_snapshot` + `rule_version`，未来 60→65 可追溯历史推荐依据。
  前端不得把 score/threshold 包装为「匹配成功率 / 合适概率」等对外承诺。
- **关联**：`MatchRuleConfigProperties` / `MatchingPolicy` / V050。

## OQ-LOCAL-ELIG-001 · 本地资格佐证文件保留期限？

- **状态**：TBD（需合规审核）
- **当前技术默认**：`features.localEvidenceRetentionDays = 365`（可配置，非永久）
- **说明**：与「注销后 36 个月数据保留」（LOCKED）是**两套独立机制**。
  配套清理作业尚未实现（已挂 Phase 22 运维任务，Phase-04 报告 :46 登记）。

## OQ-SERVICE-LOC-001 · 善缘服务站正式开放时间？

- **状态**：TBD
- **当前实现**：`service_locations.opening_hours_text` 自由文本（数据驱动、非硬编码），
  种子值「周一至周五 9:00-17:00 / 周六 9:00-12:00」。属产品文案决策，挂起不动代码。

## OQ-COUNSEL-001 · 咨询人员实际资质要求 / 预约时段规则？

- **状态**：TBD
- **当前实现**：代码中**无资质字段/校验**（现状即「无资质要求」安全默认）；预约时段为自由输入
  + 运营手工确认（无自动时段校验，不违反 AGENTS #12）。未来需资质/自动时段才需产品出规则并配置化。

## OQ-BANNER-001 · Banner 最大活跃数量？

- **状态**：TBD（**真缺口**）
- **当前实现**：代码**无**该限制，仅 demo seed 里一个从未被读取的死值 `banner.maxActiveCount='5'`
  （`system_configs` 为死表，0 个 Java 读取点）。需产品定值后**实现** active-count 校验。

## OQ-ANALYTICS-001 · 有效交友匹配正式报送口径？

- **状态**：TBD
- **当前实现**：`match.effective` 为 `PROVISIONAL` 保守近似（`min(有真人消息会话, Match 总数)`），
  文档已标「禁止对外」。建议口径（Mutual Match + Two-Way Chat）未实现；升 `OFFICIAL` 前需产品裁决。

## OQ-MATCHMAKER-002 · 组长团队统计 perMatchmakerCounts 的 operatorName 是否脱敏？

- **状态**：RESOLVED（ZC-MM-005 收口 P2-4，team-lead 裁定 2026-10-10）
- **裁定**：红娘姓名（operatorName）**保留、不脱敏**。依据：
  1. 对照《决策》§5.2 字段分类：红娘姓名属「本人/团队范围内的工作人员标识」，**非用户 PII**
     （§5.2 禁放的是 phone/mobile/wechat/idNumber 等用户敏感数据）；
  2. 功能权限矩阵「查看脱敏服务统计：组长=团队范围」+ DEC-MATCHMAKER-002 红娘组长职责
     （团队内进度与工作量管理）—— 组长统计本团队工作量属管理职责；
  3. 组长已可经 `GET /assignable-matchmakers` 拿到同批红娘姓名，此字段**非新增泄露面**
     （管理范围 ≠ 用户敏感数据）。
- **代码落点**：`MatchmakerAssignmentService#teamStatistics` 方法注释已写明该决策依据；
  本登记防止后人误判「统计含姓名=越权」。产品如日后要求组长统计姓名脱敏（如仅显示昵称/工号），
  需回到本项重新裁决并同步改 `countActiveGroupByOperator` 查询与前端渲染。

## OQ-MATCHMAKER-003 · 受控联系（电话/线下）开放前的产品/法务确认项【LEGAL_VERIFY】

- **状态**：**RESOLVED**（2026-10-11 产品裁决全部落定 + 实现/测试闭环，提交 d3735e3 → f73a116；建议正式放量前将本节产品裁决记录转法务复核留痕）
- **背景**：DEC-MATCHMAKER-003 / B1 LOCKED——默认平台内渠道联系，电话/线下联系须专项授权。B1 例外通道已按「申请（须持有效分配）→ 审批（组长主审+管理员兜底）→ **用户单独同意**（PIPL 单独同意动作，独立端点、无预同意参数）→ 限时生效 → 撤销/过期」全链路上线。
- **五项终审裁定（2026-10-11，产品侧全部确认）**：
  1. 电话/线下联系例外由**哪个岗位批准**【LEGAL_VERIFY①】——**RESOLVED：组长主审 + 平台管理员兜底**（OQ-MATCHMAKER-009 裁决，分层审批已实现，提交 f73a116）；
  2. 例外授权是否需要**用户单独同意**、如何记录【LEGAL_VERIFY②】——**RESOLVED：已实现**（单独端点 + consent 留痕 + 无捆绑默认勾选 + 三端守卫锁定）；
  3. 临时授权的**有效期限**【LEGAL_VERIFY③】——**RESOLVED：维持 7 天**（`default-validity-days=7`，DEFAULT+CONFIG，调整改配置即生效）；
  4. 联系授权记录/联系结果摘要的**保留周期**【LEGAL_VERIFY④】——**RESOLVED：维持 365 天**（`retention-days=365`，对齐平台审计口径）；
  5. 授权审批与用户同意的**审计字段与查询面**【LEGAL_VERIFY⑤/现 OQ-003 第 5 项】——**RESOLVED：现状满足**（purpose_code=matchmaker.contact.* 全链路 + service_assignment_id + request_trace_id + user_phone_disclosure 敏感审计；平台直属 org=NULL 审批边界按 NULL=NULL 规则维持，与分配建模口径一致）。
- **产品裁决记录**：2026-10-11 四项裁决全部按推荐选项确认（审批岗收敛/有效期 7 天/保留期 365 天/NULL=NULL 组长可审）；`matchmaker.contact.*` 全部 canonical key 保持 DEFAULT+CONFIG，后续调整改配置即可。
- **机械锁（已翻转）**：`MatchmakerContactGuardTest` 现锁定新机制契约——披露能力仅限专用白名单类、端点前缀白名单、到期/撤销/拒绝/未同意状态下 disclose 一律 404+DATA_SCOPE_DENIED、consent 端点独立性、ReferralService 禁词与无 @Scheduled 保留；未来绕过专用出口的披露路径必触红。
- **关联**：DEC-MATCHMAKER-003 规则 7、《决策》§十一；V056；提交 d3735e3、f73a116。

## OQ-MATCHMAKER-009 · 受控联系审批双岗并列待收敛

- **状态**：RESOLVED（2026-10-11 产品裁决：组长主审 + 平台管理员兜底，提交 f73a116）
- **裁定**：分层审批——`matchmaker.assign`（平台管理员）为**兜底岗**（全量审批、不做组织范围校验）；`approver-authorities` 首段（默认 `matchmaker.team.assign`）为**主审岗**（assertTeamScope 组织范围，hasGlobalAssign 固定不透传、防权限面双通道；NULL=NULL 平台直属可审）；两者皆无 403 deny。双岗兼任者按兜底岗口径全量审批。
- **落地证据**：`MatchmakerContactAuthorizationTest` 4 条分层用例（管理员跨组织兜底/组长他组织 403/组长审平台直属/双岗兜底全量，HTTP+审计双断言）；负向注入移除兜底分支→恰好 2 例分层用例判红→还原复绿；主理人 Docker 独立实跑 20/20。
- **关联**：OQ-MATCHMAKER-003 第 1 项；config-register `matchmaker.contact.approver-authorities`（键名/默认值不变，语义分层）。

## OQ-MATCHMAKER-010 · QA P2-2：`matchmaker.contact.enabled=false` 行为用例待补

- **状态**：RESOLVED（2026-10-11 补齐，提交 f73a116）
- **落地**：新增 `MatchmakerContactDisabledTest`（@SpringBootTest properties 覆盖 `matchmaker.contact.enabled=false`）——disclose/request 均 404 化拒绝、零 SensitiveAccessLog、零 contact 成功审计行、fail-safe 先于 purpose 业务校验。补齐过程中**发现并修复真实缺口**：request 入口原未查 enabled（disclose 有、request 无），已补 denyAsNotFound 与 disclose 口径一致。

## OQ-MATCHMAKER-004 · 红娘组长组织边界的 NULL=NULL「平台直属」规则

- **状态**：TBD（技术默认安全值，宁窄勿宽，待产品确认）
- **当前技术默认**：`matchmaker.team.assign` 的范围校验按 `operators.organization_id` 相等判定，**NULL 视为「平台直属」**：平台直属组长（org=NULL）只能分配/管理平台直属红娘；有组织组长不能分配 org=NULL 的红娘；org=NULL 的普通红娘只能由平台授权人员（`matchmaker.assign`）分配。判定实现用 IS NOT DISTINCT FROM / Objects.equals 语义（NULL 与 NULL 相等，不落 SQL `=` 的 NULL 陷阱）。
- **说明**：demo 账号 wanghongniang 即 org=NULL 情况。若产品要求「平台直属红娘由平台授权人员统一管理、组长不得触碰」或相反（NULL 归某默认组织），需改范围校验并回归 ZC-MM-002 测试基线。
- **关联**：DEC-MATCHMAKER-002 规则 4/8；提交 861c78e（ZC-MM-002 D2 决策）。

## OQ-MATCHMAKER-005 · JWT 权限实时查库零缓存的压测复议条件

- **状态**：TBD（技术默认：零缓存；非性能问题不复议）
- **当前实现**：`JwtAuthFilter` 运营分支每请求查 `operators.status` + 查库权限（claims 权限快照降级为只写不读），停用/调岗/权限变更**即时生效**（ZC-MM-006，提交 1be0d98）。未加缓存的依据：运营端为内部后台、流量低，且《决策》§七明确「不得依赖长期缓存继续放行」。
- **复议条件**：仅当运营端压测显示鉴权查询成为瓶颈时复议；届时优先考虑**超短 TTL 缓存（秒级）+ 复效事件主动失效**，并在本项登记缓存窗口期与 MM-LIFECYCLE-001 的回归影响。禁止以技术默认值冒充产品决策。

## OQ-MATCHMAKER-006 · 写接口 404 化防探测的语义边界

- **状态**：RESOLVED（2026-10-10，ZC-MM-006 G4 评估表裁定，此处留痕）
- **裁定**：凡**以资源 ID 寻址**且调用者具备权限码的写端点（assignments transfer/revoke/end、services recommend/followup/complete、referrals 转介创建），「不存在」与「范围违规」统一 404（先落 DATA_SCOPE_DENIED 审计再 404，与读详情同范式）；**无资源寻址的创建类端点**（POST /assignments 创建、POST /services/{id}/assign）维持 403——它们不构成存在性枚举面，且需要明确的权限反馈。
- **留痕原因**：后续新增写端点时按此边界执行；如产品要求创建类也 404 化（牺牲前端错误提示精度换一致性），需回到本项重裁。
- **关联**：DEC-MATCHMAKER-005「越权响应不得泄露目标用户是否存在」；提交 1be0d98；`MatchmakerWriteDenyUniformityTest` 锁定。

## OQ-MATCHMAKER-007 · purpose_code 取值 matchmaker.service.view 已定义未使用（口径漂移）

- **状态**：TBD（QA P2 移交，2026-10-10）
- **现状**：V055/审计写入点的 purpose_code 取值表中定义了 `matchmaker.service.view`，但实际**无写入点**——受限资料查看走 `sensitive_access_logs`（dataType=matchmaker_service_detail，不含 purpose_code），拒绝路径 purpose_code 传 null（audit_logs 已有 DATA_SCOPE_DENIED 语义）。
- **待产品/架构确认**：二选一——(a) 为服务详情成功查看的 audit_logs 补一条带 purpose_code=matchmaker.service.view 的写入（与 SensitiveAccessLog 双写，有噪音成本）；(b) 从取值表删除该定义（登记即口径收敛）。当前行为与 ZC-MM-006 G2 设计一致（拒绝不双写），不构成缺陷，仅口径漂移登记。

## OQ-MATCHMAKER-008 · JwtAuthFilter 运营域与用户域账号状态口径差

- **状态**：TBD（记录性登记，两域状态字段固有差异）
- **现状**：JWT 权限实时回收（ZC-MM-006）后，运营域仅认 `operators.status='active'`，用户域账号状态口径为 `users.account_status='normal'`（含 suspended/banned/closed 等多态）。两域字段模型不同，状态枚举不一一对应。
- **说明**：不构成越权（两域独立判定、各自从严），但若未来要求「统一账号生命周期模型」（如运营也需 suspended 中间态），需产品出统一口径后重构。当前按各自域内语义执行即安全默认。

## OQ-THIRD-PARTY-* · 第三方开放 / 平台化遗留（7 项）

- **状态**：TBD（范围扩张，需产品决策，本轮未擅自实施）
- 详见 `PENDING_DECISIONS.md`「第三方开放 / 平台化遗留待决策项」：第三方凭据机制、限流是否真实生效、
  OpenAPI 对外发布面、`POST /activities/{id}/interests` 语义、第三方调用审计与配额计量、
  敏感字段脱敏边界（第三方场景）、幂等键 TTL 是否按调用方分级。

---

*最后更新: 2026-10-11（二次）— 产品裁决落账：OQ-MATCHMAKER-003 RESOLVED（5 项 LEGAL_VERIFY 全闭环：①组长主审+管理员兜底 ②用户单独同意已实现 ③有效期 7 天 ④保留期 365 天 ⑤审计面满足+NULL=NULL 维持；建议放量前转法务复核留痕）、OQ-MATCHMAKER-009 RESOLVED（分层审批落地，提交 f73a116）、OQ-MATCHMAKER-010 RESOLVED（disabled 行为基线补齐，顺带修复 request 未查 enabled 真实缺口）。此前：2026-10-11 OQ-003 转 IN_PROGRESS / 新增 009~010；2026-10-10 红娘专项新增 OQ-MATCHMAKER-003~008。*