danyang-match

162 Commits 2 Branches 8 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
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	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
admin	b46b48eb33	chore: establish V1.1 recovery baseline	2026-09-09 22:05:00 +08:00

Author

SHA1

Message

Date

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

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

admin

b46b48eb33

chore: establish V1.1 recovery baseline

2026-09-09 22:05:00 +08:00