31 Commits

Include renames

Author	SHA1	Message	Date
WorkBuddy	69ebf33e18	release: freeze demo v1.1.0 2026-10-19	2026-10-19 20:36:22 +08:00
WorkBuddy	3c2b967274	release: freeze 2026-10-15 validated release baseline	2026-10-15 09:47:31 +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	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	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	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	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	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	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
Codex	60eeb8aef5	docs(brand): 全仓库 Codex 署名统一为 WorkBuddy + 5 个文件重命名 ... ## 背景 用户指令：「先将 codex 的任务一并改为 workbuddy 的任务」。 Codex 已不再运行，当前由 WorkBuddy 承担开发执行，文档署名需同步。 ## 判定规则（用大小写精确区分） | 类别 | 写法 | 处置 | |---|---|---| | 工具署名 | 大写 Codex | → WorkBuddy | | 分支名 | codex/ui-v11-fidelity | → workbuddy-ui-v11-fidelity（去斜杠，规避本仓库 ref 清理） | | 已删除文件的历史路径 | 小写 2026-09-11-codex-baseline-cleanup* | 保持原样（记录真实曾存在的文件名，改了即失真） | 结果：26 个文件、126 处署名替换。残留小写 codex 仅 8 处，全部是历史路径。 ## 文件重命名（git mv，保留历史） - Codex开发执行总指令、项目规则与任务拆解.md → WorkBuddy 同名 - Codex首轮启动提示词 + Phase 01～Phase 26 Jira级任务清单 + 每阶段验收条件.md → WorkBuddy 同名 - docs/善缘丹阳 V1.1 Codex 开发执行计划修订版.md → docs/善缘丹阳 V1.1 WorkBuddy 开发执行计划修订版.md - docs/善缘丹阳 V1.1 Codex-Jira 最终开发任务增量清单.md → docs/善缘丹阳 V1.1 WorkBuddy-Jira 最终开发任务增量清单.md - docs/善缘丹阳 V1.1 Codex最终主启动提示词（整合版）.md → docs/善缘丹阳 V1.1 WorkBuddy最终主启动提示词（整合版）.md 引用已同步：AGENTS.md 6 处、AGENTS_SUMMARY.md、以及 4 份计划/规格文档。 ## AGENTS.md 两处特别处理 - 「git config user.name = Codex」一句改为不点名工具的表述 - 「feature/ fix/ codex/ ui/ 前缀」示例去掉 codex/ ## 有意未改动 - ui-tests/ui-document-baseline-contracts.mjs 的废弃清单仍列 codex-baseline-cleanup* 那是「必须不存在」的断言目标，改了会让哨兵失去意义 - 仓库 git config user.name 仍是 Codex —— 未擅自改动环境身份。 如需彻底交接：git config user.name WorkBuddy && git config user.email workbuddy@local 验证：UI 契约门禁 13/13；AGENTS.md 零 Codex 残留；5 个新文件名与全部引用一致	2026-09-16 14:37:44 +08:00
Codex	984827f415	docs: phase 4 acceptance report + STATUS sync ... - STATUS.md updated: 阶段0-4全部完成, Ready for User Acceptance - New acceptance report: 三端构建/13契约/源码健康度/债务清单 - CapabilityService independentized (AGENTS.md #26 compliance) - discover 筛选完整重设计 (5 chip + 4 section + bottom sheet) - miniapp C组 content/anti-fraud/service-station TS-only - 三端构建全绿: miniapp tsc=0, admin-web vue-tsc=0, vite build OK - 13/13 contracts all green	2026-09-14 11:43:46 +08:00
Codex	0518cda95c	docs: add phase 04-06 recovery reports, gate outputs and execution plan	2026-09-14 10:01:41 +08:00
Codex	c66e42dd8a	docs: retire conflicting UI baselines	2026-09-13 21:12:50 +08:00
Codex	56e8329b59	docs: plan reference-driven dual-client UI redesign	2026-09-13 20:07:43 +08:00
Codex	8b5d2b35f8	docs: define reference-driven dual-client UI redesign	2026-09-13 19:54:31 +08:00
admin	159772f615	docs: plan full dual-client UI redesign	2026-09-11 15:51:03 +08:00
admin	8550ab980d	docs: define dual-client UI redesign	2026-09-11 15:09:44 +08:00
admin	ff451d3185	docs: plan Codex baseline cleanup	2026-09-11 10:15:38 +08:00
admin	8432587b83	docs: define Codex baseline cleanup	2026-09-11 10:13:02 +08:00
admin	ac2327b499	chore: checkpoint before switching to main	2026-09-11 09:07:41 +08:00
admin	45ca118453	feat: deliver V1.1 dual-client UI fidelity milestone	2026-09-10 16:06:11 +08:00