8 Commits

Include renames

Author	SHA1	Message	Date
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	f96dcb8aa6	fix(admin): 管理端入口收敛到 /admin/ 子路径，staging 端口 13521，修复生产 /admin/ 假成功 ... 承接 rc.15 的管理端端口收敛（3000 → 13520），本轮把「入口」也收敛到一处： - staging admin 发布端口 3001 → 13521（保持「生产 + 1」错开），同步 tests/uat/run-uat.sh 的默认 UAT_ADMIN_URL。 - 管理端产物改为 /admin/ 子路径部署：vite 构建 base=/admin/（dev 仍为 /，开发与 排查习惯不变）、router history base 跟随 import.meta.env.BASE_URL、三处容器化 入口（生产 nginx / 本地整套栈 nginx / admin-web 容器内 nginx）统一为「不剥离 前缀」转发，形态一致。 - 修复生产 nginx /admin/ 的假成功：原为 alias /usr/share/nginx/html/，而那正是 nginx:alpine 纯净镜像自带的默认页目录（管理端产物不在该容器内），访问返回 200 + nginx 欢迎页 —— 浏览器不报错、状态码正常，只是打开的不是管理端，比 404 更难发现。改为 upstream admin_web + proxy_pass，并以真实两跳容器实测： /admin/ → 200 且为管理端标题与 /admin/assets/*、/admin/dashboard → 200（SPA 兜底）、/admin/brand/logo-mark.png → 200、根路径 → 显式 404（用 location = / 钉住，不依赖「本配置恰好没有 server 级 root」这一偶然事实）。 - 品牌资源引用统一走新增的 src/brand.ts（public/ 资源不受 vite base 影响，原 5 处 写死根路径，子路径部署下会裂图）；favicon 由仓库内并不存在的 /favicon.svg 改为 存在的品牌标。 - 补全 tests/uat/run-uat.sh 被截断的尾部：原文件停在 `if [ -`，bash -n 不通过、 脚本根本无法运行；顺带把此前「定义了却无人消费」的 ADMIN_URL 接到管理端可达性 实测上，并补结果汇总与非零退出码。 - ui-tests：ui-document-baseline-contracts 新增两类一致性断言（staging 发布端口 ⇄ run-uat.sh 默认入口、子路径部署的五处约束）；admin-reference-contracts 的资产 断言适配 brand 模块（断言「组件经 brand 模块引用」+「brand 模块指向正式资产」）。 6 条新增断言全部经负向注入验证（注入对应缺陷 → 守卫变红且信息指向正确对象）。 验证：UI 门控 14/14 绿；vue-tsc EXIT=0；vite build EXIT=0 且产物资源均为 /admin/ 前缀；三份 nginx 配置 nginx -t 通过。 注：docs/STATUS.md 含此前的在途文档改动（非本次工作，且其中引用了已被删除的 plans 文件），故未纳入本提交；本轮的口径更新已写入该文件待一并处理。	2026-09-18 20:51:12 +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
Codex	bc4531a734	feat(api): 补齐 /me/* 命名空间，恢复 17 个 404 调用 + 修 /me/status 过期桩 ... 背景：小程序 services/*.js 按 REST 规范（§16 / §22-§40 / §80 / §83-§84）统一调用 /me/*，但后端从未注册 /me 基路径，个人资料、照片、择偶条件、隐私设置、关系状态、 我的举报/申诉等约 17 个调用全部 404。 后端 - 新增 me/controller/MeController：把既有 service 能力暴露到规范路径（纯委托，不复制 业务规则，AGENTS.md #26）。旧路径（/profile/*、/photos、/relationship/*、 /account/privacy-settings、/risk/reports/my、/appeals/my）全部保留。 - 响应形状按小程序 JSDoc 适配（小程序被 86 页引用，是权威契约）： · /me/relationship-status 返回 status（旧 /relationship/status 返回 relationshipStatus， 字段名不同，前端读的是 result.status） · /me/profile/review-status 返回 {status, items, submittedAt, reviewedAt}，时间统一 epoch 毫秒 · /me/profile/submit-review 返回 {reviewStatus, submittedAt} - 小程序三条历史写法一并兼容：/me/privacy-settings、/me/photos/{id}/main、/me/appeals 修复 - AuthService.getMeStatus：verified / profileStatus / reviewStatus 三项写死为 false / not_started / not_submitted，注释标注"Phase 03/04/05 填充"，但那三个 Phase 早已交付，导致 /me/status 长期返回错误的实名与审核状态。改为 capabilityService + userProfileMapper + reviewTaskMapper 的真实来源（与首页聚合同一判定）。 - PhotoController.deletePhoto：原用 ((Map<?,?>) p).get("id") 强转 UserPhoto 实体， 必然抛 ClassCastException，删除照片恒定 500。改用实体主键比对。 - PhotoService.setMainAvatar（新增）：数据模型以 photo_type='avatar' 标识头像（见 UserPhotoMapper#findAvatar），无 is_main 字段，故"设主图"= 换类型并保证至多一张。 注意：插入该方法时曾把 deletePhoto 原有的 @Transactional 挤到新方法上，导致 "Transactional is not a repeatable annotation" 并引发 Lombok 全面停摆（满屏 找不到 getter/setter），已修正注解归属。 验证 - 后端全量：299 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS（+2 为新增契约测试） - 新增 MeRouteContractTest（2 例）：同时断言 HTTP 方法，锁定 21 条 /me/* 与 13 条旧路径 - 小程序 tsc --noEmit 通过；UI 契约门禁 13/13 文档 - STATUS.md：/me/* 从"待裁决"改为"已完成"；核心待清债务 1 项 → 0 项 - API_INVENTORY.md：顶部"待收敛"警告改为"已收敛"，补全 /me/* 端点表	2026-09-16 12:54:39 +08:00
Codex	93fc9b0d88	feat(miniapp): migrate C-group pages to TypeScript, update contracts	2026-09-14 10:14:05 +08:00
Codex	c66e42dd8a	docs: retire conflicting UI baselines	2026-09-13 21:12:50 +08:00