100 Commits

Include renames

Author	SHA1	Message	Date
WorkBuddy	afee993626	release: align H5 demo UI and login	2026-10-21 17:34:03 +08:00
WorkBuddy	69ebf33e18	release: freeze demo v1.1.0 2026-10-19	2026-10-19 20:36:22 +08:00
WorkBuddy	8b505d9133	feat: disable user messaging and retain公益 service guidance	2026-10-15 13:38:17 +08:00
WorkBuddy	3c2b967274	release: freeze 2026-10-15 validated release baseline	2026-10-15 09:47:31 +08:00
WorkBuddy	16c82739db	docs(governance): 受控联系产品裁决落账——OQ-003/009/010 全部 RESOLVED ... - open-questions.md: OQ-MATCHMAKER-003 RESOLVED（5 项 LEGAL_VERIFY 全闭环：①组长主审+管理员兜底 ②用户单独同意已实现 ③有效期 7 天维持 ④保留期 365 天维持 ⑤审计面满足+NULL=NULL 维持；建议放量前转法务复核留痕）；OQ-009 RESOLVED（分层审批：主审岗=approver-authorities 首段走组织范围，兜底岗固定 matchmaker.assign 全量，落地证据=4 条分层用例+注入自证+主理人 Docker 独立实跑 20/20）；OQ-010 RESOLVED（MatchmakerContactDisabledTest 行为基线，顺带修复 request 未查 enabled 真实缺口） - config-register.md: approver-authorities 转「已裁决/分层语义」（键名默认值不变）；enabled/request 读点更新 - PENDING_DECISIONS.md: 受控联系行改「产品裁决全部落定」，剩余决策清零	2026-10-11 16:01:13 +08:00
WorkBuddy	21275ef770	docs(governance): 受控联系立项治理登记（OQ-003 转 IN_PROGRESS / OQ-009~010 新增 / DEC-MATCHMAKER-003-B1 落账） ... - 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 ... 与 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 已闭环推荐恒空（第 6 项）与资料/择偶条件保存失败（第 4 项）， 但清单头部 ⛔ 结论仍写着「第 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 主体纠偏）： - CFG-001 字面化：FeatureFlagConfig.KEY_ALIASES（identity.liveness.enabled / 遗留 livenessVerification.enabled → 实现字段 livenessEnabled，读兼容）+ Controller PUT/DELETE 落库归一到 canonical 键 + V051 迁移（删遗留键、写入 identity.liveness.enabled=false）； MigrationValidationTest 基线 50→51。 - PHOTO-004 真实并发突破：新增 PhotoLimitConcurrencyGuardTest（3 线程 H2 并发冲顶）—— 实测咬住「锁照片行+读时计数」在 H2 MVCC 快照漏读、3/3 全成功突破上限的缺陷； 并发控制改为锁用户行（UserMapper.lockUserRow FOR UPDATE）+ 锁后新语句 COUNT， 0 张照片亦有锁可加（补首张并发缺口）；UserPhotoMapper 计数方法同步替换。 - FF-LIVENESS-003 + canonical 持久化：FeatureFlagPersistenceGuardTest +4 （canonical 加载 / 遗留别名读兼容 / PUT 落 canonical 键 / 切换即生效无旧缓存）、 FeatureFlagControllerTest +3（canonical/legacy/reset）。 - 文档同步：AGENTS.md 规则 27（配置治理纪律）；docs/governance/known-risks.md （7 项含本机 WSL/Docker 故障 KR-07）；config-register / open-questions 更新 canonical 口径； STATUS rc.21 行补 ⑥⑦⑧。 全量回归 741/0/0/3（基线 717 + 25 新增 − 1 删死测试，宿主机 JDK21+Maven 3.9.9 实测， 本机 WSL/Docker 引擎故障期间）；UI 契约门禁 18/18	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 占位文件头 - 发现并补齐 1 处缺口：/me/status 的 localEligibilityStatus/localEligibilityType 此前零断言（实现存在但从未被测）→ 新增 MeStatusLocalEligibilityGuardTest 2 用例 - 首页 #10（counselingEnabled flag 控制入口）登记为被 2026-09-19 产品裁定取代（死配置移除） - 实测：MeStatusLocalEligibilityGuardTest 2/2 绿（离线容器 3:19）	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 / Phase 23B） → 有 硬证据：dev 的 chat-image-enabled: true 覆盖了 FeatureFlagConfig 的 Java 字段默认 false —— 若「仅 Java 字段默认值生效」成立，该值不可能为 true。 仍然成立的部分：T01~T05 模块开关与 T07 私有桶确实全仓零业务调用点（实测 12 个 flag 的 调用点计数全为 0），「死配置」结论正确；失实的只是来源（非 application.yml、非「仅 Java 默认值」）。 新发现 D-22-E：AppController#getConfig（GET /app/config）返回一份硬编码 features map （imageChatEnabled 恒 true，键名与后端 chatImageEnabled 不一致）→ 与 FeatureFlagConfig 双源， 前端读到的开关可能与实际配置相反（如 appealEnabled 实际默认 false）。不静默改契约，登记为遗留。 修正落点：STATUS.md（P26-T06 行 / Phase 22 段 / 历史声明块）、Phase-22 报告（表格行 + D-22-D + 新增 D-22-E）、JIRA_BACKLOG.md、Phase-V11-Deployment-Completion-Report.md、 治理报告新增第九节（含「同一文件并行 Edit 会随机丢失」的事故记录与纪律）。	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 这一历史事实（restore-checkpoint 覆盖面不足的依据），它是稳定事实。 理由：这与本报告自身正在治的病同族 —— 把「随时间变化的量」写成常量，等于制造下一个 「文档与实况不符」的缺口。	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