Agent-System-Dev/docs/u7-release-ci-feasibility.md

C4/C5 快速档接入 CI 的可行性（未改 workflow）

状态：只读评估。本次没有修改 .gitea/workflows/ci.yaml，没有在 home-runner 上执行演练， 也没有形成 GATE。第二实例写流量保持关闭。

平台准入（2026-10-13 只读）

Dev main 的分支保护由 API 读出，证据在任务卡 .task/feature-u7-release-roadmap.md， 来源 SELF：

• enable_push 为 false，block_on_outdated_branch 为 true
• enable_status_check 为 false，status_check_contexts 为空，required_approvals 为 0

这与 policy/platform-admission.md 在 2026-10-05 的观察一致，只说明配置当前如此。 它没有证明失败检查或陈旧候选会被拒绝。runner 隔离、token 权限和工作流来源本次没有核验。

因此，即便以后某个 job 变绿，在所有者按该文件完成准入之前，检查单不能把该次运行写成 GATE。 改分支保护属于高后果操作，本评估不准备执行命令。

现有 CI 能提供什么

test-pg 在 ubuntu-latest 上安装 PostgreSQL、pgvector 和 Redis，并以 root 容器、 无 sudo 为前提，用 runuser 或 su 切到 postgres 用户操作已有集群。 现有库端口是 5432，Redis 是 6399。演练端口 18980–18999 与这两个端口不重叠。

workflow 没有写 timeout-minutes。平台默认时限本次没有读取。

脚本直接放进 CI 时会碰到的差异

这些差异来自当前脚本和 workflow 文本。除资源数字外，都还没有在 home-runner 上实测。

1. 磁盘与负载门禁。 tests/ops/lib.sh 的 ops_resource_gate 要求可用空间至少 100GiB，且 load1 不超过 16，否则退出 3。作者机器在核验命令里打印了 local_avail_kb=1164165728、local_id=1000。这是作者主机，不是 runner。 runner 的磁盘和负载未测。未测通过前，job 不能假设自己过得了这道门。
2. pg_ctl 的 PATH。 tests/ops/run_backup_drill.sh 用 command -v pg_ctl， 找不到就退出。scripts/svc.sh 的 pg_bindir 还会找 pg_config --bindir 和 /usr/lib/postgresql/*/bin。Ubuntu 包里的 pg_ctl 通常在版本目录，不一定在 PATH。 作者机器的 pg_ctl 来自 Homebrew，不能外推到 runner。
3. root 下的 initdb。 演练通过 scripts/svc.sh db create 调用 initdb。 workflow 写明运行器容器以 root 运行。PostgreSQL 的 initdb 拒绝 root。 test-pg 避开了这条路，它启动发行版集群再切到 postgres 用户。 本次没有在 runner 上执行 initdb。
4. C5 的固定等待。 run_backup_drill.sh 把标记写入时长写成 -dur 5m， 恢复后还有 sleep 120。脚本没有快速档参数。K1–K7、工件 sha256 和跨用户 404 保持原判据。 缩短标记窗口需要改脚本，并仍能测出不超过 300 秒的 RPO。本次不改脚本。
5. C4 的固定等待。 run_fault_drill.sh --fault all 含约 60 秒的断连窗口和若干秒级等待。 本次没有计时一次完整演练。

若以后要做 job

job 与现有 test、test-pg、svc-realcombo 并列。实现前先在 runner 上确认磁盘、 pg_ctl 位置，以及非 root 用户能否 initdb。通过后的证据要带运行链接、执行身份和完整 SHA。 平台准入未完成时，检查单的写法保持「CI 运行已绿，GATE 未成立」。