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

12 KiB
Raw Blame History

开放问题 — 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 数量、报送口径、第三方开放遗留。