ci(staging): decouple deployment from main

docs/BUG_HISTORY.md

@@ -3036,3 +3036,17 @@
 - 相关记录：BUG-163
 - 复发自：BUG-163
 - 修复版本：本次提交（staging 精确 SHA 以发布记录为准）
+
+## BUG-178 | staging 发布控制器被默认 main 分支耦合，阻止测试分支独立演进
+
+- 状态：resolved（本地候选，待 staging gate/deploy 验收）
+- 首次发现：2026-08-13
+- 最近更新：2026-08-13
+- 影响面：Gitea staging quality gate、Deploy staging、Migrate Staging Database；production 发布门禁未修改。
+- 用户现象：staging 作为测试分支需要领先或偏离 main 时，旧部署工作流仍要求 main 与 staging 同一 SHA，且 `workflow_run` 从默认 main 加载控制器，导致 staging-only 变更无法按自身已测试工作流发布。
+- 触发条件：`staging` 推送了尚未进入 `main` 的测试提交并完成 quality gate。
+- 根因：staging 发布把 production 的 reviewed-main 收敛约束复用到了测试环境，同时依赖默认分支的 `workflow_run` controller；即使删除 SHA 相等检查，旧 main controller 仍可能继续执行旧门禁。
+- 修复：staging push gate 在发布同一 exact-SHA 的不可变镜像与 allowlisted controller bundle 后，显式从 `refs/heads/staging` dispatch `Deploy staging`，并传入源 gate run ID；deploy 等待并验证该 gate 最终成功，正常发布仍要求当前 staging HEAD，回滚仍要求当前 staging history 中的旧成功 gate SHA。staging migration 只要求当前 staging HEAD 和 exact-SHA gate artifact。main 与 production workflow 均不改动。
+- 验证：工作流契约测试锁定 staging-ref dispatch、源 gate run 证明、无 main 引用、当前 HEAD 防陈旧发布、同一 gate artifact 的 controller/digest 校验和回滚祖先限制；远端 gate/deploy 与运行时 SHA 待本次 staging 发布记录。
+- 防复发：测试环境的部署控制器必须来自被同一 quality gate 证明的 staging SHA；不得重新引入 `workflow_run` 默认分支控制器或 staging/main 相等门禁。production 继续保持独立的 main/staging 收敛要求。
+- 修复版本：本次 staging workflow 提交