交付品質流程：定案需求
狀態：共用實作與隔離驗證已完成，正式產品接線未啟用。Gate、可信CI回寫／受控發布、通知、具名QA及Agent工作包已實作；正式試行待產品資料定案。操作見 使用指引。
工程工作包與驗收條件見 實作計劃。本文件只保留已確認的流程與邊界。
1. 開發、測試與交付順序
| 階段 | 具體動作 | 何時能往下走 |
|---|---|---|
| 契約與情境 | PM 定 spec／AC；QA 先設計情境與預期，BE／FE 協助補可測性 | 需求歧義由 PM 決定；不把「Agent 看過」當成人的核准 |
| 介面約定 | BE 提供固定 OpenAPI／Swagger、錯誤與副作用；FE／設計提供路由、畫面狀態與互動 | 介面夠明確的部分即可腳本化，缺少部分列 owner 與待辦 |
| QA 腳本與開發並行 | QA Agent 在 QA 庫寫驗收；BE／FE 實作並寫自己的單元、元件、整合測試 | 不要求 QA 寫完所有腳本才開發；實際執行需程式與環境可用 |
| 開發自驗與單端 MR CI | 臨時啟動本次 MR 服務及依賴，跑自驗＋固定核准版本的 QA 單端測試 | 必跑 job 與案例全數通過；漏跑、跳過、環境錯或 runner 失敗不得放行 |
| 適用的故障演練 | 有可跑通的正常版本後，在隔離副本驗證測試抓得到指定業務錯誤 | QA＋技術 reviewer 決定是否需做與範圍，於適用的合併／交付關卡前完成 |
| 各端合併 | Reviewer 可提早審查，合併時核對必要 CI、核准與演練 | BE／FE 可各自先合併；須維持相容或以關閉的 feature flag 隔離未完成行為 |
| 固定版本整合 | 整合 owner 部署固定 BE＋FE 產物；QA 庫 CI 跑真實 E2E | 核對實際部署、測試前後版本及必要案例，成功後才交 QA |
| 證據回寫與 QA 驗收 | CI 結果自動回 contract；條件齊全時通知 QA，QA 人工操作與探索 | QA 透過 Agent 對指定版本與範圍具名接受或退回 |
| Gap、回歸與 Gate | 缺陷開 Gap，修復後 QA 重驗並回歸；工具推導總 Gate | 有效測試／演練／人工驗收及既有條件齊備、沒有 blocking Gap 才能通過 |
這些節點可並行，不是每張單都逐站等待。案例設計、腳本完成、尚未執行、測試通過與人類接受必須分別記錄。
設計稿是否需要由 PM 逐張 Jira 判斷，記錄「需要／不需要／待確認」及原因， 不依後台或 App 一律要求。需要時，UI 手動畫 Figma，PM 暫代交接窗口，彙整固定設計版本、 畫面／節點、對應 AC 與必要狀態，交給 FE／QA 並由有權限者納入契約。 不需要時，FE 依 AC 與既有畫面規則提供操作／狀態說明。這是確認的流程方向； IM 目前工具的逐單判斷與角色接線限制見 使用指引。
2. 三套執行位置，責任不同
QA 的驗收腳本統一維護在產品 QA 測試區：可用獨立 QA repo，或放在 contract repo 的 qa/；IM 採後者；BE／FE 自驗測試留在各產品 repo。QA 腳本不複製維護到 BE／FE 分支，CI 只取用核准的固定 commit／套件；tag 必須解析為實際 commit。
以「付款不可重複」為例：
| 執行位置 | 真正測什麼 | 尚未證明什麼 |
|---|---|---|
| BE MR CI | 啟動本次 BE＋隔離 DB；QA 腳本送重複／併發請求，確認回應與付款筆數 | 沒有操作真實 FE |
| FE MR CI | 啟動本次 FE；QA browser 腳本依固定契約 mock API，操作付款、檢查請求、處理中狀態與提示 | 沒有驗真實 BE；SSR／BFF 呼叫須另外配置 mock 服務 |
| QA repo 整合 CI | 固定 BE＋FE 都部署後，操作真實頁面連真實 API，確認最後狀態與副作用 | 自動化覆蓋以外的人工探索仍待 QA |
因此 BE 還沒完成時，FE 可先依介面與 mock 開發、測試、合併。MR CI 自行啟動臨時服務，不需先把本次 MR 部署到 dev。整合 CI 才使用固定的實際部署組合。
QA repo 的整合 pipeline 第一版由人手動選候選版本、環境與範圍啟動；穩定後 QA Agent 可代呼同一 API。只觸發成功不算測試完成。
3. 獨立測試與故障演練
獨立是指測試預期來自需求／介面契約，避免照實作倒推答案。QA 可以與 BE／FE 協作 API、畫面行為、啟動及資料觀察方法；同一 QA Agent 可先設計案例，再寫腳本。QA／產品負責人審業務標準，技術 reviewer 審測試用例、斷言及測試程式，作者 Agent 不可自批。這是職責，不限定 QA 組長；QA 與技術 reviewer 可由同一自然人兼任，兩項審查以 review_role 分別記錄並明示同人兼任，最終 QA 接受仍另行確認。
首次建立標準、重要斷言／fixture／harness 改動、新的高風險行為、漏驗缺陷，需評估故障演練。QA Agent 提建議，QA＋技術 reviewer 確認；一般實作修改不一律重做。
另行指定故障作者，在隔離的程式、服務與資料中只改產品實作，保持驗收測試不變，留下正常綠 → 指定業務斷言紅 → 復原綠。編譯失敗或連不上服務不算抓到指定錯誤。正常產品 CI 仍要求全綠，不以演練「預期失敗」代替產品通過。
4. 回寫、人工接受與 Gap
可信收集器核對 CI project／pipeline／job、原始報告、核准 suite、受測程式及部署產物，將結果自動回 contract。單端完成只更新進度；固定組合整合及必要條件齊備才通知「待 QA 驗收」。產品 MR job 不持有 contract 寫入憑證。
QA 不必手動找技術 MR 或搬報告。QA Agent 顯示本次版本、範圍、測試與待驗項目，由具權限的 QA 人明確接受／退回；核驗人的身分與指定版本後才能寫入。CI 全綠不會自動替人工驗收轉綠。
人工發現 bug 沿用 Gap：
記錄 AC、重現步驟、預期／實際、程式與測試版本、環境、證據及修復端。實作缺陷不自動升需求 revision。
FE 認為應交 BE，先回報理由，由 QA 轉派同一筆 Gap；維持原有授權邏輯。
修復端提交修正後仍待 QA 重驗；修復提交不等於解除，解除個別 Gap 也不等於整體接受。
違反必要 AC 的問題會阻擋；未違反本次約定的後續改善可 open 且
blocks: []。事後分類調整要有授權與稽核，涉及需求範圍由 PM 決定。換了影響驗收的程式、標準、測試或環境，原接受轉待重驗；QA 依影響選範圍，不能直接沿用舊綠燈。純證據／通知回寫不得讓結果自我失效。
5. 多產品與 Agent 的共同入口
同一 framework 提供流程判定、角色權限、Gate／Gap、證據 schema、工具與指引；各產品只配置 repo、owner、測試／啟動 adapter、環境、核准 suite 及安全憑證引用。
擴充既有 dcx open <ticket> --role <role> --json 工作包，使 PM／UI／BE／FE／QA 每次開工或換 Agent 都能取得：產品與角色、AC 範圍、各並行節點的有效狀態、可做／待誰處理、實際可用命令與目錄、輸入產出、完成與交接條件。CLI、Agent 與看板使用同一評估核心；未實作命令不得冒充可用工具。
採產品逐一升級並顯式啟用。未啟用者保留既有行為；啟用卻缺必要設定、證據或 QA 責任人時明確阻擋。先以真實產品試行，再驗第二產品只靠設定與 adapter 接入，不複製共用規則。
6. 現在可以使用
BE 本地範例：真實 HTTP＋SQLite 的正常、故障、復原驗證。
必要案例檢查器：核對核准清單與 JUnit，拒絕漏跑及失敗。
Agent 分工與輸入：說明同源工作包、工具及正式接線邊界。
W0～W8 實作計劃：檔案落點、相依、驗收與正式產品待填資料。