根治三类工程治理问题(技术默认值≠产品规则、配置存在但未闭环、文档代码漂移): - PROFILE-001:profile.photo.maxCount(默认6未确认)+ ProfilePolicy + 服务器端 FOR UPDATE 并发强校验(PHOTO_LIMIT_EXCEEDED,拒绝先于 S3 不留孤儿)+ 前端 mergeAppConfig 嵌套键修复 - CFG-001/IDENTITY-001:IdentityPolicy + GET /verification/liveness-status 真实判定点 (默认关不阻断,开则 enhancedVerified 变化,消除假开关)+ 删死 seed livenessVerification.enabled - MATCH-001:阈值60定为技术默认(消解 PENDING 矛盾)+ V050 recommendation_records.threshold_snapshot 规则版本化 + 删死重复配置类 MatchConfig - DOC-001:新增 docs/governance/(config-register/open-questions/decision-register/ hardcoded-rule-audit/config-drift-audit) - TEST-001:新增守卫 PhotoLimitGuardTest(8)/IdentityLivenessGuardTest(5)/ RecommendationThresholdSnapshotGuardTest(4),均经负向注入可红 全量回归 733/0/0/3(基线717+17新增-1删死测试);UI 契约门禁 18/18;STATUS 升 rc.21
4.4 KiB
4.4 KiB
开放问题 — 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
- 当前技术默认:
identity.liveness.enabled = false(features.livenessEnabled),provider =none - 说明:活体不是 V1.1 首发强制规则。默认关闭时不得阻断实名主流程、不得误提示「必须人脸」。
本轮已把开关接到真实业务判定点(
GET /verification/liveness-status→enhancedVerified), 消除「假开关」。是否启用、选用哪家合规第三方 Provider(OQ选型未定)由产品/合规裁决。 - 关联:
IdentityPolicy、UserIdentity.livenessVerificationStatus、V016。
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-THIRD-PARTY-* · 第三方开放 / 平台化遗留(7 项)
- 状态:TBD(范围扩张,需产品决策,本轮未擅自实施)
- 详见
PENDING_DECISIONS.md「第三方开放 / 平台化遗留待决策项」:第三方凭据机制、限流是否真实生效、 OpenAPI 对外发布面、POST /activities/{id}/interests语义、第三方调用审计与配额计量、 敏感字段脱敏边界(第三方场景)、幂等键 TTL 是否按调用方分级。
最后更新: 2026-09-20 — 登记 OQ-IDENTITY/PROFILE/MATCH-001 及本地资格保留期、服务站时间、咨询资质、Banner 数量、报送口径、第三方开放遗留。