review-and-merge-workflowlisted

# starledger：審查與合併工作流（2026-07-26+ 現行） （驗證日 2026-07-30。**取代**前代（2026-07-12 era）文件裡的「admin-merge」與「no auto-merge」敘述——那是舊紀元；現行如下。） ## 分支與合併機制 - 分支永遠從**剛 fetch 的** `origin/main` 切（daily sync 直推遠端 main，本地 main 天生落後）。 - 人/agent 的 PR：正常 CI（required：`verify`+`verify-agent-artifacts`+`verify-ai-provenance`， 後兩者對非 artifact PR 是 green no-op）→ 審查收斂 → `gh pr merge <n> --merge`。 **不用 `--admin`**（owner 明令；亦不得越過紅/pending check。註：routine 文件仍留有 「admin 僅用於落 meta-rebase 後的 known-good stale PR」殘句——owner 本紀元的更嚴規則 取代之；strict:false＋meta-rebase 重跑 checks 之下該路徑實質已死）。 `strict:false` ⇒ 合併前確認 checks 是對 current main 跑的——repo 教條（P3.2 原文）是 **無條件**的「merge only when the checks ran against the current main（否則 update branch／meta-rebase 重跑）」；本會話 #205 曾有一次「僅資料 commit 前進、註明後直接合併」 的先例，那是**單次、日期戳 2026-07-26 的裁量**，再用需 owner 逐次同意，不是常設許可。 executor 的 artifact PR 則由 GitHub auto-merge 在三 checks 綠後自動落地。 - **merge 的執行權**：agent 只在 owner 對該類 PR 有明示（或常設書面）授權時執行 `gh pr merge`；沒有授權就呈報收斂狀態（verdicts＋CI＋freshness）等 owner dispatch。 - `delete_branch_on_merge` 開啟；合併風格＝merge commit。 ## Owner 的跨模型審查陣容（owner 決策 2026-07-26，兩次明示） - **每輪**＝grok-4.5（effort high）＋ luna（`gpt-5.6-luna`，effort **max**）。 - **每第 3 輪、以及最終 commit/merge 前那一輪**＋＝ sol（`gpt-5.6-sol`，effort **max**）。 - sol 的 effort 是字面 `max`，**永不** `ultra`（owner 二度更正；本機 codex 設定檔可能仍寫 ultra——用參數覆蓋，勿繼承）。 - 工具面（xcheck wrapper、codex/grok CLI 路徑與旗標）是 **owner 本機事實**：換機器＝ user-must-provide，重新 discovery，勿從本文件回憶 slug/effort。 ## 迴圈紀律（本會話 #205 三輪、#213 兩輪實證） 1. Packet