# R1.1 调查报告

## 结论

- HWLAB `9c91ea0c5c37...` 的 GitHub push delivery 返回 `502`，bridge 日志没有对应新提交，Gitea branch 与 snapshot 均停在 `e76e4d2...`；没有证据表明该请求已被当前 bridge 持久接收。
- GitHub [不会自动重送失败的 webhook delivery](https://docs.github.com/en/webhooks/using-webhooks/handling-failed-webhook-deliveries)。因此修复不能补送 #2492 的历史事件，也不得声称可以恢复；只能等待后续真实、非空且业务必要的 HWLAB source PR merge 产生新 push。
- 当前 PK01 Caddy webhook route 没有有界 ingress retry。bridge 的 YAML retry 只覆盖收到请求后的 Git fetch/push，无法覆盖请求到达前的 FRP/Caddy 连接失败。
- bridge 成功日志没有 `deliveryId`/payload `after`，status 只取 repo 最后一条日志；旧成功可遮蔽新 delivery 失败。
- bridge 使用非原子的 `git push --force` 同时更新 branch 与 snapshot，不能证明两个 ref 全成或全败，也允许重写本应 immutable 的 snapshot。
- mirror observer 在 branch 缺失时按 snapshot ref 字典序选“latest”，会把期望提交隐藏为任意旧 ref。
- webhook status 仅在 delivery 为 `200/202` 时计算 stale，导致 HWLAB `MATCH=false`、delivery `502` 却显示 `STALE=false`，并输出违反自动交付边界的 `REPAIR` 手工同步提示。

## 冻结合同

- ingress 只在能够证明请求体可安全重放时做 YAML 有界 retry；4xx 与业务拒绝不重试。
- bridge 按 `deliveryId/repo/after` 关联并隔离 repo 状态；重复 delivery 幂等。
- branch 与 `snapshotPrefix/<commit>` 通过一次 `git push --atomic` 收敛；snapshot ref 不允许 force rewrite。
- status 以 GitHub head 为期望提交精确判断 branch/snapshot；任一不匹配均为 stale，最新失败不得被旧成功覆盖。
- 不提供 `REPAIR`、sync、flush、webhook-test、人工 PipelineRun 或轮询 fallback。
