WorkBuddy
21275ef770
docs(governance): 受控联系立项治理登记（OQ-003 转 IN_PROGRESS / OQ-009~010 新增 / DEC-MATCHMAKER-003-B1 落账）
...
CI/CD Pipeline / Backend Build & Test (push) Canceled after 0s
CI/CD Pipeline / Admin Web Build (push) Canceled after 0s
CI/CD Pipeline / Mini Program Compile Check (push) Canceled after 0s
CI/CD Pipeline / Test Shell Guard (Phase 23 Gate) (push) Canceled after 0s
CI/CD Pipeline / UI Contracts (source-structure gates) (push) Canceled after 0s
CI/CD Pipeline / Migration Validation (push) Canceled after 0s
CI/CD Pipeline / E2E (live stack) (push) Canceled after 0s
- config-register.md: matchmaker.contact.* 五 canonical key 登记（enabled fail-safe 缺省 false / approver-authorities 双岗并列 / consent-deadline-hours 72 / default-validity-days 7 / retention-days 365，均 DEFAULT+CONFIG 非 LOCKED 待产品+法务终审）
- open-questions.md: OQ-MATCHMAKER-003 DEFERRED→IN_PROGRESS（V056 立项实现，双守卫翻转，5 项 LEGAL_VERIFY 逐项标注当前实现态与默认配置键）；新增 OQ-MATCHMAKER-009（审批双岗并列待收敛，OPEN）与 OQ-MATCHMAKER-010（enabled=false 行为用例待补，QA P2-2）
- PENDING_DECISIONS.md: 受控联系行更新为已立项实现（DEC-MATCHMAKER-003-B1，V056，提交 d3735e3）；剩余决策=双岗收敛+LEGAL_VERIFY 终审
- decision-register.md: DEC-MATCHMAKER-003-B1（2026-10-11 LOCKED→已实现）登记，验证数字 mvn verify 895/895、UI 24/24、后端契约 228/CURATED 20、真编译 87 WXML、负向注入 5+2
2026-10-11 13:11:52 +08:00
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
WorkBuddy
3caf5f8816
feat(matchmaker,referral): ZC-MM-005 统一数据范围与字段隐私（DEC-MATCHMAKER-005/§5.2 落地）
...
依据《善缘丹阳 V1.1 红娘角色权限正式决策与开发规则》DEC-MATCHMAKER-005 最小必要原则
与 §5.2 字段级隐私，ZC-MM-005 范围=「读接口行级数据范围统一接入判定器 + 字段白名单 +
组长团队脱敏统计」。承接 ZC-MM-002 落地的 matchmaker_assignments 事实源与
ServiceAssignmentPolicy 判定器。
E1 双轨切纯判定器（不留回退）：
- assertServiceAccess 纯化（删 assigned_operator_id 回退分支），判定器成唯一事实源
- getServiceDetail 删 viewerIsOwner 双态与「非负责人脱敏详情」整段
E2 非负责人防探测 404：
- ServiceAssignmentPolicy.assertActiveAssignmentOrNotFound：无生效分配→先落
DATA_SCOPE_DENIED 审计再抛 NOT_FOUND（响应 404），存在性不可枚举，
与「查无此单」响应体逐字段一致（MM-PRIVACY-001）
E3 字段白名单显式化 + 用户隐私开关：
- 抽取 assembleMatchmakerUserProfile：仅 7 键（displayName/gender/age 派生/regionName/
educationCode/occupationCode/maritalStatus），无 birthDate 原值/详细地址/手机号/微信/
身份证；接 UserPrivacySettings.showOccupation（缺省全放行）
E4 死端点清理：
- 删除 GET /operator/matchmaker/my-services（operatorId 误当 user_id、恒空、前后端零调用），
替代路径 /operator/matchmaker/assignments/my；C 端 /matchmaker/services 与
counseling myServices 保留
P1 残留收口（读/写路径仍信任废弃 assigned_operator_id 残留列，与 E1 同类洞）：
- P1-1 运营端推荐列表：MatchmakerRecommendationMapper.findByOperatorId 改 join
生效分配（active+expires），撤/结后不再可见
- P1-2 dashboard 三计数：count*ByOperator 改 join 生效分配 + COUNT(DISTINCT) 防重，
end/revoke 后不再计入（DEC-002 规则7）
- P1-3 转介授权：ReferralService.assertMatchmakerServesUser 切
serviceAssignmentPolicy.assertActiveAssignment（DATA_SCOPE_DENIED 审计 + 403），
删残留列查询 findActiveByOperatorAndUser
新端点（组长团队脱敏统计）：
- GET /operator/matchmaker/team/statistics（@PreAuthorize matchmaker.team.assign）：
本组织 active 分配数/按红娘分组/在岗红娘数，纯计数无用户 PII；org 边界
IS NOT DISTINCT FROM（NULL=NULL 平台直属）
P2-4 operatorName 脱敏决策：保留不脱敏（§5.2 字段分类：红娘姓名=团队范围内
工作人员标识非用户 PII；组长统计本团队工作量属管理职责），依据登记
docs/governance/open-questions.md OQ-MATCHMAKER-002（RESOLVED）
死代码清理：getOperatorServices（零调用）+ MatchmakerServiceMapper.findByOperatorId
（残留列查询，调用清零）删除；C 端 MatchmakerService 遗留信任残留列按豁免未动（006/007 退役）
测试：
- MatchmakerDataScope005Test（13 用例）：MM-PRIVACY-001/002、MM-AUTH-001/003 读侧、
MM-LIFECYCLE-001 读侧、P1-1/2/3 残留收口负向（撤/结后推荐不可见/计数归零/转介 403）、
防探测逐字段一致、showOccupation 三态
- MatchmakerFieldPrivacyGuardTest（3 用例）：字段白名单源码扫描 + 无导出端点锁定
- MatchmakerReferralPhase13Test 转介口径收紧（IllegalStateException→AccessDeniedException）
- 负向注入自证（P1-3 残留列变异→判红→恢复复绿）
验证：定向 73/73；全量 851/851（3 预存 skip）；UI 契约 24/24。
2026-10-10 11:51:15 +08:00
WorkBuddy
2d60f7899f
docs(audit): ZC-MM-001 红娘角色权限差距审计报告
...
- 基准：《善缘丹阳 V1.1 红娘角色权限正式决策与开发规则》（DEC-MATCHMAKER-001~006
全部 LOCKED，A1/B1 已确认）
- 审计范围：backend matchmaker/referral/audit/security/auth、Flyway V001~V052、
admin-web 红娘页面、现有测试、治理文档；全部结论带文件:行号证据
- 核心结论：A1 分配关系未建模（分配=工单指派）、claim/followup/complete 无归属校验、
/pending 全局队列对全体红娘可见、无红娘组长角色、模块内越权拒绝不落审计
- P0×5 / P1×6 / P2×6 差距清单 + 可复用模块（CounselingService INV-012 范式、
DataScopeGuard、recordSensitiveAccess）+ ZC-MM-002~007 实施顺序建议
- 首次建立 docs/audits/ 目录
2026-10-09 22:46:32 +08:00
WorkBuddy
9fc3385d6c
feat(ci): 新增后端契约门禁 scripts/run-backend-contracts.mjs 并接入 CI
...
CI/CD Pipeline / Backend Build & Test (push) Canceled after 0s
CI/CD Pipeline / Admin Web Build (push) Canceled after 0s
CI/CD Pipeline / Mini Program Compile Check (push) Canceled after 0s
CI/CD Pipeline / Migration Validation (push) Canceled after 0s
CI/CD Pipeline / Test Shell Guard (Phase 23 Gate) (push) Canceled after 0s
CI/CD Pipeline / UI Contracts (source-structure gates) (push) Canceled after 0s
CI/CD Pipeline / E2E (live stack) (push) Canceled after 0s
与 scripts/run-ui-contracts.mjs 同级：固化一组关键后端回归/契约测试
（含 v1.1.0 修复的 3 个回归测试 + JwtAuthFilter Cookie 兜底 + 核心不变量），
先校验测试源文件存在性下限（防改名/删除后门禁假绿），再用 mvn test -Dtest
真跑并解析 surefire 汇总。在 backend job 的 mvn verify 之后执行，复用已
编译产物与依赖缓存，开销极小。同步更新 CODE_REVIEW_STANDARDS.md 门禁说明。
2026-09-30 16:21:25 +08:00
WorkBuddy
ca0db57f24
chore(release): 冻结 v1.1.0 版本
...
- 同步版本号：VERSION / backend pom / admin-web / miniapp 均升至 1.1.0
- 合并本轮代码审查修复（详见 docs/CODE-REVIEW-2026-09-24.md）：
- 后端：微信登录真实实现 RealWechatLoginProvider、实名核验真实实现 RealIdentityVerificationProvider（本地强校验 + 可配置第三方 + fail-closed/fail-fast）
- 照片直传落库端点 POST /me/photos/confirm（fileKey 归属校验 + 对象存在性校验后 savePhoto）
- 刷新 Token Redis TTL 修正（getExpirationMs()*2 的 4h → refreshExpirationMs 的 14 天）
- 管理端 token 改为 HttpOnly Cookie + silent-refresh，移除 localStorage 明文存储与 30+ 处手工注入
- 小程序：红娘接单鉴权头错位修复、serviceType 中文映射、生产域名可配置
- 隔离本地产物（.workbuddy/、*.bundle、*.dump、secrets、application-dev.yml 等已被 .gitignore 覆盖）
未验证项（打标签 ≠ 生产发布）：
- 后端编译 / 单测未在本环境执行（Maven 慢、Docker DNS 受限）
- 管理端 登录→刷新→登出 端到端、小程序真机走查待人工验收
- 生产部署需注入 WECHAT_APP_ID / WECHAT_APP_SECRET、VERIFICATION_API_URL / VERIFICATION_API_KEY 与小程序生产域名
2026-09-30 12:10:00 +08:00
WorkBuddy
e740cbf403
docs(phase26): 上线清单 ⛔ 结论更正为仅第 2/5 项阻塞（第 4/6 项已闭环）+ 覆盖率数字更新
...
commit 44f75ac⛔ 结论仍写着「第 2/4/5/6 项为硬阻塞」，与当前代码事实不符
——会直接把已修项误判为阻塞，或反之让人以为清单已过时而不读。
本次更正为「第 2、5 项仍为硬阻塞」，并把已闭环项与仍阻塞项分列，避免再次过时。
同时把自动化覆盖率数字更新为当前真实值：
后端 757 → 795、UI 契约 22/22 → 23/23（新增 ui-tests/miniapp-profile-contracts.mjs）。
2026-09-23 14:46:03 +08:00
WorkBuddy
44f75acebe
fix(uat): 闭环 UAT 4 项硬阻塞（推荐恒空/保存即失败/越权端点/文档不一致）+ 小程序字段契约
...
UAT 走查（docs/UAT-WALKTHROUGH-2026-09-23.md）发现 4 项硬阻塞，本次闭环其中 3 项
（#2 微信登录、#5 照片直传不在本轮范围），并顺带修掉走查中新发现的跨端字段契约缺陷。
后端
- #6 推荐恒空：新增 MatchScoringService 作为唯一评分事实源（复用 UserPreference 既有
10 维权重，零新造常量）；RecommendationEngineService.calculateScore/generateReasons 由
桩（return 50.0）改为委托；MatchEligibilityService 3 处桩全部去雷。此前 50 < 阈值 60
→ GET /recommendations 恒返回空数组。
- #4 保存即失败：updateProfile / updateBasicProfile / savePreference 改为
「无则插入、有则更新」。注意 UserPreference 实体 @TableId=id 与库主键 user_id 不一致
（V037 后补的可空列），故按 user_id 定位更新而非 updateById（后者会静默不更新）。
gender / birth_date 为 NOT NULL 且向导不采集，缺失时从已通过实名认证的 user_identities
补齐，仍缺则抛 400 业务拒绝，不再让 DataIntegrityViolationException 渲染成 500。
GET /me/profile 的 preferences 补回 5 个此前未返回字段（regionPriority / maritalPriority /
minEducationCode / educationPriority / childrenPriority）。
- #8 越权端点：POST /activities/{id}/interests/confirm 不再直调「建 Match 原语」
RelationshipService.confirmActivityInterest，改为与 /activities/{id}/mutual/* 同一条
二阶段同意链路（createMutualConsent + confirmConnection），单方调用不再可能建 Match
（INV-014 / INV-015）。
- #10 文档不一致：MatchmakerController 类注释更正（operator 端点实际在 /operator/matchmaker）。
- 存量 500 家族：RuntimeExceptionThrowGuardTest 的正则只认 throw new RuntimeException(，
而 17 处裸抛写作 orElseThrow(() -> new RuntimeException(...))，整体绕过守卫（CI 全绿却
仍有 500 家族缺陷）→ 17 处全量改为 GlobalExceptionHandler.BusinessException；
守卫扩为「整段代码 + 该形态」，并加自检断言防止守卫退化成恒真空断言。
小程序（跨端字段名 / 取值契约）
- 字段名对齐后端规范名：hasChildren→childrenStatus、occupationCategory→occupationCode、
workRegion→workRegionCode、ageMin/ageImportance→minAge/agePriority、
educationAccepted/maritalStatusAccepted→minEducationCode/maritalStatuses。
此前字段名对不上，后端读不到 → 字段被静默丢弃。
- 取值修 4 类违反 DB CHECK（写入直接 500）的项：has→yes；high_school→senior_high、
phd→doctor（chk_profile_edu）；occasional→sometimes（chk_profile_smoking/drinking）。
- 预填改读服务端真实字段：此前读 profile.hasChildren / occupationCategory / workRegion，
而服务端返回的是 childrenStatus / occupationCode / workRegionCode → 表单永远回填不上。
- profile-confirm 完成度改为直接采用服务端 profileCompletion（AGENTS 第 9 条：DB 是
Source of Truth），废弃原先 22 条「读服务端不存在字段」的本地猜测式断言。
- 择偶条件页新增「展示形态 ↔ 服务端规范形态」适配器（toApiPayload / fromApiPayload）。
测试与门禁
- 新增 MatchScoringServiceTest、RecommendationEngineServiceBehaviorTest、
ProfileSaveUpsertBehaviorTest、ActivityInterestConfirmConsentBehaviorTest 与
ui-tests/miniapp-profile-contracts.mjs（桩 stores，真跑三个页面的事件处理与 onNext，
断言提交负载用规范字段名与枚举码）。
- MIN_GUARDS 21→23（并修正上一轮漏改：该值当时仍为 21，与守卫数不符，使「数量下限」
保护形同虚设）。
- 负向注入实测：把 #6 评分改回桩 50.0、#4 改回恒 insert、#8 改回绕开二阶段、并注入
orElseThrow 形态裸异常 → 4 个守卫全部变红（含精确定位到 RecommendationEngineService.java:282）。
- 后端：795 tests / 0 failures / 3 skipped；UI 守卫 23/23；语种审计 0 命中；tsc 通过；
wcc/wcsc 真编译 88 WXSS + 86 WXML / 0 失败。
仍未修（需产品/数据决策，见报告 8.3）
- regionScope 需 GB/T 2260 单值区划码，而小程序选项含「镇江其他辖区」这类非单值项 →
不臆造区划码（该约束默认 preferred 软约束，不误过滤）；
- occupationPreference 后端无对应列；settlementPreference 后端无取值字典。
2026-09-23 14:33:43 +08:00
WorkBuddy
0a100548a9
docs(phase26): 上线前准备 — 13 项手动验证清单 + 冒烟脚本骨架 + STATUS 文档矛盾清理
...
- 新增 docs/PHASE26-GO-LIVE-CHECKLIST.md：上线前 13 项人工验证清单
（部署栈存活 / 微信登录 / 运营登录越权隔离 / 资料择偶条件 / 照片 SeaweedFS
直传 / 推荐匹配 / 聊天 / 活动 / 咨询 / 红娘转介 / 内容 / 管理端口径 / 合规备份），
每项含验证方式、通过标准、负责方、关联决策与配置旋钮；自动化子集见脚本。
- 加固 infrastructure/scripts/smoke-test.sh：健康检查 + 匿名鉴权守卫(401) +
安全接口；带 OPERATOR_TOKEN/USER_TOKEN 时展开需登录链路，未提供明确打印
「需人工验证」而非假绿（沿用项目「断言≠证据/不假绿」纪律）。修掉 curl -f
在 4xx 退出码会把 000 拼到状态码后的 bug。
- STATUS.md：修正「V1.1 待实现模块」表把本地资格声明与审核误标 ⏳ 待开发
的矛盾（实际 Phase 04/05 已于 2026-09-12 复验关闭，LocalEligibilityService
已实现），与全文一致。
2026-09-23 11:57:07 +08:00
WorkBuddy
8bd1ab804a
fix(organization): 修复创建机构审计缺操作人；补全机构修复的验证并部署 Docker 测试环境
...
一、机构审计归属缺陷（本轮活栈验收中新发现）
- 现象：audit_logs 中 CREATE_ORGANIZATION 的 operator_id 7/7 为 NULL，
而 DISABLE/ENABLE_ORGANIZATION 均正确记录操作人。审计不可归属 = 无效审计。
- 根因：OrganizationController.create 持有 @AuthenticationPrincipal OperatorPrincipal，
却只把 params 传给 Service，未透传 principal.id() → saveAuditLog(null, ...)。
- 修复：createOrganization(params, operatorId) 签名透传；新增测试断言
createOrganizationRecordsOperatorInAuditLog 长期守卫。
- 复验：新写入的 7 条 CREATE 审计全部带 operator_id，旧 14 条仍为 NULL（前后对照清晰）。
二、补全 rc.22 的验证缺口（此前记为「已修复待验证」）
- 全量回归 757 / 0 / 0 / 3，BUILD SUCCESS，108 个测试类，6:44（基线 741 + 新增 16）。
- 负向注入：ORG_STATUS_ACTIVE 改回 "normal" → 16 例变 3 失败 + 7 错误
（守卫三条断言各自命中 + 服务侧 7 例被 H2 CHK_ORG_STATUS 拦下）。
注入采用「仓库只读挂载 + 容器内副本改写」，工作区哈希前后一致，源码零污染。
- 活栈实测（Docker 全栈）：创建/停用/启用均 2xx、非法输入 400、不存在 404、全程零 5xx（15/15）。
- 对已部署栈 pytest tests/e2e → 65 passed。
三、Docker 测试环境部署与工具链固化
- 测试镜像 danyang-match-backend-test 与命名卷 danyang-m2-cache 因 Docker Desktop 重装丢失，
构建定义此前是临时产物 → 落盘为仓库资产 infrastructure/test-toolchain/Dockerfile。
- 本地栈统一使用 docker compose -p danyang（原项目名 infra 与另一项目撞名，
其 --remove-orphans 会误删本项目容器；已确认邻项目数据无丢失，见 known-risks KR-09）。
四、UI 门禁脆弱性修复
- ui-document-baseline-contracts.mjs 解析 docker-compose.staging.yml 时报假红
（「守卫自身失效」）；真因是该文件为 CRLF 而守卫正则要求 \n 紧随 container_name 之后
（prod.yml 是 LF 所以此前能过）。解析改为行尾无关，真实断言未削弱。门禁 18/18。
五、文档
- STATUS.md 新增 rc.23 并将 rc.22 由「待验证」订正为「已验证关闭」。
- 实施计划附 B.1、PROGRESS-ASSESSMENT-2026-09-21.md 同步订正。
- known-risks.md：KR-07 解除（Docker 已恢复）、KR-01/KR-06 按复测订正，
新增 KR-08（Docker Hub 域名 DNS 被投毒，改用国内镜像源绕行）与 KR-09（compose 项目名撞名）。
验证状态：全量回归 757/0/0/3 全绿；UI 契约门禁 18/18；对已部署栈 E2E 65/65；
负向注入可变红；工作区哈希未被注入过程污染。
未验证：GitHub Actions 首次真绿（仍未推送，见 KR-06）。
2026-09-22 00:46:10 +08:00
WorkBuddy
c195133680
fix(organization): 机构三处写操作必崩 500 修复 + type 白名单 + 测试库约束补齐
...
缺陷本体（实施计划附 B.1，2026-09-19 登记并实测复现，本轮处置）：
OrganizationService 的 createOrganization / disableOrganization / enableOrganization
分别写入 Constants.ACCOUNT_STATUS_NORMAL("normal") 与 ACCOUNT_STATUS_SUSPENDED("suspended")。
那是 users.account_status 的取值，而 organizations.status 的 CHECK 白名单
（V001 chk_org_status）只有 ('active','inactive') → 三个写操作全部违约，
生产必崩 PSQLException violates check constraint "chk_org_status" → HTTP 500。
二阶影响：activities.organizer_org_id NOT NULL ⇒ 无机构即无法新建活动，
运营端「建机构 → 建活动 → 报名 → 互选」链路的第一环是断的。
修复：
- Constants 新增 ORG_STATUS_ACTIVE / ORG_STATUS_INACTIVE（独立于 users.account_status，
附注释说明两者白名单不同，禁止互相复用）
- 三处状态值改为 ORG_STATUS_ACTIVE / ORG_STATUS_INACTIVE
- 新增 OrganizationService.ALLOWED_TYPES + type 白名单前置校验：
非法值返回 VALIDATION_ERROR(400)，不再打到 PostgreSQL 才 500
- 「机构不存在」由裸 RuntimeException(→500 SERVER_ERROR) 改为 NOT_FOUND(404)
- 异常类型统一为 GlobalExceptionHandler.BusinessException —— 独立类
shared.exception.BusinessException 没有 @ExceptionHandler，抛它仍会退化成 500
根因第三重盲区（缺陷长期隐身的直接原因）：
schema-h2.sql 的 organizations 表此前未复刻这两条 CHECK，H2 上写 'normal' 畅通无阻。
已补齐 chk_org_type / chk_org_status 及 NOT NULL / DEFAULT，与生产 DDL 逐值一致。
新增守卫：
- OrganizationConstraintParityTest：生产迁移 DDL ↔ 测试库 schema ↔ 后端白名单 ↔
Constants 四方比对 + 解析器自检（虚构约束名必须解析失败，防断言静默永真）。
其中 status DEFAULT 的解析必须先把范围切到 organizations 建表块 —— 全文件搜索会
误命中 users.account_status（本轮自检脚本实测踩到并修正该缺陷）。
- OrganizationServiceTest：走真实 DB 的 H2 集成测试，9 用例覆盖创建/停用/启用/
停启往返/六个合法 type/非法 type/名称空白/404 语义，断言落库值而非返回值。
⚠️ 未在本机运行测试：本轮探测确认本机无 Docker、无 JDK，wsl.exe 被安全策略阻止
（与 known-risks.md 的 WSL/Docker 故障一致），mvn -o test 与负向注入均无法执行。
已用等价正则的独立脚本验证守卫判别力与两处 DDL 一致性（PASS，脚本留痕
.workbuddy/_verify_org_guard.py）。
补跑全量回归 + 负向注入前，本项记为「待验证」，不得计入已验收。
2026-09-21 20:34:30 +08:00
WorkBuddy
60c591fc68
V1.0.1 纠偏 DoD 补齐：canonical key 字面化（V051+KEY_ALIASES）+ 照片并发突破实测（锁用户行+锁后计数）+ AGENTS 规则27 + known-risks
...
按文档 DoD/约束逐条复查后补齐的差距（承接 438b38d
2026-09-21 11:13:14 +08:00
WorkBuddy
438b38d121
V1.0.1 配置与规则纠偏：照片上限配置化+强校验 / 活体开关闭环 / 推荐阈值快照+规则版本化 / governance 三表+漂移审计
...
根治三类工程治理问题（技术默认值≠产品规则、配置存在但未闭环、文档代码漂移）：
- 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
2026-09-21 02:05:15 +08:00
WorkBuddy
b60c1ffb71
docs: 数据保留 36 个月政策定稿 + 09-20 收尾状态 —— STATUS 版本演进表重排至 rc.20，隐私政策 §3.3/PIA §8 修订，UAT V1.1 用例 46 条（9 角色×7 路径），E2E 65/65 本机模拟 CI 登记
2026-09-20 22:30:44 +08:00
WorkBuddy
76a152bccf
docs(status): 批 2/3 收尾完成登记 —— 全量回归 712/0/0/3 实测、权威行升级（批 1~3 done, awaiting user go）、Phase 21 遗留行清偿状态、rc.16 定稿
...
- 后端基线 700 → 712：MeStatusLocalEligibilityGuardTest(2) + 互选 expires_at 接线守卫(+2, 负向恰 2 红)
+ 随访审计与风险守卫(4) + 红娘注销拦截守卫(4)，全部真实落库守卫
- 批 3 仅余：数据保留流程（待产品决策）、E2E 入 CI 的 GitHub Actions 实测绿
- UI 契约门禁 18/18；本机 E2E 65 passed
2026-09-19 19:39:02 +08:00
WorkBuddy
08b9cb2468
fix(p21-2e): 红娘服务拦截接线（blocker 首次生效 + 竞态兜底）；2d 确认 Onboarding 本地资格已实现；文档回写
...
P16 遗留 2e（红娘服务拦截）：
- checkCanWithdraw 硬编码 0 → 接 MatchmakerServiceMapper.countActiveByUserId（非终态口径
submitted/assigned/in_service/waiting_user，与 findActiveByOperatorAndUser 一致），blocker 首次真正生效
- notifyMatchmaker TODO 空转 → terminateActiveMatchmakerServices 竞态兜底（残留非终态置 cancelled）；
不发通知：Phase 18 D2 的 notifications.user_id→users(id) FK 教训
- 守卫 MatchmakerWithdrawBlockerGuardTest 4 用例全绿；首跑暴露测试基建坑：@Transactional Service
是 CGLIB 代理，ReflectionTestUtils 直调私有方法拿到的是代理实例的 null 字段 → 须先
AopTestUtils.getTargetObject 解包（已在测试内注释说明）
- 另发现历史遗留：countInProgressByOperator 使用白名单外的 'processing'（已登记）
P04-T10：复核确认 Onboarding 本地资格步骤早已实现（onboarding 消息/动作 + 路由 + /me/status 字段），
JIRA ⏳ → ✅ ；清除首页语义错位的死状态 isVerified（miniapp tsc EXIT=0）
文档：JIRA 收尾行/计划文档 Task 3.1/3.3 勾选
2026-09-19 19:30:38 +08:00
WorkBuddy
28cf25756a
test(e2e-recon): E2E 场景对账表（32 项：31 项有真实覆盖、1 项被裁定取代）+ 补 /me/status.localEligibilityStatus 零断言缺口
...
- 对账表写入收尾计划 Task 2.1 节：首页 11 / 本地资格 11 / 权限 10 逐项映射到
E2E 用例与后端集成测试；原始清单取自 commit ae1bd2b
2026-09-19 18:58:07 +08:00
WorkBuddy
e9b99d020b
docs(status): 回写批 2/3 实况 —— 权威行升 09-19（E2E 65 passed / 678+ tests）、Flyway V048、rc.16、Phase 21 遗留行修正（隐私设置已关闭；红娘拦截「无表」判定已推翻）、JIRA 登记批 2/3 收尾、收尾计划 Task 3.1 隐私项勾选
2026-09-19 18:50:00 +08:00
WorkBuddy
0aa5a7b4e6
docs(status): Phase 22 遗留三项更新为 2026-09-19 已处置
...
T01-T05 死开关与 T07 私有桶配置已移除；PUT /feature-flags 已由 V048 做成
真持久化（含重启加载、DELETE 恢复默认、坏值 fail-fast），并如实记录
「多实例内存值不自动刷新」的已知边界。避免与计划文档自相矛盾。
2026-09-19 17:50:49 +08:00
WorkBuddy
d605c04707
feat(flags): PUT /operator/feature-flags 真持久化（V048）
...
此前 updateFlag 只改 FeatureFlagConfig 内存单例的字段：重启即回默认值、
多实例互不一致，表现为「后台显示已关闭，一次发布后功能又回来了」。
- V048 新建 feature_flag_overrides（flag_key 主键；值存字符串、回读按字段
声明类型解析；updated_by 记审计）。updated_by 必须建 uuid 而非 varchar，
否则 UUIDStringTypeHandler 以 uuid 发参数会在 PG 抛
operator does not exist: character varying = uuid（同 V046 的 actor_id）。
- FeatureFlagOverride/Mapper/Service：upsert 走「先 UPDATE、0 行再 INSERT」，
不用 PG 的 ON CONFLICT（H2 测试库不认，同 IdempotencyMapper 取舍）。
- FeatureFlagConfig.reloadFromPersistence() 挂 @PostConstruct：该时机晚于
@ConfigurationProperties 绑定，故 DB 覆盖压得住 yml 默认值。
- PUT 先改内存再落库（内存改动失败即 400，不写库）；新增 DELETE 恢复默认。
- 覆盖值无法解析时启动 fail-fast，不静默回退默认（否则「配了不生效」）。
守卫 FeatureFlagPersistenceGuardTest 11 例，核心是「另起实例重新加载后改动仍在」
（重启等价路径），并自检 @PostConstruct 未被摘掉。
负向验证：注入不落库 + 摘钩子 -> 恰好 5 例变红，其余不受影响；还原 md5 一致。
全量回归 700 / 0 / 0 / 3（起点 689，净 +11）；UI 契约门禁 18/18。
2026-09-19 17:47:16 +08:00
WorkBuddy
018626935a
chore(config): 移除 7 项从未被读取的死配置（5 个功能开关 + 2 个咨询附件桶）
...
产品裁定：确认移除对系统无影响即可移除。移除前的无影响论证（不是「看着没人用就删」）：
全仓搜索 5 个 getter，命中的只有 ① 本类定义处 ② getAllFlags() ③ FeatureFlagControllerTest 一处断言
—— 业务代码零调用点；前端 admin-web/src 与 miniapp 对 feature-flag 零调用（仅一个未使用的 storageKey 常量）。
⚠️ 重要边界：FeatureFlagConfig **整体不能删** —— 同类的 isAppealEnabled（AppealService 4 处）、
isLocalEvidenceUploadEnabled（LocalEligibilityService）、getLocalEvidenceMaxFiles /
getLocalEvidenceMaxFileSizeMB / getLocalEvidenceAllowedTypes（PhotoService）都是**真实生效的 gate**。
本次只删那 5 个死的：counselingEnabled / premaritalEnabled / contentEnabled /
serviceLocationEnabled / localEligibilityEnabled，以及从未被读取的
counselingAttachmentsPrivate / counselingAttachmentsBucket（存储实走 object-storage.bucket-private）。
同步清理 application-docker.yml（application-dev.yml 被 .gitignore 排除，已在本地同步清理）：
否则会留下「配了但不生效」的新死配置 —— 正是本次要消除的问题本身。
getAllFlags() 键数 21 → 14；FeatureFlagControllerTest 布尔样例由 counselingEnabled 换成 referralEnabled。
docs(plan): Task 3.1 全闭 + Task 3.2 前两项已完；附 B 增第 14 项；基线 685→689
Task 3.1（隐私设置）两层均已关闭：① upsert ② 桩接通 + 键集以小程序为准。
Task 3.2 第三项「PUT /feature-flags 不持久化」**仍未处理** —— 改动涉及运维流程
（改的是运行时内存态，重启即失效），与「删死配置」风险不同，需确认做成真持久化还是标注只读后关端点。
附 B-14：新增迁移必须同步更新 MigrationValidationTest.LATEST_MIGRATION（本轮实测踩到），
该守卫还断言「迁移文件总数 == 基线」即不允许缺号，属有效守卫。
全量回归 689 / 0 failures / 0 errors / 3 skipped；UI 契约门禁 18/18 绿。
2026-09-19 17:12:05 +08:00
WorkBuddy
04b07b5821
fix(privacy): updatePrivacySettings 改 upsert —— 同一用户第二次更新不再撞 user_id 主键
...
user_privacy_settings 的主键自 V002 起就是 user_id，旧实现无论记录是否存在都无条件 insert，
导致同一用户第二次更新必然 DuplicateKeyException → 500，隐私设置从此再也改不动。
现改为「存在则按 user_id 更新，不存在才插入」。
更新条件刻意用 user_id 而非实体 id：id 是 V037 为「实体↔表对齐」后补的独立列，
不作为寻址依据 —— 否则历史行 id 缺失时更新会静默失效。
已知边界（未擅自处理）：findByUserId 带 deleted_at IS NULL，若将来引入软删路径，
已软删的行会让本方法走插入分支并撞主键。当前不存在任何软删隐私设置的路径，故不可达；
若将来新增软删，需同步改为 PG ON CONFLICT (user_id) DO UPDATE。已在代码注释中标注。
test(privacy): PrivacySettingsUpsertGuardTest —— 4 用例，全走真实落库（H2），不用 mock 断言调用次数
① 连续更新两次：第二次不得抛异常 + 库中仍只有 1 行（防退化成重复插入，
那会让 findByUserId 的 Optional 返回值抛 TooManyResultsException）
② 部分更新不得把未提交字段重置回默认值
③ 首次更新未提交字段取默认 true
④ 无记录时读取返回全 true 且不落库（固化既有契约）
负向注入已验证：退回无条件 insert → 恰 2 红，失败原因即 DuplicateKeyException；
另 2 个只更新一次的用例正确未红（走不到该分支）。已还原并复跑全绿。
docs(plan): Task 3.1 拆两层并记录进展；附 B 增第 13 项；基线 681→685
⚠️ 关键发现（附 B-13）：隐私设置有两套实现，前端走的是桩那一套 ——
小程序 pages/privacy-settings 调 /account/privacy-settings（AccountLifecycleService 桩，不落库），
管理端对隐私端点零调用。故本次修复位于「前端尚未触达」的路径：必要但当前用户不可感知。
真正的用户可见故障是「改隐私设置根本不保存」（桩），属 Task 3.1 上层，仍待契约裁定。
本次修复是该上层工作的必要前置 —— 桩一旦接到 PrivacyService 立刻会撞上此缺陷。
方法论：评估「某修复的价值」必须先确认前端实际调用哪条路径 ——
本项目同业务存在 /me/* 与 /account/* 多套并存端点，后端有真实实现 ≠ 用户能走到。
2026-09-19 15:49:54 +08:00
WorkBuddy
0242ea44e8
fix(mapper): 补 5 个「只有声明、无任何 SQL」的方法；新建 Mapper 绑定守卫持续挡住该类缺陷
...
全仓无 mapper XML、无自定义 ISqlInjector，自定义方法只能靠注解提供 SQL。
这 5 个方法漏写注解，编译期无感知，调用必抛 Invalid bound statement：
UserPrivacySettingsMapper.findByUserId —— 隐私设置读取
UserPreferenceMapper.findByUserId —— 推荐引擎 / 匹配资格共 6 处调用
ReviewReasonMapper.findAllEnabled —— 审核原因字典下拉
ReviewReasonMapper.findByCategory
ReviewItemMapper.findByReviewTaskId
长期未被发现的原因：候选池为空（分支走不到）+ 测试库根本没有这 4 张表（双重不可达）。
补的 SQL 一律带 AND deleted_at IS NULL —— V037 之后这些表都有软删列，
只看 V002 建表会漏掉软删过滤，制造「读到已删数据」的新缺陷。
test(invariants): MapperBindingGuardTest —— 三用例
① 绑定守卫：反射遍历 MapperRegistry 全部 Mapper 的声明方法，hasStatement 为假即失败；
按「实体有无主键」语义豁免复合主键实体的 selectById/updateById/deleteById 等
（MP 本就不为无主键实体注入，属正确行为；非类名白名单，故新增复合主键表同样适用）。
② 探测自检：虚构 statementId 必须为假，防断言静默永真。
③ 可执行性：插真实数据后真查一遍 —— 绑定存在 ≠ 能跑（本次即借此确认 JsonNode 映射无碍）。
负向注入已验证：移除 ReviewItemMapper 的 @Select → 守卫报恰 1 项缺失，
且可执行性用例抛真实 Invalid bound statement；还原后复跑全绿。
test(db): schema-h2.sql 补 4 张缺失表（user_privacy_settings / user_preferences /
review_reasons / review_items），按 V002 + V037 之后的最终态建模（含 id、deleted_at 与
11 个匹配权重列），并保留 chk_item_type / chk_item_status / chk_pref_priority 约束。
docs(plan): 附 B 新增第 12 项；更正第 11 项中我自己上一轮的错误断言
—— 「表无 id 列导致 insert 必崩」不成立：V037 已补齐 id/deleted_at/权重列。
真实缺陷是 updatePrivacySettings 对已存在记录也走 insert（非 upsert）→ 第二次更新撞主键冲突。
方法论：判断表结构必须遍历全部迁移，只看 CREATE TABLE 会得出与生产相反的结论。
2026-09-19 15:26:35 +08:00
WorkBuddy
9466b2b636
docs(plan): 校正「跑测试命令」两处误判并补全必挂项；登记全量回归实测基线 678/0/0/3
...
本轮自查中先后写下两条错误结论，均系命令/挂载所致而非代码问题，现如实留痕更正：
① 误判「mvn -o 不可用」—— 实为漏挂命名卷 danyang-m2-cache（镜像内置 /root/.m2 仅 132MB，
缺 surefire-junit-platform；命名卷 251MB 含 3.1.2）；
② 误判「35 failures + 54 errors 是回归」—— 实为只挂 backend/ 而非仓库根，
致 MigrationValidationTest / AnalyticsPermissionGrantTest / SecurityPathCoverageTest /
PrincipalInjectionContractTest 等以相对仓库根路径读文件的测试集体 NoSuchFile。
正确命令下全量回归 BUILD SUCCESS：678 / 0 failures / 0 errors / 3 skipped（约 6 分钟）。
附 A 校正表扩至 9 行（含 2 处自身结论更正），Global Constraints 与附 B-9 同步补全两处必挂。
2026-09-19 14:16:19 +08:00
WorkBuddy
b834fa86a0
test(invariants): Phase 23 Task 2.2 —— INV-011 显式行为守卫（9 用例 + 两次负向注入验证）
...
产出 Inv011EvidenceAccessGuardTest：非领取人 / 跨用户佐证 / 非 local_eligibility 任务一律拒绝，
且 successful 与 denied 两条路径都断言 sensitive_access_logs 真实落库（不用 mock 断言）。
另含 3 个结构性守卫（用户侧端点无用户可控 userId 入参、佐证读取入口的双重权限约束、
佐证读取不暴露可伪造 operatorId）与 1 个守卫自检（参数名反射可读，防断言静默永真）。
前置修复：schema-h2.sql 补 sensitive_access_logs 表 —— 该表此前在测试库完全不存在，
而它是「访问留痕」命题的唯一落点，缺失导致该命题根本无法断言（表漂移盲区，与 Phase 12/15/19 同族）。
负向注入两次，均精确命中：
① 停用 requireClaimOwner → 恰 1 红（非领取人用例），其余 8 绿
② 停用 catch 内 denied 审计 → 恰 2 红（非领取人 + 跨用户），第 3 条走 try 外的另一路径故正确未红
两次注入均已还原并复跑全绿（9/9）；V11InvariantsTest 12/12 绿；UI 契约门禁 18/18 绿。
文档：Task 2.2 闭环记录 + 附 A 扩至 7 处校正（含对本文档初稿「机构创建 500 归因」的自我更正，
实测为 chk_org_status 违约而非 id 为空）+ 附 B 扩至 11 项新发现
（5 个 Mapper 方法声明了却无实现、隐私设置三方契约冲突 + 表/实体主键错配、
测试镜像 mvn -o 不可用、本机全量回归会卡住）。
2026-09-19 14:02:52 +08:00
WorkBuddy
e666ee6f8a
feat(e2e): Phase 23 Task 2.1 —— 活动互选 8 场景 + 服务预约 8 场景真实实现（16 个真实用例）
...
背景：`tests/e2e/activity_mutual_consent_test.py` 与 `service_appointment_test.py` 此前是
**诚实占位**（仅 docstring、0 用例，指针指向 run_v11_tests.py），计划 Task 2.1 要求把
文件头保留的场景清单逐条实现为真实 HTTP 用例。本提交完成该任务。
═══ 新增真实用例 16 个（本机活栈 pytest tests/e2e 49 → 65 passed）═══
activity_mutual_consent_test.py（8，覆盖 INV-014/015/006 + AGENTS.md #19/#20）
1 建立互选记录不建 Match（INV-014）
2 单方确认不建 Match（INV-015）
3 双方确认建 Match Episode 且双方可见
4 已有 active Match 时再次双确认必须复用（#19）
5 曾 Unmatch 后重新双确认开启新 Episode：episode +1（#20）
6 一方拒绝不建 Match，对方随后确认也不建
7 超时：已过期记录不得被推动成双确认（含「未过期必须生效」对照，防假绿）
8 单向意向不泄露（INV-006，含「B 确认后必须看到 accepted」反证）
service_appointment_test.py（8）
1 提交预约；2 幂等键重放不得产生第二条；3 运营确认 submitted→confirmed（用户侧同态可见）
4 并发「用户取消 × 运营确认」不得 5xx、最终状态必须收敛；5 我的列表只含本人
6 待确认可取消；7 归属隔离（他人不可读详情/不可取消）
8 运营侧状态闸门：已完成预约不得再被取消
═══ 两个幂等 seed（E2E 前置数据，本机与 CI 通用）═══
- seed_e2e_activity.sql：organization + 两个 activity。
必须建的原因是硬约束而非选择：`activity_mutual_connection_consents.activity_id`
有 **FK 到 activities(id)**（实测约束名 …_activity_id_fkey），而 activities.organizer_org_id
又 FK 到 organizations(id) 且 NOT NULL —— 全新库里三张表全空，互选无活动可挂。
- seed_e2e_service_station.sql：service_location + **站点-运营关联**。
关联必需：运营确认受数据范围约束（`assertOperatorScope` → `canAccessByOperator`），
super_admin **不豁免**，实测 e2e_admin 确认他站预约返回 403。
E2E 因此改用 seed 中该站点关联的 e2e_station。
两个 seed 由测试首用时幂等执行（docker exec psql），无需改 CI 步骤。
═══ 负向注入（Task 2.1 Step 3）═══
③ 撤销 service_station_operator 的 service_appointment.confirm →
恰 2 红（test_operator_can_confirm / test_operator_cannot_cancel_completed，403），其余 6 绿；
④ 触发器强制新建互选记录的对方侧 accepted →
3 红（both_confirm_creates_match_episode / timeout_handled / single_interest_not_leaked），其余 5 绿。
两处均已还原并复跑全绿（65 passed），确认无残留（无 e2e* 触发器、权限计数回到 1）。
**两次失败的注入（记录以免后人重复踩）**：
- 删除站点→运营关联：**无效** —— 测试的 seed fixture 在用例前幂等重放 seed 会自愈该前置条件；
- 改 user_b_status 列默认值：**无效** —— `createMutualConsent` 在 Java 侧显式写 pending，
DB 默认值根本不参与（侧面证明写入路径的权威性）。
═══ 计划文档校正（审阅产物）═══
按实测推翻 4 处失实断言，登记 7 项新发现（详见计划文档「附 A / 附 B」）：
- 推翻：matchmaker_services「无表/需扩权」（实为 V009 已建表且 mapper 齐备）；
门禁 14/14（实为 18/18）；「tests/e2e 现为占位」（实为仅 2 个文件）；
E2E 基线 49（实为 65）。
- 新发现：① `POST /operator/organizations` 必然 500（createOrganization 不赋 id +
IdType.INPUT + 无 DB 默认值；且未校验 chk_org_type）→ 连带「无法新建活动」；
② `createMutualConsent` 从不写 expires_at → 互选永不过期（即批 3 P16-T13，配置与
V041 部分索引空转）；③ 用户侧取消预约不校验状态（已确认/已完成也能自取消），
与运营侧明确拒绝 completed 口径不一致 → 需产品裁定；
④ E2E 环境 organizations/activities/service_locations 均为空表（无迁移种子）；
⑤ 运营数据范围 super_admin 不豁免（预期行为，勿误判）；
⑥ 本机复跑会遇到 Redis 登录锁定键（auth:operator_login_lock:*）；
⑦ e2e_* 账号因 ON CONFLICT DO NOTHING 重跑 seed 不覆盖旧口令。
═══ 验证 ═══
- `pytest tests/e2e` → **65 passed**（含新增 16）；`node scripts/run-ui-contracts.mjs` → **18/18 PASS**，退出 0；
- 本机环境处置（不属代码改动）：把 6 个 e2e_* 账号口令对齐到 CI 口令、清除 Redis 登录锁定键。
- **未验证**：微信开发者工具、CI 上的首次 E2E 实测绿（Task 2.3 Step 3，本机无 Docker Hub 出口）。
2026-09-19 12:28:16 +08:00
WorkBuddy
2ae72aabe7
docs(governance): JIRA Epic 总览表补全状态列（P01~P07 补 ✅ / P23~P26 如实标注）；基线计划 Phase 22 合并重复口径澄清块
...
- Epic 表由 4 列改 5 列：P01~P07（此前漏标）补 ✅ ；P23 部分关闭、P24 待用户确认、P25 待运营、P26 Smoke 待手动
- UAT/RC/Production 当前执行项行更新：/me/* 已收敛，停在 Phase 24 门前
- 基线计划 Phase 22（Deployment/Ops）：合并两次编辑产生的重复口径澄清 blockquote，补回 Files 行
2026-09-19 11:45:27 +08:00
WorkBuddy
b67a56479e
fix(miniapp): 修 P0 请求层崩溃（一个下划线致所有请求卡死）+ 组件 WXSS 违规选择器，再补 3 项门禁
...
═══ 缺陷 1（P0，运行期）：utils/api.js 成功回调调用不存在的方法 ═══
控制台：
TypeError: _this._releaseIdempotencyKey is not a function
根因：类中定义的是 `releaseIdempotencyKey()`，成功回调写成了
`this._releaseIdempotencyKey(...)`（**多一个下划线**）。
**为什么一个字符的笔误是 P0**：该调用位于 `wx.request` 的 success 回调内、
且在 `resolve()` **之前**。抛错 → `resolve` 永不执行 → 该 Promise **永不 settle**
→ 所有页面永远停在 loading，同时 App.onError 刷屏。
即「一次成功请求」本应推进流程，实际把前端整成不可用。
修复不只是改名，而是纠正结构：
- **先 `resolve(body.data)`，再执行收尾动作** —— 收尾逻辑不允许挡在响应路径上；
- 释放动作自带 try/catch + console.warn：释放失败最多是"下次操作没拿到新键"，
不得升级为业务失败。
- 语义未变（勿改）：成功→释放（下次同域操作是新的一次）；失败→刻意不释放
（重试复用同一把键，后端才能识别重复投递）。
═══ 缺陷 2（编译期警告）：组件 wxss 用了标签选择器 ═══
Some selectors are not allowed in component wxss ... (components/recommend-card/index.wxss:1:1092)
实测违规 1 处（23 个组件样式文件全扫）：`.compact-like image` —— 组件 wxss 只允许类选择器。
改为 `.compact-like__icon` 并**同步在 WXML 补上类名**
（只改 wxss 会让样式静默落空，是另一种"假成功"）。
═══ 门禁：15 → 18（既有的全是源码内容断言，抓不到上述两类）═══
- 第15 `wxml-structure-contracts`（上一提交新增，本轮 MIN_GUARDS 基线顺带对齐）
- 第16 `miniapp-self-method-contracts`：扫描 `this._x(` / `self._x(` 等私有调用，
要求同文件有定义（方法简写 / 类字段 / `this._x = 值` / prototype 四种形态）。
**判据先自证假阳性**：首版正则不允许 `.` 前缀，把 `this._unsub = store.bind(this)`
形式误报为未定义（3 个页面）；修正并加反向自检样例固化了该坑。
- 第17 `wxss-component-selector-contracts`：组件 wxss 禁标签/ID/属性选择器。
**作用域刻意只限 miniapp/components/**（page 的 wxss 允许标签选择器，套上去必有误报）。
- 第18 `miniapp-api-client-behavior`：**唯一的行为断言** —— 桩掉 `wx.request` 真跑 api.js，
验证成功 resolve / 失败 retain 键 / 成功 release 键 / 收尾抛错不影响响应路径 4 组。
含 1s settle 超时，直接编码"永不 settle"这一失败模式。
- 新增 `scripts/lib/wxss-selectors.mjs` + `scripts/check-wxss-component-selectors.mjs`（CLI）。
- `MIN_GUARDS` 15 → 18；执行器措辞改为「源码结构与关键行为断言」。
═══ 验证 ═══
- `node scripts/run-ui-contracts.mjs` → **PASS 18 / 18**，退出 0；
- 负向注入：未定义私有方法 / 标签+ID+属性选择器 / 多余闭合标签 → 均精准变红，
且**合法样例（`this._x = 值`、纯类选择器、属性内含 `>`）不被误报**；
行为守卫的负向自证见下一提交/记录；`UI_GUARDS_MIN=99` 拒绝报绿。
- 文档口径同步：AGENTS.md、STATUS.md（4 处当前口径 + 新增 1.1.0-rc.18 行）、ci.yml 注释。
- **未验证**：微信开发者工具真实编译与真机渲染（本机无该环境）。
2026-09-19 11:40:38 +08:00
WorkBuddy
d036c9b986
fix(miniapp): 修复 2 个页面 WXML 结构缺陷，并补第 15 项门禁（WXML 结构守卫）
...
现象：微信开发者工具报
[ WXML 文件编译错误] ./pages/service-history/service-history.wxml
get tag end without start, near `</`
真实缺陷（实测 2 处，非 1 处）：
- pages/service-history/service-history.wxml 多 1 个 </view>
- pages/service-program/service-program.wxml 多 1 个 </view>
（均为单行压缩写法，随更早提交入库；全仓另外 84 个 WXML 结构自洽）
根因不是这两个文件写错，而是**门禁覆盖盲区**：
既有 14 项 UI 契约全是「源码内容 / 清单断言」，没有任何一条会解析 WXML，
所以「14/14 全绿」与「小程序能不能编译」之间没有因果关系。
修复：
1. 删掉两处多余闭合标签 → 86 个 WXML 结构全部自洽。
2. 新增 scripts/lib/wxml-structure.mjs：按**引号状态机**逐字符扫描标签。
不能用懒惰正则 —— 属性值里可以合法出现 `>`（`subtitle="{{unreadTotal > 0 ? ...}}"`），
正则会在引号内的 `>` 处提前收尾，把自闭合标签的 `/` 读掉，报出假阳性。
（首版实现即踩此坑，曾把合法的 messages.wxml 误判为坏文件；已复核排除。）
3. 新增 scripts/check-wxml-structure.mjs（CLI，退出码 0/1/2）。
4. 新增 ui-tests/wxml-structure-contracts.mjs：全量扫描 + **3 组内置自检样例**
（正向样例故意在属性值内放 `>`，把「假阳性」这个坑钉进门禁）。
5. scripts/run-ui-contracts.mjs：MIN_GUARDS 14 → 15（守卫被删/改名仍会拒绝报绿）。
6. 文档口径同步：AGENTS.md、STATUS.md（4 处当前口径 + 新增 rc.17 版本行）；
ci.yml ui-contracts job 注释 14 → 15。历史时点行保留原值。
负向验证（三项，全部通过）：
- 注入「多余闭合 / 未闭合」→ 退出 1，且只报坏文件、合法的 `>` 属性文件未被误报；
- UI_GUARDS_MIN=99 → 拒绝报绿（数量下限分支可自检）；
- CLI 直扫坏目录 → 退出 1。
验证：node scripts/run-ui-contracts.mjs → PASS 15 / 15，0 失败，退出码 0。
未跑：微信开发者工具真实编译（本机无该环境），结论仅由结构判据支撑。
2026-09-19 11:25:05 +08:00
WorkBuddy
6b2ff0f73e
docs: 二次修正 features 断言失实（5 处）—— 原判据「*.yml 无 features 块」被证伪
...
Phase 22 复验报告 D-22-D 的判据「backend/src/main/resources/*.yml 无 features: 块」是错的，
且被上一轮收尾照抄进 STATUS.md（P26-T06 行），属二次传播。
实测事实：
- application.yml（基础） → 无 features 块
- application-dev.yml（默认激活 profile，自 63cbbff）→ 有，21 键
- application-docker.yml（自 730dddd
2026-09-18 21:58:58 +08:00
WorkBuddy
f63e579a8d
ci(e2e): 落地「活栈供给方式」决策 — Compose in CI，并修掉 6 处真实缺陷
...
决策：E2E 活栈在 runner 内用 docker compose 起全栈（postgres + redis + minio + backend），
与本地验证路径完全一致；未采纳「service containers + runner 上 mvn package 后 java -jar」——
那需要为后端另写一套 host 网络配置，等于制造第二条与本地不一致的路径。
本机实测（与 CI 同一序列）：中间件三项 healthcheck 全 Healthy（pg_isready / redis-cli ping /
mc ready local）→ backend /api/v1/health/live 返回 200 → seed 幂等可执行（INSERT 0 0）
→ pytest tests/e2e → 49 passed。
（本机限制：Docker Hub 不可达且无 temurin 基础镜像，未复现 --build；改用本地既有镜像为底座、
挂载当日 16:24 构建的 jar，使被验证的代码版本与 CI 一致 —— 否则是拿 09-09 的旧代码验 09-18 的用例。）
修掉的 6 处缺陷：
1. minio/minio:latest 是滚动 tag → pin RELEASE.2025-09-07T16-13-09Z（否则 CI 拉到的镜像
与本地验证时不同，表现为不可复现的偶发失败）
2. up 未显式列出 minio（靠 depends_on 隐式拉起），而 minio 的 healthcheck 正是 backend
能否启动的前置条件
3. up --build 把构建与起栈耦合，失败日志混杂 → 拆为 build / up 两步
4. 就绪窗口 5min 偏紧（首次构建后仍需 Spring 启动 + Flyway 46 个迁移）→ 7.5min
5. 缺 down -v 前置清卷：seed 用 ON CONFLICT (username) DO NOTHING，残留卷会让账号口令
停留在上一轮 → 登录 401，并伪装成业务失败
6. job 无 timeout（GH Actions 默认 360 分钟）→ timeout-minutes: 30
另：pytest -v → pytest tests/e2e -v。原以为从仓库根收集会误收 tests/*_test.py
（其在 import 期依赖 psycopg2 与 E2E_DB_PASSWORD），实测否定：pytest.ini 的
testpaths = tests/e2e 已限定范围，从根收集正是 49 个用例且无 error。显式传参作为兜底保留。
计划 Task 2.3 由「依赖基础设施决策」改为「已决策并落地」，仅余 Step 3（CI 上实测一次绿）。
2026-09-18 21:58:56 +08:00
WorkBuddy
70134dd62e
docs: STATUS 历史区收敛 951→783 行，修正两处残留假声明，同步治理报告与收尾计划
...
治理报告「八、遗留」第 2 项（STATUS 后半历史区过长）至此关闭。
STATUS.md（951 → 783 行，净减 168）：
- 折叠 2026-09-09 期快照：Phase 01~11 逐项任务表 → 索引表（指向权威结论位置）；旧 Phase 13
首轮表 → 指针；「V1.0 基线状态 + 历史状态记录」两块 → 一段带历史边界声明的治理痕迹。
- 收敛作废/重复块：两块已作废的 Phase 22 历史声明、已作废的 Phase 23「已完成」声明、
「整体进度总结」里重复的 Phase 24~26 摘要。
- 修正两处残留假声明（本轮新发现）：
① `P26-T06 初始化Feature Flags | ✅ (application.yml配置)` → 标「不成立」（依据 Phase 22 复验：
4 份 application*.yml 无 features 块，15 个 flag 实为 Java 字段默认且业务不读取）；
② `Phase 23（V1.1专项测试）— 已完成 ✅ ` → 标「已被 2026-09-18 复验推翻，实为部分关闭」。
- 口径更新：UI 契约测试行 13/13 → 14/14（统一执行器 + 已接入 CI），并注明阶段 4 的历史时点值。
- 三个门禁锚点全部保留并复验：UI REDESIGN ACCEPTED BY USER、Phase 07…已通过用户验收、
管理后台: http://localhost:13520/ 。
同步文档：
- 治理报告：4.4 漏网文档改为「已处置」；悬空引用表最后一行为已关闭；第七节补 UI 门禁入 CI、
执行器负向验证、漏网文档处置三行，并改写 STATUS 收敛行；第八节改为「3 项遗留全部关闭」。
- 收尾计划：批 1 Task 1.1 标完成（Step 1~4 证据齐），并更正「15 个契约文件」为实测 14 个；
验收口径由逐文件执行改为 `node scripts/run-ui-contracts.mjs`。
验证：`node scripts/run-ui-contracts.mjs` → PASS 14/14、退出码 0（含文档基线契约门禁）。
2026-09-18 21:34:47 +08:00
WorkBuddy
b2ef60c04c
docs: 废止漏网报告 Phase-V11-Deployment-Completion-Report（原地重写）+ 修订两处引用
...
治理报告 4.4 登记的「保留待决」项至此关闭（用户确认执行）。
- docs/Phase-V11-Deployment-Completion-Report.md：102 行 → 废止声明，含四要素
（①原文是什么 ②为何失效：16/16 E2E 与 Feature Flags 15 项均被 Phase 22/23 复验推翻
③取代者：STATUS.md / OPS.md / V1_1_CHANGELOG.md ④为何保留而不删除）。
**未删除** —— 本机有「删文件会级联清空父目录」红线，且删除会制造悬空引用。
- docs/Phase-01-V11-Recovery-Completion-Report-2026-09-09.md：引用行标注「已于 2026-09-18 废止」，
并指明结论以 STATUS/OPS 为准，使引用有落点而非悬空。
- docs/Phase-13A-V11-Completion-Report.md：废止声明中「决定保留待决」改为「已同步原地重写为
废止声明」，与实况一致。
原文可从 Git 历史取回：git log --all -- docs/Phase-V11-Deployment-Completion-Report.md
2026-09-18 21:34:33 +08:00
WorkBuddy
c061a55151
docs: 治理报告去掉 bundle 的写死 hash，改为现场可复核判据
...
上一提交在 D7 行与第七节写上「list-heads → main = 4e18272」，但该 ref 指向会随每次
提交变化 —— 报告一旦入库就已经过期，读者复核必然看到不一致。改为只给判据不给值：
- D7 行 / 第七节：删除固定 hash，改为「`git bundle list-heads <file>` 里的
`refs/heads/main` 必须等于 `git rev-parse HEAD`；引用时不要写死 hash」。
- 保留 f96dcb8
2026-09-18 21:23:56 +08:00
WorkBuddy
75272a5c21
docs: 修正治理报告 D7（bundle 先虚后实）+ 补 9 项缺口补记与可复核证据
...
D7 是本轮唯一一处「先报完成、后被证伪」的项，如实修正并留证：
- 原写「✅ 本轮重跑 git bundle create 覆盖至最新提交 | 根目录 *.bundle」，
实测磁盘上并不存在该文件；且当时唯一的 .workbuddy/tmp/restore-checkpoint-2026-09-18.bundle
其 main 停在 f96dcb8，早于 21:15 的三个治理提交 —— 等于治理成果当时无 bundle 保护。
- 已补建 .workbuddy/backup/docs-governance-2026-09-18.bundle（23.3MB，--all），
git bundle verify = complete history，list-heads → refs/heads/main = 4e18272。
- 新增补记：安全网类交付（bundle / tag / 门禁）必须用可验证命令复核
（list-heads 看 ref 指向的提交号、git tag -l、门禁退出码），不能以「命令已执行」为准；
与本项目此前「假成功」同族（生产 /admin/ 返回 200 欢迎页、E2E 只断言常量字符串）——
共性为「验证信号与被验证对象解耦」。
- 第七节补 bundle 可复核证据行；第六节「安全网」行注明其覆盖面不足；
第八节执行纪律补 bundle 路径约定 .workbuddy/backup/<phase>-recovery-<date>.bundle 与 list-heads 校验步骤。
2026-09-18 21:23:19 +08:00
WorkBuddy
4e1827295d
docs: 新增 Phase 23 收尾与 UAT 就绪计划 + 2026-09-18 文档治理报告（方案任务四、五）
...
- 新建 docs/superpowers/plans/2026-09-18-phase23-closeout-and-uat-readiness.md（superpowers 计划格式），
五批：批 1 快速收尾（ui-tests 15 个契约接入 CI —— 目前**只在本地手工跑**，CI 无把关）/
批 2 Phase 23 剩余（E2E 场景真实实现 + INV-011 显式守卫 + CI 串联 E2E【需基础设施决策】+
Phase 22 Deployment/Ops 口径复验）/ 批 3 代码级遗留清偿 / 批 4 UAT 就绪【需用户协作】/
批 5 Phase 25-26 前置登记。STATUS.md 与客户需求基线计划均已引用（方案明确要求）。
- 新建 docs/文档治理报告-2026-09-18.md：五任务执行核对；本轮 9 项缺口（D1~D9）逐项处置；
删除/归档/头注/保留四张清单；悬空引用二分结论（naive 扫描 29 处，其中 **24 处是「已删除对象清单」
里的合法治理证据**，真实悬空 5 处）；**docs/ 目录被 safe-delete 钩子整体移除的事故记录与恢复过程**；
验证证据；4 项遗留。
验证：UI 契约门禁 **14/14 PASS**；ui-document-baseline-contracts 通过（锚点齐全）；
database 文档 59 表 / 46 迁移与迁移文件实测一致。
2026-09-18 21:15:39 +08:00
WorkBuddy
ae2405f645
docs: 状态文件同步到 2026-09-18 实况（方案任务三）
...
- STATUS.md：顶部权威行由 "PHASE 20 COMPLETE"（09-17）更新为 09-18 口径（Phase 01~22 关闭 /
Phase 23 部分关闭 / 三轮横向加固 / 669 tests / 停在 Phase 24 门前）；版本演进表补 rc.11~rc.16；
**合并三处重复的「V1.1 本地部署完成 (2026-09-09)」区块为一处**（996 行 → 946 行）并加
「历史记录边界」声明；清「Phase 04~05 ⏳ 待开发」等与实测矛盾项。契约锚点全部保住
（UI REDESIGN ACCEPTED BY USER / Phase 07 已通过用户验收 / 管理后台: http://localhost:13520/） 。
- AGENTS.md + STATUS.md：UI 契约门禁口径 13/13 → **14/14**（历史时点行保留原值并注明，
不篡改史实）。
- JIRA_BACKLOG.md：Epic 总览表补 P14/P15/P19~P23 的 ✅ （P23 标「部分关闭」）。
- 客户需求基线计划：Phase 07 标题去 "UI REOPENED"；Phase 10~15/19 补 ✅ ；Phase 20/21 勾选
checkbox 并注日期；**Phase 22 如实标「未复验」**（口径澄清：计划的 Deployment/Ops 与 STATUS 的
「部署运维配置扩展（Feature Flag）」是两份不同工作，后者复验结论不构成本节证据）；
Phase 23 标「部分关闭」，第 3/5 项（E2E 场景实现、CI 串联）**不虚勾**。
- PENDING_DECISIONS.md：历史部署声明 10 项按各 Phase Recovery 报告证据回写处置结果
（9 项已关闭 / 1 项部分）；补登 HTTP 与幂等检修遗留的第三方开放待决策 7 项。
- REMAINING_WORK.md：整体重写 —— 原文称 CHANGELOG 3.3MB（实为 4234 字节）、P1-3 指向从未存在的
Phase-23-Completion-Report.md；改为「已关闭 / 仍未完成 / 原编号索引 / 验收标准」四段，保留原编号
以便对照历史引用。
- database 两份：TABLE_INVENTORY 40 表 → **59 表**（带「来源迁移」列）；MIGRATION_GUIDE
V001~V011 → **V001~V046（46 个）**；两份均标注「以 backend/src/main/resources/db/migration/ 为准」。
2026-09-18 21:15:29 +08:00
WorkBuddy
4f37df3284
docs: 废止被取代的 Phase-13A 首轮报告与 V1.0 部署方案（原地重写，不用 git rm）
...
- docs/Phase-13A-V11-Completion-Report.md：2026-09-08 首轮报告自报「✅ 核心链路已完成」，
已被 Phase-13A-V11-Recovery-Completion-Report-2026-09-17.md（CLOSED，Gate 全项通过）取代。
该文件因命名差异（`Phase-13A-` 带 13A、缺数字段）不匹配清理清单的 `Phase-XX-` 模式而漏删。
**原地重写为废止声明**而非 git rm —— 本机 safe-delete 钩子会把「删文件」放大为「删父目录」
（2026-09-18 实测：一次 git rm 导致整个 docs/ 被移除，已从 Git 完整恢复）。
- 部署架构、运维监控、备份恢复与升级方案.md：补 V1.1 取代头注（方案任务二点名要求，此前遗漏）。
另登记一份**不删**的：docs/Phase-V11-Deployment-Completion-Report.md（2026-09-09，含已被推翻的
「16/16 E2E 通过」）—— 它不在方案删除目标模式内，且被保留文档
Phase-01-V11-Recovery-Completion-Report-2026-09-09.md 援引，删除会制造悬空引用，保留待决。
2026-09-18 21:15:13 +08:00
WorkBuddy
16538d7af5
chore(docs): V1.0 前端设计文档归档至 docs/archive/design-v1.0；为仍被援引的 V1.0 总纲文档加取代头注
...
- git mv 4 份 UI 类文档（UIUX 视觉规范/组件库与 Design Token/高保真原型/页面级功能清单）入档，
附 README 说明取代关系：UI 域唯一基线为 docs/superpowers/specs/2026-09-13-* 规格
- 根目录两份 V1.0 WorkBuddy 提示词/总指令：加「已被 V1.1 整合版取代」头注，保留原位
（AGENTS_SUMMARY 与 Recovery 报告仍援引其行号）
- REST API 规范：加「部分取代」头注（V1.1 增量以数据库与API增量设计为准；WebSocket 章节仍为协议出处）
- 根 CHANGELOG.md：加指针指向 docs/V1_1_CHANGELOG.md
- V1.0 业务设计 12 份与部署运维方案按用户决定保留原位不动
2026-09-18 20:25:58 +08:00
WorkBuddy
c77e6fcd63
chore(docs): 删除已被复验推翻或取代的失效历史文档（65 份）
...
- V1.0 自报式 Phase-XX-Completion-Report 26 份（README 已声明其不可信）
- V1.1 首轮 Phase-XX-V11-Completion-Report 21 份（已被对应 Recovery 版复验推翻/覆盖）
- V1.0 时代审查/发布报告 13 份（CODE_REVIEW/FIX_PLAN/ISSUE_TRACKER/发布与 Go-NoGo/UAT/渗透测试/P0 指令/REAUDIT/两次评估）
- 自declared被取代的旧计划 4 份（RECOVERY_PLAN_2026-09-09、当前进度校正、09-14 两份 superpowers 计划）
- IDEA.md（一行备忘）
引用核查：代码/脚本/CI/配置零引用；STATUS.md 与 REMAINING_WORK.md 中两处现行引用随后续文档同步修正；
Phase-10 Recovery 报告与 2026-09-13 UI spec 中的历史叙述引用按原文保留。
治理详情见 docs/文档治理报告-2026-09-18.md。
2026-09-18 20:23:43 +08:00
WorkBuddy
3ff0c0641a
chore(admin): 生产管理端端口 3000 → 13520；守卫扩至三处并容错 CI
...
生产 admin 容器发布端口原为 127.0.0.1:3000 —— 3000 是本机最易被其他项目
（videoos / ai-callcenter）抢用的端口，与新定的管理端端口 13520 不一致。
已改为 127.0.0.1:13520:80（仍绑定 loopback，对外访问走 nginx 80/443 + /admin/）。
⚠️ 该实体改动无法进入本次提交：infrastructure/docker-compose.prod.yml 位于
.gitignore 的「Secrets and certificates」段，刻意不进版本控制（含按主机定制的
部署参数）。因此本次提交承载的是「决策记录 + 守卫」，端口改动只在部署机生效。
守卫 ui-tests/ui-document-baseline-contracts.mjs：
- 由「两处一致」扩为「三处一致」：admin-web/vite.config.ts（权威声明）、
docs/STATUS.md（给人照做的）、docker-compose.prod.yml（生产发布端口）。
- 生产 compose 采取「存在才断言」：CI 全新克隆上该文件不存在，硬 read() 会抛
ENOENT 让门控假红。已实测——移走文件 → 打印 skip 且 EXIT=0；放回 → 断言恢复。
- 明确排除另外两处管理端入口并写清理由：本地整套栈的管理端经 nginx 6688 暴露
（6688 是 nginx 入口，不是纯管理端端口）；staging 的 3001 是为与生产同机共存
而按「生产 + 1」错开（5433/6380/8081/3001），且被 tests/uat/run-uat.sh 的
UAT_ADMIN_URL 默认值依赖 —— 改动它们要同步消费方，不该由本守卫断言等于 vite 端口。
docs/STATUS.md：新增「管理端端口口径」表，记录四种管理端入口的端口与取舍理由，
并显式标注生产 compose 不在版本控制内（否则后人会以为改了没生效）。
验证：ui-tests 门控 14/14；负向验证 prod compose 改回 3000 → 精准报
「docker-compose.prod.yml=3000，vite.config.ts=13520」；文件缺失 → skip 且不假红；
还原后 md5 逐字节一致（71a30653…）；docker compose config 解析出
published=13520 且 host_ip=127.0.0.1（loopback 绑定未丢失）。
2026-09-18 19:49:50 +08:00
WorkBuddy
9c26d4b7b2
chore(admin-web): 开发端口 3000 → 13520，并禁止端口静默漂移
...
本机长期并行运行三个项目（videoos / ai-callcenter / 本项目），3000 属最易被
抢用的端口之一。按用户决定改为 13520。
- admin-web/vite.config.ts：server.port 3000 → 13520
- 同处新增 strictPort: true。vite 默认在端口被占用时静默 +1 退到下一个可用端口，
结果是「文档写 13520、实际跑在 13521」且全程不报错 —— 与本项目反复处理的
「声明与兑现失联」同族。加上后端口被占用会直接失败。
- docs/STATUS.md「当前运行状态」同步为 13520。
- ui-tests/ui-document-baseline-contracts.mjs：新增端口一致性守卫。
端口写在两处（vite.config.ts 是权威，STATUS.md 给人照做），只改一处不会让任何
测试变红，却会让照文档操作的人打不开页面。守卫断言的是「两处一致」而非写死
13520 —— 允许改端口，允许的是「一起改」，不是「只改一处」。
两处解析均用「解析失败即失败」写法，避免正则匹配不到时断言退化成与 undefined
比较而失去意义（本项目踩过的守卫静默失效坑）。
用 assert.equal 而非 assert.match：match 失败会把整份 STATUS.md（3000+ 行）
打进报错，噪声会盖掉真正的不一致信息 —— 负向验证时实测确认。
- .gitignore：忽略 admin-web/vite.config.ts.timestamp-*.mjs。
vite 在 dev server 被强杀（未优雅退出）时遗留该配置临时文件，本机已多次出现。
未改动（有意）：
- CORS 不受影响。CorsConfig 默认拒绝所有跨域是刻意设计，且注释已写明「管理端走
Vite 代理（同源）」—— dev 端口变化不产生跨域。
- infrastructure/docker-compose.prod.yml 的 127.0.0.1:3000:80 是生产 admin 容器
的发布端口，与开发服务器无关，未动。
- releases/v1.0.0-RC.* 内的 3000 为历史发布快照，属冻结记录，不改写。
验证
- UI 契约门控 14/14 全绿（含新增守卫）；vue-tsc --noEmit EXIT=0。
- 负向验证：把 STATUS.md 改回 3000 → 守卫变红并精确报出
「管理后台端口不一致：STATUS.md=3000，vite.config.ts=13520」及行号；还原后复绿。
- 真实启停：dev server 实跑 http://localhost:13520/（HTTP 200），旧端口 3000 无监听。
- strictPort 负向验证：端口被占用时第二实例立即以
「Error: Port 13520 is already in use」退出，未漂移到 13521。
- vite build EXIT=0（19.35s）。
注：vite build 直接执行会失败，栈停在 emptyDir(dist) 且全部位于本机
node-safe-delete-shim（批量删除守卫）内，与本次改动无关；改用全新 outDir 复跑即
成功，据此排除「改动导致构建失败」。该现象此前无记录，已写入技能备查。
2026-09-18 19:36:07 +08:00
WorkBuddy
c561bf46af
docs(idempotency): 统一报告中的计数口径（25 处调用点 / 30 处声明）并补 CI E2E 缺陷到结论行
2026-09-18 16:40:09 +08:00
WorkBuddy
2766e53fe2
docs: 幂等键检修报告；勘误 API_INVENTORY 与 HTTP 报告；同步 STATUS/JIRA
...
新增 docs/幂等键检修报告-2026-09-18.md：记录双向断裂（后端零处读取该头、
前端 Date.now 每次生成新键）、五处审计发现、机制设计与五个取舍
（先占位后执行 / 重放 / 失败释放占位 / 孤儿占位接管 / 作用域含 actor_id）、
列类型不变量扫描、E2E 与守门证据、三处同形状问题的连带修复。
同轮勘误：
- docs/HTTP语义检修报告-2026-09-18.md：其中「Idempotency-Key 已支持」一句
在写下时不成立（后端当时零处读取），已显式标注勘误并保留原文，
以免「结论先于核实」被当作既成事实继续引用。
- docs/api/API_INVENTORY.md：原记载 POST /activities/{id}/interests
「提交活动互选」，后端从未实现（Phase 16 已并入 /feedback 的
interestTargetUserIds），按真实端点重列并附勘误说明。
docs/STATUS.md：迁移范围更新为 V001~V046；回归行更新为 669 / 0 / 0 / 3；
新增「幂等键检修」章节；补登 HTTP 语义检修章节在两份文档中的缺失条目。
docs/JIRA_BACKLOG.md：补登 HTTP 语义检修与幂等键检修两行
（此前均未登记）。
2026-09-18 16:37:47 +08:00
WorkBuddy
ed725daccd
docs(status): record identity scope convergence and the PathPattern ** trap
2026-09-18 15:06:06 +08:00
WorkBuddy
cbb4f64fdc
fix(security): stop operator identity from reaching user endpoints; guard path rules
...
Continues the HTTP-semantics work. Fixing 401/403 exposed a worse defect on the
same axis: who is allowed to reach which endpoint.
Root cause chain:
- PlatformPrincipal has two implementations (OperatorPrincipal / UserPrincipal),
chosen by JwtAuthFilter from the token type.
- `@AuthenticationPrincipal UserPrincipal` against an OperatorPrincipal is a type
mismatch, and Spring Security returns null (errorOnInvalidType defaults to
false) instead of failing.
- 244 uses of that annotation repo-wide; only 48 null-check. The rest NPE -> 500
when reached with an operator identity.
- The fallback rule was `.authenticated()`, which an operator token satisfies, so
such requests did reach user-facing controllers.
Adding ~196 null checks would be mechanical, easy to miss, and does nothing to
constrain future code. The mismatch is between identity type and endpoint, so it
is fixed once, at the authentication layer: the fallback becomes
`.hasRole("USER")` (operator -> ROLE_OPERATOR, user -> ROLE_USER, per JwtAuthFilter).
Operator requests to user endpoints now get 403 before any controller runs.
Trap worth recording: operator endpoints are not all under /operator/ —
/counseling/services/operator/queue, /content/operator/articles,
/activities/operator/checkin/scan, /service-appointments/operator/list and others
sit deeper inside business paths. The first attempt covered them with
`requestMatchers("/**/operator/**")`, which fails at runtime:
PatternParseException: No more pattern data allowed after {*...} or ** pattern element
Spring's PathPattern permits `**` only as the final element. Worse, the symptom is
a 500 from the whole filter chain (Tomcat HTML error page, not our JSON), and E2E
went from 37 passed to 33 failed — an error far removed from its cause. Now the
nine prefixes are listed explicitly, each ending in /**.
Because explicit enumeration can be forgotten as endpoints are added, and because
the failure mode is "operators locked out of their own admin module" (invisible to
user-side tests), SecurityPathCoverageTest parses the OPERATOR rule prefixes out of
SecurityConfig source, walks every *Controller.java, joins class-level and
method-level mapping paths, and asserts every path containing /operator/ is
covered (/auth/operator/** excluded by design). Two things that would silently
neuter it, both handled: it must parse only the .hasRole("OPERATOR") chain — pulling
in the permitAll or fallback rules would mark everything covered — and the test
working directory is the repo root, not the Maven module root.
Verification: negatively validated by removing /content/operator/** -> exactly one
test turns red listing the six affected ContentController endpoints; restored.
E2E 40 passed (37 + 3 identity-isolation cases). Backend regression 664 / 0
failures / 0 errors / 3 skipped.
2026-09-18 15:05:41 +08:00
WorkBuddy
3a4e03a9f9
docs(status): record HTTP semantics remediation; note 3 test assertions that encoded old wrong behavior
2026-09-18 14:38:59 +08:00
WorkBuddy
7682abd85c
fix(api): give failures real HTTP semantics; fix 401/403 confusion and CORS default
...
Phase 23B ended with an E2E assertion changed to expect "HTTP 200 + body.code
== BAD_REQUEST", documented at the time as "this project's convention". That
description was accurate about the code and wrong about the intent: it described
a defect, and I made the test accommodate it instead of fixing it.
Auditing it found the convention was already broken, not merely risky:
- ~100 sites (105, across 30 controllers) do `return ApiResponse.error(...)` /
`forbidden()` / `notFound()` with no exception and no `@ResponseStatus`, so
the HTTP status is always 200. Gateways and APM cannot separate 4xx from 5xx;
callers cannot tell "fix your request" (400) from "don't retry" (403) from
"check state first" (409) from "retry later" (429).
- miniapp/utils/api.js already had 401/403/429 branches that could never be
reached, since the backend never returned those codes. The concrete damage:
an expired token returned 403, so `onSessionExpired` never fired and users
were stuck with no way back to the login flow.
- SecurityConfig had no `authenticationEntryPoint`, so Spring's default
`Http403ForbiddenEntryPoint` returned 403 for unauthenticated calls, with a
framework body that has no `code` field at all.
- CorsConfig defaulted `allowed-origins` to `*` together with
`allowCredentials(true)`, while its comment claimed "localhost only by
default". Comment contradicting code is worse than no comment: it reads as
safe.
- Only 4 files / 15 assertions in the whole backend suite touched HTTP status,
which is how this survived.
Approach: one definition, two applications, zero controller changes.
- ApiResponseCode gains an `httpStatus` field — the single source of truth. The
constructor requires it, so a new code cannot be added without one.
- GlobalExceptionHandler reads status from the enum instead of hardcoding
`@ResponseStatus` per handler.
- New ApiResponseStatusAdvice (ResponseBodyAdvice) fills in the status just
before the body is written, covering all ~100 direct-return sites without
touching them. Two constraints, both noted in code: only downgrade when the
current status is still 2xx (the advice also sees exception-handler results,
and must not override an already-correct 401/403/409), and never alter the
body.
- SecurityConfig: entry point returns 401 with a uniform ApiResponse body;
access denied handler returns 403 likewise.
- CorsConfig: default changed to empty (deny). Both clients are same-origin
anyway — nginx proxies /api/ and Vite proxies /api — so nothing depends on it.
- miniapp api.js: 401/403/429/409 branches now prefer the server's
`body.message`, otherwise "账号已被封禁" would be flattened to "无权限访问".
Implementation trap worth remembering: `ServerHttpResponse` has `setStatusCode`
but no getter, so reading the current status requires casting to
`ServletServerHttpResponse`.
Verification: 37 E2E passed (33 + 4 new contract cases), including a live-stack
check that a controller's direct `notFound()` now yields 404 — that path throws
no exception and never reaches the exception handler, so if the advice were
inactive it would silently return 200 while the enum unit tests stayed green.
Backend regression 662 / 0 failures / 0 errors / 3 skipped (+6 new guards).
The first regression run had 3 failures, all tests asserting the old wrong
behavior (anonymous access expected 403; outsiders reading a conversation
expected 200). Fixed the assertions, not the implementation. Where 404 is used
instead of 403 for "invisible", that is deliberate — it prevents probing whether
another user's conversation exists — and the substantive assertions (e.g. that an
unauthorized response must not leak message bodies) were kept.
Not done, needs a product decision: third-party credential issuance, whether
rate limiting is actually active, publishing OpenAPI externally, per-caller
audit and quotas, pagination/idempotency coverage, desensitization boundaries.
2026-09-18 14:34:58 +08:00
WorkBuddy
730dddde30
test(e2e): Phase 23B — rebuild E2E infrastructure; fix 6 real prod defects it exposed
...
Phase 23 closed as PARTIAL: fake coverage was gone, but the E2E layer itself
was still empty — no conftest.py anywhere, ~15 fixtures that never existed,
6 files crashing at import on os.environ["E2E_PASSWORD"], and CI never ran E2E.
STATUS's "10 E2E files / ~80+ cases ✅ " described files that had never executed.
Infrastructure delivered:
- tests/e2e/conftest.py: ApiClient (trust_env=False — a host http_proxy turns
localhost calls into 502), operator_token(username) / new_user / admin_token
fixtures, and a session probe that calls pytest.exit(4) when the stack is
unreachable. NOT skip: skip would launder "did not run" into "passed".
- pytest.ini, tests/e2e/requirements.txt, and tests/e2e/sql/
seed_e2e_operators.sql — migrations contain NO operator seed at all, so a
fresh database has zero logins; the seed creates 6 e2e accounts with role
bindings, idempotent, password injected via `psql -v pwd`.
- CI job `e2e`: compose up -> poll /health/live (timeout = fail) -> seed ->
pytest -> always teardown. Gate D-23-D is now closed.
- 8 E2E files migrated off import-time env reads; tautological assertions
(`x == t or not x`), a counselor token standing in for content_editor, and a
bare `status_code == 200` claiming to prove INV-020 were replaced with real
permission/behavior assertions.
Six real production defects found only by running against real PostgreSQL
(H2 has zero coverage for all of them):
- D-23B-A (Critical): stale V042__add_appointment_operator_register_permission.sql
left in target/classes; src had replaced it with V042__add_service_location_
announcements.sql. Packing without clean put two V042 in the jar -> Flyway
"Found more than one migration with version 042" -> app would not start.
Guard added: testBuildOutputHasNoDuplicateMigrationVersions scans build output
(src is clean, so only this catches it).
- D-23B-B (High): non-UUID path variable reached the DB -> 500 + leaked
`invalid input syntax for type uuid`. Now rejected at the controller.
- D-23B-C (High): 6 E2E files raised KeyError at import -> never collected.
- D-23B-E (Critical): permissions = 48, role_permissions for super_admin = 18,
matchmaker = 0. V015's "grant all to super_admin" was a point-in-time snapshot;
the 30 permissions added later were never granted. On a fresh stack an admin
cannot create a service station and matchmakers can do nothing. V044 restores
super_admin to its documented definition (not an expansion); the matchmaker
permission set needs a product decision and is left as a residual.
- D-23B-I (Medium): IllegalArgumentException (e.g. invalid activity type) was
unmapped -> 500. Now BAD_REQUEST.
- D-23B-J (High): `operator does not exist: uuid = character varying` — Java
ids are String, columns are uuid, PostgreSQL does not implicitly cast in
comparisons. Fixed at the source with JDBC `stringtype=unspecified` (docker
profile); production datasource comes from deploy env and needs the same.
One judgement retracted: an initial read suggested service_appointment.register
was missing. It is not — the endpoint uses service.assisted_registration, seeded
in V029, and the code deliberately avoids a duplicate permission. Nothing was
changed on that basis.
Verification: 33 E2E passed against a live stack; unreachable stack and a
missing operator password both exit 4 (never skip/pass); backend regression
656 / 0 failures / 0 errors / 3 skipped (baseline 655, +1 guard, negatively
validated by injecting a duplicate V042 -> exactly one test turned red).
2026-09-18 13:50:19 +08:00
WorkBuddy
ae1bd2b734
test(phase23): KEEP-VERIFY — remove 44 pass shells + fake INV tests, add shell guard
...
Phase 23 "可信系统测试重建 (REFACTOR)" re-audit. STATUS claimed "10 E2E
files / ~80+ cases" and "INV-011~020 ✅ "; measurement showed the opposite.
D-23-A (Critical): V11InvariantsTest's 14 cases asserted only Constants
strings. INV-016 "Banner target types" actually asserted ARTICLE_STATUS_*;
INV-017 "home 8 entries" declared local arrays then asserted
firstRow.length == 4 (tautology, never called the home service);
INV-018/019/020 used appointment/article/account status constants as
stand-ins for permission and data-scope checks. Rewritten to 12 cases:
4 real service-behavior guards (INV-013 via real CounselingService.getDetail
— Matchmaker sees null userRequestSummary, with an assigned-Counselor
counter-proof so global sanitization cannot fake a pass; INV-016 reads the
production ALLOWED_TARGET_TYPES whitelist and asserts no external/http/url/
web entry; INV-017 calls real getHome and pins all 8 codes + order;
INV-019 asserts content_editor reads null), plus assertBehaviorTestExists
turning "行为验证见 XxxTest" pointers into executable Class.forName contracts.
D-23-B (High): 44 `pass` shells across 6 files in tests/e2e (4 files were
100% shells). Gate forbids skip/pass shells. Rewritten in place as honest
placeholders with the full scenario lists preserved.
D-23-C (High, residual): the pytest E2E suite is not executable at all —
no conftest.py anywhere, ~15 fixtures (api_client/verified_user/
banner_factory/...) do not exist. Only run_v11_tests.py really runs
(16 cases, needs a live stack + E2E_PASSWORD).
D-23-D (High, residual, NOT fixed): CI does not chain E2E as the plan
requires. Needs an infrastructure decision on how CI provisions a live
stack; not implemented rather than written unverified.
D-23-E (Medium): the CI migration job claimed to "验证 migration SQL 语法"
but only checked file non-emptiness, while the real syntax/baseline checks
live in MigrationValidationTest (already run by the backend job). Replaced
with a real sequence check (naming / non-empty / unique versions / no
gaps); verified by extracting the exact inline script and running it.
New gate: scripts/check-no-empty-tests.py (AST scan, blocks pass-only and
unconditionally skipped tests) + a CI test-shell-guard job. Verified both
ways: 0 findings on the real tree, 2 precise findings on injected shells.
Negative validation: 3 injected production defects (external_url in the
banner whitelist, swapped home entry order, isMatchmaker returning the full
record) turned exactly inv016/inv017/inv013 red, 9 others green, zero
unrelated failures; md5sum -c confirmed byte-identical restore.
Full regression: 655 tests / 652 passed / 0 failures / 0 errors / 3 skipped
(baseline 657; -2 because 14 vacuous cases were merged into 12). The 3
skips carry explicit reasons (2x @EnabledIfEnvironmentVariable(CI=true),
1x @Disabled "需要完整数据库连接") — none is a shell.
Phase 23 is PARTIALLY closed: fake coverage is gone, but the UAT gate
requires the end-to-end chain to actually execute, so "失败为零可进入 UAT"
is NOT claimed.
2026-09-18 11:49:18 +08:00
WorkBuddy