3.4 KiB
3.4 KiB
Booking V0.1 安全 checkpoint
最后更新：2026-08-12
当前已完成的仓库内处置
- 开发与生产数据库配置不再提交远程连接地址、用户名或密码；开发环境必须通过
TH_HOTEL_DEV_DB_URL、TH_HOTEL_DEV_DB_USERNAME、TH_HOTEL_DEV_DB_PASSWORD注入，生产环境使用对应的TH_HOTEL_PROD_*Secret。 - 默认本地 profile 使用进程内 H2，且关闭 AgentBus 捕获、SuperAgent 分发、Debug EML、文档转换和演示数据入口。
- Git 历史不做重写。历史中曾出现的数据库凭据不得继续使用，也不得从历史恢复到配置文件。
- BR00 原型只在开发态且
VITE_ENABLE_BR00_PROTOTYPE=true时注册；生产构建不暴露原型路由，原型不连接正式 API。
G0 的外部前置条件
数据库管理员必须在部署 Secret 系统中废止/轮换历史泄露的数据库凭据，并记录轮换日期与工单号。此操作不由代码仓库或应用启动过程替代；在收到完成证明前，G0 不得标记为完全通过。
验证边界
- 本地验证使用 H2，不使用远程数据库默认值。
- 远程测试环境只允许通过 Secret 注入连接信息。
- 真实邮件样本、密码和
.planning过程文件不进入产品提交。
测试环境部署与回滚 Runbook
- 先由数据库管理员完成历史凭据轮换，并在 Secret 系统注入新的
TH_HOTEL_BOOKING_PG_URL、TH_HOTEL_BOOKING_PG_USERNAME、TH_HOTEL_BOOKING_PG_PASSWORD；仓库不保存其值。 - 在应用启动前，以同一 Secret 在受控环境执行
scripts/verify-booking-postgresql-migration.sh，并显式设置TH_HOTEL_BOOKING_PG_SMOKE_APPROVED=true。脚本会验证V1–V6、重启、lease/fencing、并发claim和清理；缺少 URL、预期数据库名、凭据或批准标志时失败关闭。 - 如schema含仓库V001旧模型，脚本只在旧migration描述精确匹配、关系对象全部位于allowlist且八张旧业务表 均为空时允许以Flyway version 0记录共存；任一条件不满足即失败。禁止Flyway clean、DROP、RENAME或绕过门禁。
- 仅在确认 schema 仅为
th_hotel_booking且 pre/postflight 通过后，设置TH_HOTEL_BOOKING_PG_ENABLED=true。旧 MySQL 仍只读兼容，不允许双写或跨库事务。 - 如需回滚应用行为，先停止 AgentBus 入口/worker，再将
TH_HOTEL_BOOKING_PG_ENABLED=false并重启；不要执行 Flyway clean、不要删除 schema。已保存的 contracts artifact 与 attempt 供排障和三个月 retention 清理使用。 - 排障从受控查询
GET /api/reservation/booking-processing-runs/{runId}开始；只有FAILEDrun 可调用POST /api/reservation/booking-processing-runs/{runId}/retry。重试只读取已脱敏的 contracts artifact，绝不重拉原件。 - 系统管理员用
GET /api/reservation/booking-processing-metrics观察最近 24 小时的失败、Agent fallback、Risk、积压和重试趋势。该 API 不返回原始邮件、附件、团号或 Secret。
当前外部阻塞
- 获批非生产PostgreSQL已通过V1–V6、幂等重启、lease/fencing和并发claim smoke，合成数据已清理；连接信息 未写入仓库。MySQL V30仍需单独的非生产连接和批准后才能执行真实migration smoke。
- 此数据库Gate不构成Parsing Agent CP5平台放行；独立Main Prompt/Skill/Profile/app/token/API exposure、无PII Provider smoke、告警与人工恢复runbook仍须另行闭合。