danyang-match

Files

T

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

admin-dashboard-data-contracts.mjs

feat: add admin dashboard data adapter

2026-09-13 21:44:58 +08:00

admin-reference-contracts.mjs

test: verify admin reference UI fidelity

2026-09-13 22:09:15 +08:00

admin-role-navigation-contracts.mjs

fix(ops-backend/service-station): close Phase 19 KEEP-VERIFY — 25 defects (unreachable announcements + station write privilege escalation; banner 500 + soft-delete leak; content publish dead-end; program approval dead-end/draft leak/zero counts/missing withdraw; zero-coverage test schema) ; add V042 announcement chain + 34 guard tests; full regression 602 green

2026-09-17 22:21:31 +08:00

brand-assets.mjs

feat: add miniapp reference assets and primitives