Files
danyang-match/docs/governance/open-questions.md
T
WorkBuddy 6c2601950b docs(governance): ZC-MM-007 同步治理文档——红娘专项 DEC-MATCHMAKER-001~006 收口
- decision-register.md: 登记 DEC-MATCHMAKER-001~006 全部 LOCKED(实施摘要 + 落地提交链 2d60f78/861c78e/5e484d0/3caf5f8/1be0d98 + 验证数字 mvn verify 884/884、UI 契约 24/24、后端契约 198、负向注入 7 处判红→还原)
- open-questions.md: 新增 OQ-MATCHMAKER-003~008——003 受控联系开放前 5 项确认(①②LEGAL_VERIFY)+ ContactAuthorizationPolicy DEFERRED(MatchmakerContactGuardTest 机械锁强制复审)/ 004 NULL=NULL 平台直属规则 / 005 零缓存实时查库压测复议条件 / 006 写接口 404 化语义边界(RESOLVED)/ 007 purpose_code matchmaker.service.view 定义未使用口径漂移(QA P2①)/ 008 运营域 active 与用户域 normal 状态口径差(QA P2②)
- PENDING_DECISIONS.md: 红娘专项六项决策标已落地;新增两项待产品确认——受控联系授权机制开放(OQ-003 引用)、C 端死代码退役 3 项(getCandidates/cancelService/getRecommendationsForUser,grep 零调用已核)专项治理批次

ZC-MM-001~007 全链路闭环(架构师落盘 + 主理人 grep 锚点终验:DEC-MATCHMAKER/DEFERRED/LEGAL_VERIFY/OQ-003~008 全命中,零代码变更)
2026-10-11 10:26:35 +08:00

137 lines
12 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 开放问题 — 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】
- **状态**:TBD(受控联系功能未立项;安全默认 = 不开放)
- **背景**:DEC-MATCHMAKER-003 / B1 已 LOCKED——默认平台内渠道联系,电话/线下联系须专项授权。当前系统**不存在**任何电话/线下联系功能与授权机制(守卫锁定,见下)。
- **开放前必须逐项确认(①②标 LEGAL_VERIFY,需产品 + 法务共同裁决)**:
1. 电话/线下联系例外由**哪个岗位批准**【LEGAL_VERIFY】;
2. 例外授权是否需要**用户单独同意**、如何记录【LEGAL_VERIFY】;
3. 临时授权的**有效期限**(expires_at 语义);
4. 联系授权记录/联系结果摘要的**保留周期**;
5. 授权审批与用户同意的**审计字段与查询面**。
- **DEFERRED**:`ContactAuthorizationPolicy`(形态已预置:`assertContactAllowed(operatorId, userId, channel, purpose)` → `DataScopeGuard.deny`)与 `matchmaker_contact_authorizations` 表**仅在产品确认开放受控联系时立项**。
- **机械锁**:`MatchmakerContactGuardTest`(ZC-MM-003 落地)断言全仓无 ContactAuthorization 类、无 matchmaker_contact_authorizations 迁移、无联系端点——**未来任何人引入受控联系必先触红,强制回到本项复审**,不存在静默绕过路径。
- **关联**:DEC-MATCHMAKER-003 规则 7、《决策》§十一;提交 5e484d0(守卫)、1be0d98(DEFERRED 登记)。
## 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-10 — 红娘专项新增 OQ-MATCHMAKER-003(受控联系开放前 5 项确认,①②LEGAL_VERIFY;ContactAuthorizationPolicy DEFERRED + MatchmakerContactGuardTest 机械锁)/004(NULL=NULL 平台直属)/005(零缓存压测复议)/006(写接口 404/403 语义边界,RESOLVED)/007(purpose_code matchmaker.service.view 未使用口径漂移)/008(运营域 active 与用户域 normal 状态口径差)。此前:2026-09-20 登记 OQ-IDENTITY/PROFILE/MATCH-001 及本地资格保留期、服务站时间、咨询资质、Banner 数量、报送口径、第三方开放遗留。*