9 Commits

Include renames

Author	SHA1	Message	Date
WorkBuddy	d51c4c6a76	chore: ignore local temporary workspaces	2026-10-20 14:20:23 +08:00
WorkBuddy	b624c43432	fix(ci): 依据 Actions 真实日志修复三处失败（runner 无 pnpm / 门禁缺依赖 / 生产配置未入库） ... 上一轮已把 CI 跑起来并读到真实结果：7 个 job 中 Mini Program 与 Test Shell Guard 通过，Admin Web、Backend、UI Contracts 三个失败，migration 与 e2e 因依赖 backend 被跳过。本轮全部依据 Actions 原始日志定位，而不是本地推测 —— 三者都不是业务代码问题。 1. Admin Web Build：runner 已不再预装 pnpm 日志：Unable to locate executable file: pnpm runner 镜像（ubuntu-24.04 / 2.337.0）的 PATH 里没有 pnpm，而 setup-node 的 cache: 'pnpm' 在 restore 阶段就需要调用 pnpm 可执行文件，于是 job 在第一步失败、 后续步骤全部 skipped。同批的 miniapp job 没配 cache 所以正常通过，正好反向印证。 改为先用 corepack 启用并钉住 pnpm@9.15.9，store 缓存改由 actions/cache 手动配置 （此时 pnpm 才存在于 PATH）。 2. UI Contracts：门禁依赖没装 日志：Cannot find module '.../miniapp/node_modules/typescript/lib/typescript.js' phase04 守卫会用 TypeScript 编译器 API 解析小程序源码，但本 job 此前不装依赖。 本地能跑通只因为工作区早已装过；CI 的每个 job 都在独立 runner 上， miniapp job 安装的依赖不会共享过来。补上 npm install，并修正 workflow 中 「零 npm 依赖、故无需装依赖」的错误注释 —— 与实际不符的声明本身就是缺陷来源。 3. Backend：断言了一个永远不会入库的文件 日志：DeploymentTests.testDockerComposeProdExists 期望 true 实际 false infrastructure/docker-compose.prod.yml 被 .gitignore 列在 「Secrets and certificates」段而排除出版本控制，但这是**误分类**： 该文件不含任何明文密钥，敏感值全部走 ${VAR} 注入、db 密码走 Docker secrets， 文件头注释本身也写着「敏感信息通过 .env 文件注入，不进 Git」。 后果是该测试「本地恒绿（文件在工作区）、CI 恒红（checkout 拿不到）」， 且从本地永远发现不了。现修正 .gitignore 把它纳入版本控制； 真正的密钥仍由 secrets/、certs/、backups/ 等规则挡住。 修复后，此前因 backend 失败而被跳过的 migration 与 e2e 两个 job 也会真正跑起来。	2026-09-22 10:54:24 +08:00
WorkBuddy	c6b48d5d91	fix(ci): 修复三处必致 CI 变红的工程缺陷 ... 排查 Phase 23 收尾项「 GitHub Actions 从未跑绿」时，逐个在本地复刻 CI 的每个 job， 发现三个与业务代码无关、但足以让流水线恒红的缺陷。 1. 依赖锁文件被排除出版本控制（admin-web job 必红） .gitignore 原先同时忽略 pnpm-lock.yaml 与 package-lock.json，导致 CI checkout 后 admin-web 根本拿不到 lockfile。pnpm install --frozen-lockfile 在缺 lockfile 时不是降级重试、而是直接报错，因此该 job 必然失败； miniapp 的 npm install 也因失去锁文件而版本浮动。 现在按包管理器逐一放行：admin-web 走 pnpm、miniapp 走 npm。 admin-web/package-lock.json 仍保持忽略 —— 同一目录并存两把锁会让两种包管理器 各按自己的锁安装，漂移时彼此看不出问题。 2. admin-web/pnpm-workspace.yaml 内容残缺（任何环境下都装不上依赖） 该文件原先只有两行 allowBuilds（esbuild / vue-demi），既无 packages 声明也未写取值。 pnpm 一旦检测到工作目录下存在 pnpm-workspace.yaml 就强制进入 workspace 模式， 随后因读不到 packages 而报 packages field missing or empty。 本仓库 admin-web 只有一个包，现显式声明单包 workspace，并补出 esbuild 与 vue-demi 的 build 白名单 —— 二者 postinstall 是必需步骤： esbuild 下载平台原生二进制、vue-demi 生成 Vue 版本桥接。 3. CI 使用 runner 预装的 pnpm，版本会漂移 pnpm 9 与 10 对「是否默认放行依赖 build 脚本」的语义相反，而上述 allowBuilds / onlyBuiltDependencies 恰好是版本敏感配置项。 runner 镜像升级后 会出现 install 能过、build 变红、且错误信息不指向真正原因的情况。 现钉住 pnpm@9.15.9，使 CI 语义不再随 runner 变化。 本轮同时在本地复刻了 CI 的其余 job： - migration job 的迁移序列校验：51 个迁移文件，版本 1 至 51 连续且唯一，通过。 - test-shell-guard：18 个 Python 文件未发现 skip / pass 空壳，通过。 - miniapp job 的 npm install 加 tsc --noEmit：通过。	2026-09-22 09:40:44 +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	556f95a562	fix(activity-mutual): close Phase 16 KEEP-VERIFY/EXTEND — 7 defects + 1 hidden compile defect (reopenEpisode) + 1 test-fidelity; unify dual-impl to confirmActivityInterest; INV-006 fix; +7 tests (481 green)	2026-09-17 16:47:10 +08:00
WorkBuddy	4e478ce6ba	fix(invariants): Phase 08 复验 —— 修复 INV-004 搜索/详情绕过 Block + matches.source 取值越界 ... 复验（KEEP-VERIFY）在既有 Phase 08 实现中发现 3 处真实缺陷并修复： D1（严重）DiscoverService.searchUsers 不含查看者身份，查询条件既无排除自己也无任何 Block 条件，被拉黑者仍可被搜到并点开 —— INV-004「搜索不可见」整体失效。改为接收 viewerUserId，排除自己，并用新增的 UserRelationMapper.findBlockedUserIdsBothWays（UNION 双向）一次取回后 notIn 批量排除，避免 N+1。 D2 详情路径（DiscoverService / UserProfileService）均无 Block 判断，知道 userId 即可读到被拉黑者资料。两条路径统一加双向判断并返回 null，由 Controller 转 404（不用「已隐藏」以免被用来探测存在）；UserProfileService 中该判断排在隐私设置之前，拉黑不能被对方「允许搜索可见」覆盖。 D3（潜伏，仅 PostgreSQL 暴露）RelationshipService.like() 把关系类型值 "liked" 当 match source 写入 matches.source，违反 V003:91 的 chk_match_source。测试库 schema-h2.sql 该列是裸 VARCHAR(32)、无约束，故长期静默通过。改传 MATCH_SOURCE_USER_LIKE。canonical 路径 RelationService.like 传值本就正确，线上未触发。 测试保真度对齐：schema-h2.sql 补 chk_match_source（与 V003 逐字对齐）与 user_profiles 表（此前测试库无此表，资料查询无法端到端测试）。 新增 DiscoverBlockInvisibilityIntegrationTest（9 用例，@SpringBootTest 真实 H2 + 真实 SQL），覆盖正向/反向拉黑、对称性、排除自己、详情 404 与查自己不受限。P0FixVerificationTest 补 source 回归守卫。DiscoverServiceTest 同步构造签名。 负向验证：临时还原 D3 修复后，4 个用例因 CHK_MATCH_SOURCE 约束违反报错，证明守卫有效。 证据：后端全量 308 tests / 0 failures / 0 errors / 3 skipped（基线 299）；UI 契约 13/13 GREEN。报告 docs/Phase-08-V11-Recovery-Completion-Report-2026-09-16.md。 同步 STATUS.md / JIRA_BACKLOG.md（EPIC-P08-V11 置 ✅）/ 客户需求基线计划 Phase 08 复选框；首轮报告加状态注记（其「Known Issues 无」已被推翻）。.gitignore 忽略 .workbuddy/。	2026-09-16 15:11:38 +08:00
Codex	fd5f4d6e80	chore: add artifacts/backups to gitignore	2026-09-14 10:02:58 +08:00
admin	5b51d5b3f1	feat: complete phase 02 RBAC and data scope recovery	2026-09-10 10:58:43 +08:00
admin	b46b48eb33	chore: establish V1.1 recovery baseline	2026-09-09 22:05:00 +08:00