交付品質流程：開工實作計劃
2026-10-05：QA Draft MR !67 已追加真 API 寫入測試與 CI 入口。 本機連 dev：唯讀 12 項、寫入／回讀 15 項通過，三輪測資均清理確認；遠端 CI 待登入變數與執行。 stg 才供正式 QA 驗收；部署 SHA 尚未核對，不是完整 QA／W8 驗收。
團隊導入見第 10 節；共用待辦與唯讀 MCP 的收尾／接手見第 11 節（2026-10-04）。第 9 節為歷史換機交接，不再作為待辦入口。
更新：2026-10-04。目標分支：codex/quality-workflow-plan。狀態：共用程式與隔離驗證已實作；正式產品未啟用，W8 試行待真實輸入。
本文件是 現行流程計畫 的工程分解。本分支提供版本化配置／schemas、QA庫與CI範本、隔離runner、可信收集／受控發布／通知、Gap擴充、具名QA與同源Gate／工作包／看板。操作見 使用指引。IM QA 已選 contract repo 的 qa/；既有 Runner 已有工程試行證據，完整品質政策仍未啟用，新單的部署／資料與正式權限接線另行確認。以下 W0～W8 描述完整能力與驗收要求，不是第一張跟跑單必須一次完成的清單。
1. 開工摘要
完整能力的驗證路徑：QA 測試區 → MR 臨時環境單端驗收 → 固定部署組合 E2E → CI 自動回寫 → QA 透過 Agent 具名驗收 → contract Gate。人工發現的實作 bug 沿用 Gap，轉派與解除仍由具權限的 QA 操作。
| 工作包 | 交付結果 | 相依 | 主要負責 |
|---|---|---|---|
| W0 共用設定與試點 | 定產品設定、Agent 工作包介面、Slice／owner 及各端測試命令 | 無 | PM、QA、BE／FE、CI 維護者 |
| W1 QA 測試庫 | 受審案例、BE API／FE 模擬 API 腳本、固定測試版本 | W0 | QA／QA Agent、技術 reviewer |
| W2 產品 MR CI | 臨時啟動本次程式與依賴，跑自驗＋QA 單端測試 | W0；驗收需 W1 | BE／FE、CI 維護者 |
| W3 故障演練 | 指定錯誤的正常／故障／復原證據與具名確認 | W1、可正常跑通的 W2 | QA、技術 reviewer、故障作者 |
| W4 QA 庫整合 CI | 人選固定 BE／FE 產物，在 dev 跑真實 E2E | W1、W2；必要時 W3 | 整合 owner、QA、CI 維護者 |
| W5 實作缺陷 Gap | 新類型、重現證據、QA 轉派／重驗、非阻擋改善 | 可與 W1／W2 並行 | framework 維護者、QA |
| W6 結果回寫與通知 | 可信 CI 結果進 contract，成功後通知待 QA 驗收 | W0 的資料模型；真實驗收需 W2、W4 | framework／CI 維護者 |
| W7 全角色 Agent 與 Gate | 各角色取得狀態／待辦／工具；QA 具名接受、失效與同源 Gate | 工作包骨架依 W0；完整判定依 W5、W6 | framework 維護者、各角色 |
| W8 跨產品驗證與啟用 | 雙產品隔離測試、角色續接與完整流程實測、分批導入 | W1～W7 | 產品 owner、QA、CI 維護者 |
第一張工程 MR 建議從 W0 的共用產品設定／Agent 工作包介面與 W1 的 QA 庫骨架 開始，沿用已有必要案例檢查器。BE／FE 的功能實作與 QA 腳本化並行，不等待整套 QA 腳本寫完才開發。程式審查可以提早開始；合併時才要求必要 CI、審核及本次必要演練齊備。
2. 已確認的執行邊界
2.1 Repo 與三種執行位置
| 位置 | 維護什麼／跑什麼 | 成功的意義 |
|---|---|---|
| contract repo | spec／AC、介面權威引用、QA 計畫引用、Gap、可信證據與人的驗收結論 | 依完整政策推導交付狀態；CI 綠不直接等於 QA 接受 |
| BE repo 的 MR CI | 本次 BE 程式、自驗；從 QA 庫取固定版本的 BE 驗收 | BE 在本次測試環境符合必要條件 |
| FE repo 的 MR CI | 本次 FE 程式、自驗；從 QA 庫取固定版本的 FE 驗收，使用契約一致的模擬 API | 真實前端在約定回應下正確操作與呈現 |
| QA repo 的 CI | QA 維護 API／browser／跨端腳本；整合 job 對實際部署的固定 BE＋FE 組合跑 E2E | 該部署組合的必要整合案例通過，之後交 QA 人工驗收 |
QA 腳本不複製維護在 BE／FE repo。產品 CI 可唯讀 checkout／下載 QA 核准版本到臨時目錄；啟動應用及測試就在同一 job 可互通的環境內執行，避免跨 pipeline 無法連到臨時網址。QA suite 用 commit／不可變套件識別；1.0.0 可作人讀 tag，但須解析並記錄其實際 commit，不能每次拿浮動分支最新值。
後續若改用 QA downstream job 執行單端測試，必須傳遞指定 MR 產物並安排可達的環境，且上游等待實際測試結果。第一輪先採產品 job 取 QA 套件，降低跨環境連線成本。
2.2 開發前與開發中分別交什麼
| 提供者 | 最小輸入 | 不足時怎麼處理 |
|---|---|---|
| PM | spec／AC／業務規則、成功與失敗預期、固定版本 | QA 回提歧義，由 PM 定義 |
| BE | 固定 OpenAPI／Swagger、請求回應與錯誤語義、必要副作用與可查詢結果 | 介面未定先列待決；不能用現有實作猜 expected |
| FE／設計 | 畫面路由、操作與狀態表、提示與互動約定；可沿用既有設計稿 | 補出可觀察的預期行為，不要求開發前就有完整 DOM |
| BE／FE | 開發中逐步補啟動／停止命令、ready 檢查、測試設定、資料準備／重置、可用 URL | 無法啟動標為環境未就緒，不填 passed |
| QA | AC → 情境 → 必要案例 ID → 檢查點；固定測試與 mock／fixture 版本 | 區分案例已設計、腳本已撰寫、未執行、失敗、通過 |
QA 可先寫案例；介面確定後逐步寫腳本，等相應程式與環境可用才執行。QA 可讀 API／畫面約定並協作測試入口；expected 依需求建立。測試作者不取得實作 diff 與開發推理來倒推答案；可執行產物的黑箱操作不等於讀實作。
2.3 跨產品共用框架與產品設定
使用者明確要求：每個採用 contract 的產品，都應透過同一套工具得到角色指引、當前流程及下一步，不依賴原始討論或某位 Agent 的記憶。共用流程能力屬 framework 正式交付範圍，第一個產品只是驗證點。
| framework 共用 | 每個產品自行設定 |
|---|---|
| 流程規則、狀態推導、角色權限、Gate、Gap 交接、證據與驗收 schema | product ID、contract／BE／FE／QA project 與 repo、ownership |
| Agent 工作包、命令說明、角色指引、生成器與版本相容檢查 | 各端技術棧、啟動／測試／reset／ready 介面、Runner 與測試環境 |
| CI／QA 庫範本、可信來源核驗與通知介面 | 核准 suite pin、必要案例、部署產物來源、通知對象、憑證引用 |
共用模組不硬編產品名稱、路徑、票號前綴、GitLab project ID 或 Python／Node 等技術棧。產品透過版本化設定與 adapter 接入，不能為每個產品複製一套 dcx／Gate 邏輯。設定沿用 .delivery-contracts 的產品識別與 framework pin，新增部分需 schema 與 doctor 檢查；密鑰只留安全引用，不進 Agent 工作包。
角色啟用與職責對應依產品 ownership 宣告；整合 owner／技術 reviewer 是責任，不強加新的 CLI 角色。啟用這套完整流程時必須有人承擔 QA 驗收，不能因 QA inactive 就略過最終接受。不同產品可選測試工具及適用案例，但必要驗收、可信證據與人類確認的規則一致。
新產品的接入範本預設列出完整流程；既有產品逐一檢查、升級 pin、生成指引並啟用。分批導入是上線方式，不表示流程只提供給首個試點。保留未啟用產品的舊行為，避免未備妥環境時無預告改變關卡。
3. 共用資料與狀態設計
W0 先定以下最小資料模型，W6／W7 再實作正式 schema。欄位應重用既有角色、Stable ID、ownership 與 Run 授權資料，避免平行維護。
| 記錄 | 最少內容 |
|---|---|
| 驗收標準 | ticket、AC／BR、案例 ID、層級 be/fe/integration/manual、必要性、QA suite commit、介面版本、業務與技術核准引用 |
| 測試執行 | execution ID、受測角色／範圍、程式 commit、產物 digest、QA suite commit、必要清單版本、runner 原始結果、GitLab project／pipeline／job ID、原始 artifacts |
| 部署組合 | candidate ID、實際 BE／FE commit 與 digest、部署 ID、環境、設定／migration／fixture 版本、核對時間 |
| QA 確認 | ticket、candidate／證據版本、驗收範圍、accept／reject、具名 QA 身分、理由、時間、相關 Gap |
| 故障演練 | 觸發理由、基底／測試版本、指定故障與應失敗案例、三次結果、隔離及復原證據、QA／技術 reviewer 結論 |
QA repo pipeline 的 commit 是測試程式版本，不能拿它當 BE／FE 受測版本。 W6 必須分開驗證「執行腳本版本」及「實際部署產物」。
標準核准、CI 執行結果、QA 最終驗收是三種不同紀錄。不能以測試標準核准或一般 Agent Run accepted，直接代替 QA 對交付版本的接受。
狀態採獨立欄位：自動測試 not_run/running/passed/failed/error、QA pending/accepted/rejected/stale、Gap 的生命週期與 blocks、既有角色版本狀態。看板呈現原因，不把不同狀態混成單一「完成」。完整整合通過後才顯示待 QA 驗收；必要證據不足或環境錯誤不能成為 passed。
3.1 Agent 每次開工／續接要取得的工作包
擴充既有 dcx open <ticket> --role <role> --json 與 orchestrator-mvp/run-agent.py 的 work package。現有 --stage contract-draft/ready-for-build 是呼叫者要求的契約檢查階段，不能直接當作系統已確認的整體流程進度；新流程狀態必須由有效紀錄推導。
| 工作包需回答 | 內容 |
|---|---|
| 我在操作哪裡？ | product、ticket、contract root、產品 workspace／repo 對應、工具與政策版本；缺實作路徑就列待提供，不能猜 |
| 我是誰、負責什麼？ | 已驗證身分、角色、ownership、負責 AC、寫入範圍、reviewer／交接對象 |
| 目前進度？ | 規格／介面、QA 案例／腳本、各端 CI、適用演練、整合、QA 接受各節點的狀態與依據；含最後核對時間 |
| 現在可以做什麼？ | 依角色列可立即執行的下一步、仍在等待的項目、缺資料原因與誰提供；多端並行不壓成單一階段 |
| 要怎麼用工具？ | 真正可用的命令、參數、執行目錄、產品設定引用、前置條件、輸入與預期輸出、是否需人確認 |
| 什麼才算完成？ | 必要交付、測試／證據版本、成功條件、寫回位置及交給誰；不以執行 exit 0 或 Agent 自述代替審核 |
| 出問題怎麼處理？ | 可用的查詢／重試／Gap／轉派建議／修復提交方式；工具尚未接線時明列限制與 owner，不提供不存在的命令 |
狀態與下一步由同一品質評估核心供 CLI、Agent、看板使用，包含資料未知／過期／權限不足的原因。Agent 執行寫入、觸發 CI 或提出驗收前重新讀取狀態，操作入口核對版本及權限；不能依上一次聊天的舊結果放行。回寫與通知成功不取代測試及驗收紀錄。
| 角色／責任 | Agent 在適用階段收到的工作提示 |
|---|---|
| PM | 補需求與 AC、裁定歧義、確認範圍／版本；顯示等待 PM 的問題 |
| UI／設計（有此角色時） | 補畫面狀態與操作約定，交 FE／QA；無獨立 UI 時依 ownership 明定接手者 |
| BE | 補 API／啟動與資料介面、實作及自驗、跑 QA BE 驗收、提交修復；判錯端只能建議 QA 轉派 |
| FE | 補畫面可觀察行為／啟動介面、依契約 mock 開發及自驗、跑 QA FE 驗收、提交修復 |
| QA | 先設計案例，介面可用後腳本化；看結果、人工驗收、開／轉派 Gap、重驗並具名確認 |
| 技術 reviewer／整合 owner | 按實際身分映射取得測試審查、演練核對、固定部署與整合任務；責任本身不自動授權 |
人類的業務決定與核准仍明確交人處理。這個入口提供上下文與工具導航，無須引入自動召集所有 Agent 的工作流引擎。換一個 Agent 或重開對話，也應能重新取得同一組最新且有依據的下一步。
4. 各工作包的修改與驗收
W0 — 試點、輸入範本與資料模型
先在 framework 建立產品接線填寫表與 BE／FE 測試介面範本，再由試點產品填入真值。預定位置為新增 examples/quality-qa-repo/ 的說明／範本及上述資料模型；不假裝已有正式 QA project ID。
列出 contract／BE／FE／QA repo、固定 framework 版本、PM／QA／技術 reviewer／整合 owner／CI 維護者。
先定共用產品設定 schema、能力宣告、Agent 工作包輸出與命令描述介面；提供兩個不同產品設定範例，讓後續各包回填相同的狀態與下一步。缺必要設定的 doctor／開工提示要有具體原因及 owner。
區分單端 MR 必跑清單與部署後整合必跑清單；同一 AC 可對應不同責任，不機械複製三份案例。
BE Swagger 與 FE 狀態約定可以先確認，啟動命令隨實作補齊；mock 的欄位、狀態碼與業務語義引用同一契約。
定義人工項目與受測範圍；必要人工驗收在 QA 階段完成，不偽裝成 JUnit passed。
驗收：選定一張小 Slice，各角色知道要交什麼；未齊備資料有 owner，模型與範本經 QA／技術 reviewer 審查。
W1 — QA 獨立庫與可執行測試
先交付可複製的 QA 庫範本，再接到獨立 QA repo 或 contract repo 的 qa/。建議結構：cases/、tests/be/、tests/fe/、tests/integration/、fixtures/、adapters/、CI 設定及鎖檔；實際目錄可配合技術棧。
先延用產品熟悉的 BE 測試工具；FE 範例用 Playwright 操作真實頁面並攔截瀏覽器 API。工具不影響獨立性定義。
FE 測例包含正確請求的 method／path／資料、成功／失敗提示、處理中狀態與防重複操作；mock 回應不能成為測試唯一斷言。
page.route適用瀏覽器發出的請求；若 FE 有 SSR／BFF 的伺服器端 API 呼叫，另提供契約 mock 服務及依賴設定，不能宣稱瀏覽器攔截已覆蓋。BE 測例呼叫真實測試 API，檢查回應與必要資料副作用；測試資料須可重置，依產品採 DB 或約定的觀察 API。
保護 cases、mock／fixture、adapter、harness、鎖檔、CI 及必要清單。QA／產品人審業務標準，技術 reviewer 審測試程式；修改需重新核准。
QA suite pin 更新必須連到契約／案例影響及核准，不能由產品 MR 任選一個較寬鬆的舊版本。
驗收：測試能在指定 FE／BE 產物執行；刻意錯誤的請求／畫面／資料會失敗；沒有測試的必要案例不會被當成通過。
W2 — 在 MR CI 臨時啟動產品服務
修改真實 BE／FE repo 的 CI、測試啟動與資料腳本；framework 提供接線範本，保留 現有 checker。各 job 取得本次 MR 對應程式及固定 QA suite，記錄實際測試 commit；不連共用 dev 冒充本次 MR。
| FE job | BE job |
|---|---|
| 安裝／建置指定程式與瀏覽器依賴 | 安裝／建置指定程式與依賴 |
| 啟動 FE，等待 URL ready | 啟動隔離 DB／Redis 等必要服務，migration／seed，啟動 BE 並等待 ready |
| 跑自驗及 QA FE 腳本，API 依契約 mock | 跑自驗及 QA API 腳本，核對真實資料結果 |
| 保存 JUnit、trace／截圖與 server log | 保存 JUnit、API／service log、必要資料檢查結果 |
| 停止臨時服務、清理本 job 資料 | 停止臨時服務、清理本 job 資料 |
每 job 的名稱空間、port／network、DB 與資料隔離；容器服務用正確 hostname。取消、timeout、測試失敗仍保存可得結果並執行清理，不能因清理成功蓋過失敗。
單元測試與驗收 job 可分開，pipeline 必須包含全部必跑 job。零案例、skip、漏 job、缺報告、runner 非零都拒絕；必要清單不能從當次結果反向生成。
測試啟動由產品／CI 維護者實作；QA 測試只接收約定 URL／設定，設定不得混入正式資料或憑證。
MR 可提早開、Reviewer 可同步看；合併需 CI 成功、標準／程式審核完整及適用的故障演練已接受。FE 先合併時須維持既有功能相容或用關閉的 feature flag 隔離未完成路徑。
驗收：新 commit 會重新測；舊綠燈不可覆蓋新提交；一端未完成不妨礙另一端的單端測試；並行兩次 job 資料互不污染。查核站台保護設定，無法強制者明示為試行限制。
W3 — 在可跑通之後執行必要故障演練
依本地範例建立產品的演練操作說明，第一輪可由人指派隔離任務，不建自動風險決策系統。正常實作與核准測試能跑通後才進行，並於需要該演練的合併／交付關卡前完成。
QA Agent 提出這次是否需要演練、原因、錯誤與對應案例；QA＋技術 reviewer 確認範圍。
觸發：首次建立標準、重要測試／執行路徑變更、新增或改變高風險行為、漏驗缺陷。一般實作變更仍重跑正常測試，但不一律重做演練。
故障作者另接任務，指定隔離 worktree／checkout、資料與服務；只改受授權的產品實作，驗收測試唯讀。可由開發 Agent 另任此職，不能自行核准。
保存正常綠 → 指定業務斷言紅 → 復原綠。未啟動、編譯錯、環境失敗不能當抓到錯；需要修測試就回 W1 審新版本並重做。
驗收：一個真實漏驗故障被指定檢查抓住；Agent 不能自選免做；未隔離的共享資料不可被演練改動。
W4 — 固定部署組合，在 QA 庫跑真實 E2E
第一輪由 QA／整合 owner 在 GitLab 手動啟動 QA repo pipeline，輸入候選 ID／環境／範圍／核准 suite 版本。後續 QA Agent 代呼 API 仍使用同一入口，不另造一套結果規則。
合併後形成確切 BE／FE 產物；若未測 merged result，先重跑適用測試，再進交付。各端先合併不表示整個功能已可驗收。
整合 owner 部署固定組合，從可信部署紀錄及實際服務核對版本；僅填參數 SHA 不是已部署的證明。
測試前後核對版本；共享 dev 須有部署／測試協調鎖或隔離候選環境，否則偵測換版就作廢重跑。人工驗收期間仍須能識別換版。
E2E 連真正 BE／FE；BE／FE 邊界不可再 mock。必要外部第三方使用受控測試服務，報告明示範圍。
保存原始結果與同一受測產物 digest；交付 QA 的環境／產物與報告必須對得上。若搬到另一驗收環境，另核對設定並執行必要部署檢查。
驗收：BE／FE 單端綠但整合紅時無法進入待 QA；A 的報告不能交付 B；測途中換版會失效；只成功啟動 pipeline 不算測完。
W5 — Bug 沿用 Gap，維持原有 QA 權限
預計修改 dcx、tools/run_protocol.py、schemas/run-result.schema.json／reference、tools/board.py、dashboard 類型／顯示、Agent 指引及產生器。新類型建議名為 implementation_defect；非必要改善的類型建議 improvement。名稱需在本工作包固定，兩者都不自動升業務契約 revision。
Gap 記錄受影響 AC、重現步驟、預期／實際、受測 BE／FE／QA suite 版本、環境、證據。受阻角色為 QA；assign 是修復端，可先空白。
責任不明由整合 owner 協調；FE 認為應交 BE 時提出理由與證據，由具權限的 QA reassign 同一筆 Gap。保留
_gap_authorization的既有規則，不擴權給修復方。修復端
submit-fix提交修正與測試依據；仍待 QA 依新版本重驗，具權限者再resolve。解除一筆 Gap 不等於整體驗收接受。違反本次必要 AC／規則必須帶
blocks；未違反約定的改善可保持 open、blocks: []，不阻擋 QA Gate。不能把違反必要 AC 的 bug 直接改名改善來繞過。既有 Gap 原始內容受不可改寫限制；若需要事後調整阻擋性，新增可稽核的分類事件（名稱草案
reclassify），由原提出者／受阻角色授權人操作，附理由；涉及需求範圍須有 PM 決定及契約更新依據。不得直接覆寫 blocks，也不放寬 reassign／resolve 權限。關聯 AC 與
blocks要分開保存，非阻擋改善也能查到相關 AC。新欄位優先向後相容，舊紀錄仍可讀。驗收：QA 可開／轉派／確認；修復方越權被拒；待確認修復仍紅；合法 advisory 可與綠燈共存；偽造 actor、修改歷史或自行清空 blocks 均拒絕。
W6 — 可信 CI 結果回寫與通知
新增獨立的品質證據模組及 schema，建議 tools/quality_evidence.py；dcx 提供窄入口。JUnit 核對可重用必要案例檢查器；可信 CI 來源與部署核驗需另外實作。contract 中只存索引、狀態及必要摘要，完整報告保存於可保留的 artifact 儲存。
完成事件只作觸發提示；受控收集器向 allowlist 的 GitLab project／pipeline／job 取得實際狀態、commit 與 artifacts，核對 QA suite、必要清單、受測程式／產物、部署組合。不能只信任 Agent 自報 passed 或傳入網址。
產品 MR job 沒有 contract 寫入憑證。 受保護的收集器可寫的範圍僅限結果紀錄；不得改需求、驗收標準或替 QA 接受。
收集器在來源測試 pipeline 完成後執行；不在同一個尚未完成的 pipeline 中要求它已成功，避免相互等待。失敗結果也可回寫診斷，只有可信完整通過才成為放行證據。
以來源 project／pipeline／job＋candidate＋suite 版本去重；重送不重複通知，晚到的舊結果不可覆蓋新候選狀態。寫入失敗可重試，不產生假綠燈。
結果提交若產生新的 contract commit，不應因純證據／通知變更使測試自我失效；用真正影響行為的契約／介面／標準內容來綁定。
BE／FE 單端結果可回寫進度；只有固定組合整合與必要條件通過，才通知「待 QA 驗收」。通知最少含 ticket、候選版本摘要、範圍、結果／證據連結與 QA 下一步。
通知第一版走產品既有可達 QA 的入口（優先評估既有 Jira 同步能力），實際通道於 W0 指定；不假設 Agent 會自動接收推播。通知發送失敗不抹除測試結果，顯示失敗並可重試；QA 亦能主動查詢。
驗收：假 artifacts、錯 project／job／commit、過期報告、舊結果重播、無權限 API、版本不符均不能使 Gate 通過；重試不多寫一份驗收結論、不重複通知。
W7 — 全角色 Agent 工作入口、QA 確認與 Gate
先依第 3.1 節實作共用工作包，讓 PM／UI／BE／FE／QA 與具名 reviewer 都能取得適合自己的狀態、工具及下一步，再接 QA 最終確認。狀態評估、命令說明與生成指引必須同步，不能只在最後加一段 QA prompt。
預計修改 dcx 的 open／next actions／role 及生成器、orchestrator-mvp/run-agent.py 的工作包／續接與輸入重驗、agents/roles/{pm,ui,be,fe,qa}.md，並同步版本化 schema、AGENTS／CLAUDE 與 .agents／.claude 生成指引。W0 定介面後即隨 W1～W6 逐步串入，最終在 W7 驗收完整流程。
新增品質查詢／驗收 CLI，底層用同一套品質評估函式提供 dcx open／gate／board。命令名稱於實作時固定，文件示意不冒充現有功能。
QA 在 Agent 查本單受測組合、測試結果、人工項目及 Gap；明確表示「接受這次驗收」或「退回及原因」，Agent 記錄到 contract。必要對象資訊不完整時補問，不能把含糊的聊天「好」視為指定版本驗收。
Agent 是操作代理，確認人是具權限的 QA 自然人。正式寫入使用可驗證的登入／GitLab 操作者身分與 ownership 對應；不信任任意
--author字串。若寫入者是共用 bot，仍須保留並核驗原始人類授權，不能把 bot commit 當作人的同意。後台可由受控 branch／MR 或既有 bot 寫入流程驗權，但不要求 QA 手動找 MR；狀態只在正式寫入通過後生效。Agent 可呈現可追溯連結。
QA 接受綁定驗收範圍、候選、標準及證據；與目前候選不同或資料過期時拒絕接受。發現缺陷依 W5 開 Gap，QA 重驗後另記接受。
啟用品質政策的產品，總 Gate 同時要求：既有角色／版本條件、必要單端及整合測試、適用演練、必要人工項目與 QA 接受、證據版本有效、無 blocking Gap。
ready_for_qa與 QA accepted 分開。QA 完成後，程式、標準、測試執行路徑或必要環境設定有影響驗收的變更，轉
stale／待重驗。未知影響先待重驗，由 QA 決定範圍；部分沿用需明確保留依據，不能把舊報告套到新產物。第一版以候選／內容版本保守失效，證據、通知等非行為變更不自我失效。精細到檔案的自動免重驗延後，仍保留人工依影響選範圍。
採顯式 opt-in 與版本化設定。未啟用的產品維持現有 Gate；啟用卻缺資料／QA 未配置時拒絕，不默默退回舊綠燈。
驗收：CI 綠但 QA 未接受不能綠；舊接受遇換版失效；無權限／假身分接受被拒；advisory 不擋；CLI 與看板同結論；未啟用產品的既有行為保持相容。
W8 — 跨產品驗證、正式試行與導覽同步
先發布已驗證的 framework 版本並更新試點產品 pin／生成文件，再寫入新 Gap 類型或新驗收紀錄；舊工具不認得新類型時須明確拒絕，不能刪資料來相容。新政策顯式啟用，保留未啟用產品的既有行為。
在不含正式資料的產品測試環境跑一次完整流程：正常通過 → QA 發現 bug → Gap → 指派錯端交 QA 轉派 → 修復與重跑 → QA 解除並接受 → 更換受影響版本重新待驗；另保留一筆非阻擋改善，驗證它不造成紅燈。
另以兩個不同產品的設定／隔離 fixture 驗證相同框架：不同 ticket 前綴、repo、測試工具、環境與角色人員，不能串用另一產品的證據、Gap、通知或憑證。第一個產品完成真實 Slice 試行後，第二個產品依接入指引及配置接線，無須修改共用流程程式；不同技術棧只實作約定的 adapter。
同步 agents/roles/{pm,ui,be,fe,qa}.md 及生成器、docs/AGENT-WORKFLOW.md、流程 HTML 與範例。QA 庫分工、MR 臨時環境、整合 CI、回寫及 Gap 新類型都要說明；流程文件隨功能落地更新實作狀態。生成文件由產生器更新，不能只改產品輸出檔。
驗收：正常路徑及約定拒絕路徑有真實紀錄；人能從 contract 找回原始報告與版本；QA 不必手動搬報告／找 MR；產品 owner 確認實際權限及旁路限制後啟用。功能旗標與回復方案先備妥；停用必須具名記錄，不能因某張單紅燈而自動停用，且歷史證據保留。
5. 工程驗證清單
以下是開工後的必要測試範圍，不代表本次已執行。
| 工作包 | 必驗反例／既有測試落點 |
|---|---|
| W1／W2 | BE 未做完時 FE 單端可跑；錯請求不能被 mock 放過；臨時 DB 隔離；服務啟動失敗；MR 新提交；必要 job 消失／案例漏跑／skip／原 runner 非零。沿用 tests/test_required_cases.py，產品各自測 CI 行為 |
| W3 | 正常綠／指定斷言紅／復原綠；故障仍綠、編譯錯、資料串用均不接受 |
| W4 | 單端綠但跨端紅；部署產物不符；測中換版；QA suite commit 與產品 commit 不同仍可正確核驗 |
| W5 | tests/test_agent_workflow.py、test_ci_ownership.py、test_run_protocol.py、test_gap_basis.py、board／dashboard 測試；新增 kind 與 schema 一致，舊紀錄仍可讀 |
| W6 | 新證據核驗測試；偽造結果／舊候選重播／重複事件／回寫衝突／artifact 失效／通知失敗 |
| W7 | 新 Agent 僅依工作包即可定位產品／角色／待辦／工具；並行狀態、續接、換版、未接線命令與執行前重驗；test_agent_workflow.py／test_run_protocol.py。Gate 接受／拒絕／失效狀態與權限測試；QA inactive 與品質 opt-in 衝突；既有 test_roles_inactive.py、test_legacy_validation.py、test_r2_revalidation_feedback.py；看板同源判斷 |
| W8 | 雙產品資料／身分／通知隔離、相同政策一致、配置缺失、工具版本與生成文件同步、新對話角色接手；第二產品只靠配置與 adapter 接入。產品 GitLab 實際權限與完整交接驗證；tests/test_quality_docs.py、quality-workflow.test.mjs 及生成檔檢查 |
實作每一包先跑相關測試；改到共用 CLI／schema／授權後，再跑 repo 既有 CI 必要檢查。文案與計劃更新本身不新增鏡像測試。
6. 開始接真實產品前需補的資料
本節是完整品質政策的接線清單；逐步跟跑先依第 10 節及團隊教學，只補選定範圍實際需要的資訊。
2026-10-02 使用者決定：首個試點產品為 IM，採用下一張新工單。 工單建立後再確認 Slice 編號與範圍；不以既有 IM-1421 作為本次試點。 試行 QA 負責人由 Leo（@ptp_leo）暫代，負責確認驗收標準及對指定候選作最終接受／退回。 技術 reviewer 由 Dino（@ptp_dino，既有 GitLab ID 211）擔任，負責審查測試程式與故障演練。 QA Leo 的既有 GitLab ID 為 201；兩位身分對應已從 IM ownership 核對。 整合 owner 也由 Leo（@ptp_leo）暫代，負責協調 BE／FE 測試環境部署、核對固定候選版本並交付驗收。 小團隊試行採職責兼任，不要求每項職責由不同的人擔任，也不另設專職 CI 維護者、UI 或替補。 CI／Runner 接線由 Agent 協助實作與檢查，整合 owner 協調必要的帳號權限與部署資源； PM／BE／FE 沿用既有 ownership；IM-1421 本輪後台範例不需設計稿，由 FE 依 PM 規格補畫面行為。 替補依實際需要再補，不作本輪試行前置條件。 QA 與技術 reviewer 也可由同一人兼任，不限定 QA 組長或額外人力；業務與技術審查須以 review_role 分別留下紀錄。 同人兼任會明示於看板及查詢，不視為獨立第二人審查，也不代替 QA 最終接受。IM 仍沿用已選定的 Leo／Dino 分工，未自動改派。後續先查既有 repo／CI 設定，只向使用者詢問查不到的資訊或需人決定的事項。
2026-10-02 使用者確認：IM 測試放在 im-delivery-contracts/qa/，不另建 QA repo。QA 與 contract 使用同一 project ID／URL，suite_path=qa；先完成 framework 支援，正式接線仍待新工單、Runner 與部署資料。
2026-10-05 補充：設計稿由 PM 逐張 Jira 判斷是否需要；前台 App 也非每單必備。 UI 維持手動畫 Figma，PM 暫代固定版本與畫面的交接窗口；無稿的單由 FE 依 AC 與既有畫面規則實作。 IM 釘選 v0.6.17 的 roles_inactive.ui 是產品級停用，尚無逐單設計稿適用設定。 待補能力是逐單判斷與對應檢查，以及 PM 兼任交接時所需的角色權限；不能直接全面啟用 UI 代替。 跟跑先在原 Jira 記錄判定與設計連結，這次只調整文件，未修改 IM 的契約、ownership 或 CI。
以下是其餘接線輸入，不妨礙 framework／範本工作先開工；未提供時不能聲稱產品試行完成。
| 待填 | 負責人 | 最晚使用點 |
|---|---|---|
| 新工單的 Slice、contract／BE／FE／QA repo 與 GitLab project ID | 產品 owner／PM | W0；W1 建真實庫前 |
| BE 技術棧、FE 是否含 SSR、測試／啟動命令、DB／依賴及 mock 邊界 | BE／FE | W1／W2 接線前 |
| Runner executor、可用映像、跨 repo 讀權限、GitLab 版本／保護能力 | Agent 查核；整合 owner 協調權限 | W2 接線前 |
| dev 部署入口、可核對的產物識別、測試資料與環境鎖 | 整合 owner | W4 前 |
| contract 受控寫入身分、QA 具名操作身分與 ownership 對應 | framework／產品維護者 | W6／W7 正式寫入前 |
| 通知目的地與接收人、artifact 保存期 | QA／產品 owner | W6 試行前 |
共用框架須支援所有採用 contract 的產品，透過產品設定與 adapter 導入。暫不做：自動判定免演練／免驗收、每張 MR 部署完整跨端預覽站、Jira 唯一入口改造、全產品同時強制遷移。QA Agent 自動觸發 pipeline 是手動入口穩定後的薄層擴充；本期必須完成的是結果自動回寫與 QA 具名確認。
7. 技術依據
官方文件核對日期：2026-10-01。公司 GitLab 版本、授權與實際 Runner 能力仍須依第 6 節查核。
GitLab MR pipelines：設定 MR 觸發及測試對象。
GitLab services：job 內的依賴容器與生命週期；Shell Runner 另行設計服務管理。
Playwright webServer 與 Mock APIs：啟動前端、等待可用及瀏覽器 API 攔截。
GitLab Jobs API 與 Job Artifacts API：依確切來源核對狀態與取得報告。
Downstream pipelines：若採跨 pipeline 執行，須處理狀態傳遞；不把觸發成功當測試成功。
8. 本地實作交付紀錄
| 工作包 | 本地交付 | 正式產品尚待 |
|---|---|---|
| W0 | version 1配置/schema/doctor、實際命令與工作包、兩產品範例 | owner／Slice／repo與身分定案 |
| W1 | QA測試區骨架、固定suite與受審標準、真browser/HTTP fixture | 產品QA測試區／測試腳本及兩項審查核准 |
| W2 | 臨時服務/資料隔離harness、timeout/cancel清理、原始runner/JUnit、單端Gate | BE/FE CI接線、Runner及必要job保護 |
| W3 | 適用性兩項審查確認、下載核對三段原始CI/JUnit、指定業務斷言/復原 | 正式隔離演練與具名核准 |
| W4 | 固定部署model、QA手動pipeline範本、GitLab部署與live probe前後核對 | dev部署／鎖／digest與實際E2E |
| W5 | implementation_defect/improvement、完整重現、reclassify稽核、原權限保留 | 產品Gap試行 |
| W6 | allowlist完成pipeline/必要job/原始artifact收集、去重、錯誤診斷、只追加結果的MRpublisher、通知重試 | 寫入身分／保護設定／通知adapter及目的地 |
| W7 | CLI/Runner/看板同源、五角色／生成器、具名QA、scope/manual/失效與總Gate | QA登入／正式MR授權與團隊接手 |
| W8 | 雙產品不同ID/票號/人員/工具的隔離全流程、換Agent續接 | 發布framework pin、正式產品完整試行、owner確認旁路 |
試點產品已選 IM，將以下一張新工單試行；Slice 與其餘接線資料待定。 本地 transport 與 fixture 沒有當作正式驗收， IM保持未啟用；沒有推送、合併、正式部署或對外通知。備份分支保留。 本次實測如下；原工程驗收要求仍是正式產品試行依據。
2026-10-02 本地驗證
共用實作提交：
ed281a4（可信證據、具名 QA、Gap 邊界、CLI／Runner／看板與生成指引）。python3 -S -m unittest discover -s tests -p 'test_*.py' -v：298 項，296 通過、2 跳過。新增品質流程 43 項涵蓋雙產品、原始 CI／JUnit 核驗、實際執行時效、候選／契約失效、具名授權、MR 手編反例、通知重試與 publisher 邊界。跳過原因：可選 PyYAML 未安裝，以及 worktree 相對路徑找不到相鄰 IM repo。後者已指定真實 IM 路徑，唯讀
git archive到臨時目錄補驗通過；沒有修改 IM 或切換服務。dashboard：30 項 Vitest、TypeScript、正式與離線建置通過；離線 HTML 已重新產生。導覽 Node 測試 4 項通過。
Go：
go test ./...與CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build通過。生成器：15 份輸出一致，demo contract check 通過；
git diff --check通過。真瀏覽器 fixture：FE 契約 mock 正常綠、刻意錯請求紅、真實 FE→BE→SQLite 整合綠且付款副作用只有一次。BE 既有示範的正常／兩種業務故障／復原均符合預期。
文件可讀匯出：19 頁，沒有缺失參照。這些 fixture 與模擬 API 結果只驗 framework 行為，尚非正式 GitLab、部署或人工驗收證據。
正式接線仍待第 6 節產品／人員／Runner／部署與通知輸入；未發布 framework pin、 未推送或合併本分支、未啟用正式產品、未部署或發送外部通知。主 checkout、IM repo 與既有備份分支保持原狀，後續從本分支及 操作指引 接續。
2026-10-02 小團隊兼任調整驗證
QA 與技術 reviewer 可同人兼任；標準、演練適用性及演練證據按 review_role 分別核准，不能用一筆審查完成兩項職責。既有分人紀錄可相容讀取，最終 QA 接受仍獨立確認。
新增 5 項 Python 行為測試，涵蓋同人完整流程、演練雙職責、越權職責、手編省略職責及既有紀錄相容。品質測試共 48 項通過；完整 Python 303 項，301 通過、2 項沿用前述環境原因跳過。
看板明示同人兼任／分人審查：31 項 Vitest、TypeScript、正式及離線建置通過，離線 HTML 已更新。15 份生成文件一致、demo contract check 與 diff whitespace 檢查通過。
IM 既定 Leo／Dino 人員配置及正式產品啟用狀態未改動；本次只完成 framework 本地調整。
2026-10-02 Contract／QA 共用 repo 驗證
IM 採 im-delivery-contracts/qa/；框架允許 contract／QA 共用 project ID 與 URL，明列 suite_path=qa，保留獨立 QA repo 相容性。
固定乾淨 suite commit、子目錄執行與報告路徑核對；測試及收集使用不同 pipeline，明確區分 integration／collect／notify action。
qa/ 單獨變更也核驗 MR 作者；collector publisher 拒絕夾帶測試或標準修改。CI 憑證環境隔離仍須正式站台接線實測。
新增 6 項行為測試；品質測試 54 項通過。完整 Python 309 項，307 通過、2 項沿用前述環境原因跳過。
15 份生成文件及 demo check、4 項導覽 Node 測試、兩種配置 schema、CI YAML 語法與 diff whitespace 檢查通過。未執行正式 GitLab CI lint 或 Runner。
本次僅完成 framework／範本本地交付；IM pin 與正式品質政策尚未更新。
2026-10-02 IM Runner／CI 本機盤點
使用者選擇本輪先整理本機結果，GitLab 即時設定查核延後。未啟動 pipeline、變更遠端設定或部署服務。
| 項目 | 已核對的本機證據 | 沿用判斷與待查 |
|---|---|---|
| Contract／QA repo | im/im-delivery-contracts，本機 f5dffa8，framework pin v0.6.17；CI tag=im-runner，註解記載 Shell executor | 優先評估既有 Runner；線上 Runner ID、executor、狀態、保護及容量尚未查證 |
| 後台 FE | im/frontend/adminim_6t，本機 ee58052；已配置 origin，既有 SSH 唯讀 ls-remote 成功且遠端 main HEAD 一致 | deployment.md 的「尚無 remote」已過時；不能據此判定尚未建遠端專案。Runner／部署狀態仍未知 |
| FE 現有檢查 | GitLab verify job：api:generate、generated drift、pnpm verify；Node 24.18.0、pnpm 11.13.1；dist 保存 7 日，未定義發布 job | 可沿用自驗命令；尚無獨立 QA 驗收 job。CI 未指定 runner tag；若接目前 im-runner，需確認 tag／untagged 規則與 Shell 主機工具版本，image 不提供 Shell 隔離 |
| BE | 既有 IM-1421 manifest 的介面來源為 backend/6t-im；本機 IM 下只有 frontend 與 contracts | 可作後端定位線索，尚未查證正式 URL、project ID、CI、啟動／測試／DB 命令；不將 IM-1421 改作試行工單 |
| 產品 dev | FE sources.md 列出 6t-im-api.ljbdev.site 的 API 文件入口；部署文件無已驗證的 FE dev 域名 | API 文件入口不等於可驗收的固定部署。contract CI 裡的 dashboard-deploy 是交付看板，不是 IM 產品 FE／BE 環境 |
接線前可由 Agent 處理的具體差異：
Contract 目前 stages 為 validate/generated/impact/baseline/build/deploy，沒有範本的 test stage；接入時須明確增加或對應 stage，合併既有 workflow，不直接覆蓋。
Contract default.before_script 會建立 .ci-venv／.ci-cache。整合 job 不能直接把這份工作樹當乾淨 suite checkout；需另外取固定 commit 的乾淨 checkout，binding／profile 暫存放外面。
保留既有 contract／FE 自驗，新增明確 integration／collect／notify 路徑；回寫結果與 push 不自動觸發整合。
接 QA 前須核對既有 DELIVERY_BOT_TOKEN、Jira、SSH 部署憑證及新增 collector 憑證的作用範圍。檔案只看得到引用，不能宣稱已完成隔離；測試 job 不得繼承寫入或部署憑證。
仍需 GitLab／Runner 實況才能確認：project／runner ID、近期成功 jobs、保護與變數 scope、跨 repo 讀取權限、瀏覽器與 DB 隔離能力。新工單出來後再確定採用哪個 FE／BE 與候選部署；本次後台 FE 盤點不代表新工單範圍已定案。
9. 歷史換機交接（2026-10-02）
本節保留當時的查核與指令；smoke 待辦已由後續工程試行完成，接手請改看第 10 節。
使用者要求將目前進度提交並推送遠端，這次不執行 CI，之後改在另一台電腦接續 Codex。以下取代前述歷史紀錄中「尚未推送」的當前狀態；舊段落保留作為當時的查核紀錄。這次只保存進度，不觸發試行、不合併、不發布版本或啟用產品。
分支與接手入口
| Repo | 接續分支 | 本次交接前的程式基準 | 先讀 |
|---|---|---|---|
| ai-tool/delivery-framework | codex/quality-workflow-plan | 9b6ec0b | 本節、QUALITY-WORKFLOW-USAGE.md、QUALITY-WORKFLOW-PLAN.md |
| im/im-delivery-contracts | codex/im-qa-pilot | d9c725a | qa/runner-smoke/README.md、.gitlab-ci.yml |
兩個 repo 都使用既有 GitLab：gitlab-aha.okkia.site，SSH port 8022。新電腦可在選定的父目錄取得兩個分支：
git clone --branch codex/quality-workflow-plan ssh://git@gitlab-aha.okkia.site:8022/ai-tool/delivery-framework.git
git clone --branch codex/im-qa-pilot ssh://git@gitlab-aha.okkia.site:8022/im/im-delivery-contracts.git若已有 clone，先檢查 git status，保存自己的修改，再 fetch origin 並切換上述分支、以 fast-forward 更新；不要覆蓋另一台已有工作。把兩個 repo 加入 Codex 工作區，先讀交接文件及適用的 AGENTS.md。原電腦 worktree 路徑不是接手前置條件。
已完成與既定決策
framework 已實作 W0～W7 的共用流程、CLI／schemas／範本、固定 suite 與隔離 runner、可信 CI 證據收集、受控結果發布／通知、Gap 與具名 QA 接受、同源 Gate／工作包／看板；W8 有雙產品隔離 fixture，正式產品全流程仍待驗。
支援 QA 獨立 repo 或 contract 共用 repo；IM 已選 im-delivery-contracts/qa/，suite_path=qa。
首次正式試行等 IM 下一張新工單，不能改用既有 IM-1421。Leo（@ptp_leo，201）暫代 QA 與整合 owner；Dino（@ptp_dino，211）技術 reviewer。小團隊允許職責兼任，QA／技術審查以 review_role 分開紀錄，最終 QA 接受另行確認。
framework 最新完整 Python 驗證 309 項：307 通過、2 跳過，原因及補驗見第 8 節；品質測試 54 項、生成文件 15 份、Node 導覽 4 項通過。Dashboard 31 項、TypeScript 與兩種建置通過；先前 Go 測試與 Linux build 亦通過。換機保存只改文件，未重跑整套測試。
IM 正式 pin 仍 v0.6.17，QA 仍未啟用；未改 ownership、正式契約或產品部署。
Runner 最新證據與 IM 分支
使用者提供的 GitLab 截圖（僅證明截圖當時）：
| Runner | tag | executor | version | 當時狀態 |
|---|---|---|---|---|
| #10 | im-runner | shell | 18.6.0 | Online / Idle |
| #13 | 6t-im-dev-k8s-runner | kubernetes | 16.10.0 | Online / Idle |
IM 的 d9c725a 已在前一輪推送遠端，新增 qa-runner-smoke 手動 job，指定 #13，只在 codex/im-qa-pilot 未保護分支／其 MR 出現。沿用 validate stage，覆寫 default 繼承，固定 Playwright 1.63.0 與映像 digest，先預檢再 npm ci，產生 summary.json／JUnit／截圖，artifacts 保存 7 日。既有 #10 jobs 保留。
同映像 linux/amd64 本機容器已驗：正常瀏覽器操作成功；錯斷言非零退出且 JUnit 失敗；模擬寫入 token 被拒且無值洩漏；錯 Runner 被拒；模擬正確 CI 環境成功。契約草稿與 15 份生成文件檢查通過。模擬 CI 不等於真實 Runner 證據。
尚未取得 GitLab job 結果、實際 Pod 資源或 artifacts 上傳證據；使用者尚未回報按 Play 的結果。前一輪推送可能已建立 pipeline，狀態未知。本次保存用 commit 的 [skip ci] 及 git push -o ci.skip，沒有手動啟動或取消舊 pipeline。GitLab UI/API 未登入；SSH git 存取已可用。不要把 SSH 推送成功當作 CI 成功。
未完成事項與接手順序
下一步只核對 Runner smoke。 使用者先前偏好一件一件來。接手時先詢問／查看 d9c725a 的既有 pipeline 是否已跑 qa-runner-smoke，確認 Runner #13、job 結果、Tests 與可下載 artifacts。pipeline 入口：https://gitlab-aha.okkia.site/im/im-delivery-contracts/-/pipelines?ref=codex%2Fim-qa-pilot 。這次使用者要求不觸發 CI，接手後也先查狀態，待使用者要恢復試跑時再執行。
如果需重新試跑，使用既有 d9c725a pipeline 的手動 job；若不存在，恢復試跑時再手動建立分支 pipeline。最新交接 commit 有 [skip ci]，不要將 Skipped 當測試通過。未有登入時由 Leo 在自己的 GitLab 按 Play 並提供結果，不索取密碼／token。
失敗依 log 判斷：pending 查 project／tag／未保護分支可用性；pull 查 MCR；npm 查 registry 網路；Chromium 查 Pod 資源；預檢查 project/group 憑證 scope。不要為通過而放寬寫入憑證檢查或更換所有既有 job。
Runner 通過後，正式接線仍待下一張新工單的 Slice／範圍、實際 BE／FE repo 與 project ID、啟動／ready／reset／DB／mock 約定、dev 部署與不可變產物核對、環境鎖、具名身分／collector 權限及通知目的地。可先查可讀設定，只向 Leo 問查不到或必須決策的事項。
framework 尚待正常 MR／CI 審查、發布版本，之後才能更新 IM pin／生成文件並顯式 opt-in。不得因試行 smoke 綠燈就合併、部署或宣告 QA 接受。受保護主分支與 MR 合併由人依 repo 規則處理。
正式試行需跑正常→缺陷 Gap→轉派→修復重驗→QA 解除與具名接受→候選換版失效，並驗非阻擋改善；還要驗真實 collector／publisher／通知和跨 repo 權限。既有 fixture 不能替代這些證據。
原電腦 /tmp 的原始本機報告、瀏覽器截圖、node_modules 及登入／SSH 設定不隨 Git 搬移；可重跑腳本與驗證摘要已保存。新機須自行具備公司 GitLab 存取；沒有將任何憑證存進 repo。
當時的接續指令（已由第 10 節取代，不再依此重跑舊 smoke）：
先讀 delivery-framework 的 docs/QUALITY-WORKFLOW-IMPLEMENTATION.md 第 9 節，以及 im-delivery-contracts 的 qa/runner-smoke/README.md。沿用 codex/quality-workflow-plan 與 codex/im-qa-pilot，核對遠端與本機狀態。先接續 IM Runner #13 smoke 的結果查核，一件一件來；尚未授權恢復 CI 時不要觸發。正式試行等下一張 IM 新工單，保留 Leo／Dino 分工，勿把本機模擬當正式 QA 驗收。
CI skip 依據：GitLab pipeline skip。Skipped 空紀錄可能仍出現在 GitLab，沒有 jobs 執行；本地 git 能驗證遠端 commit，實際 UI 狀態仍待登入查核。
10. 目前導入與接手狀態（2026-10-04）
使用者決定先讓 1～2 張小單沿既有流程跟跑，避免時程與學習成本影響交付。 先看 HTML 教學的逐步導入段落； Pipeline／Job 對照 保存工程示範的版本、位置、用途與限制。
已完成的工程示範
IM-1421 已跑 FE CI 30267（86 案）、BE CI 30264（313 案）、QA 真 FE＋mock browser CI 30260（8 案），並完成各端 Draft MR、審查、修正與重驗。
contracts 最終文件版本
719d720daaa486618a0a5c26c03da6abcd09e099的 Pipeline 30306 已通過；smoke Job 129015 為 7 案、零失敗／錯誤／跳過，summary 與 JUnit 已核對。該 pipeline 的 optional browser Job 未重跑，browser 證據仍綁定 30260。FE／BE／QA 三張 MR 保持 Draft；未合併
dev／main、未部署，45 TC／18 AC 的完整產品驗收未完成。不同套件總數不相加當作 AC 覆蓋率。IM pin 仍為
v0.6.17，未啟用完整品質政策或正式 QA 角色。工程示範通過不代表 collector、自動通知或正式驗收權限已接線。
下一張小單如何開始
團隊依排程選一張非緊急、AC 清楚且範圍小的單，約定試哪些操作、測試層級、協助窗口與額外時間上限。沿用原需求、MR、QA 與發布規則。
Agent 先核對所選 repo／分支與既有 CI；新增試行 Job 限定範圍、手動、非阻斷，保留原必要檢查。限制執行時間與並行資源，明確列出取消方式；測真 FE＋BE 時核對部署版本，涉及寫入再確認隔離資料／清理約定。
先補案例、各端單元／元件及所選 QA 測試，保存 AC → case → 固定版本 → CI／原始報告連結，標出未執行範圍。現有試行 artifacts 為 7 日，試用前確認能保留到審查與回顧；過期不能當成仍可核查的證據。
工具／權限／環境卡住超出約定時間就記錄並退回原流程；產品 bug 依既有缺陷與發布規則處理。記錄額外耗時、求助、誤報及找到的缺陷，再決定第二張是否繼續。
接手不要重做： 不因第 9 節的舊待辦重跑 smoke，不先改 framework pin／quality.enabled／ownership，也不把整套 W0～W8 視為第一張單的開工門檻。若所選範圍確實需要新能力，再另開具體改動與驗證。 IM-1421 的 qa-runner-smoke 是限該試行分支的 required manual Job；保留這份歷史設定，不能直接當成未來非阻斷跟跑的範本。 未來正常開發單依原授權交付；本次 Agent 仍不代合併、部署或修改共用分支。
11. 共用待辦與唯讀 MCP：收尾與接手（2026-10-04）
使用者已決定先實作共用待辦與唯讀 MCP，設計須可擴充多產品。 StreamX 僅是未來情境；本次沒有建立它的 repo、帳號、部署或產品設定。
已完成並可審查
dcx todo --json、Dashboard 與 MCP 共用相同待辦索引。分清個人指派、角色共用／待認領與團隊未指派，包含 Gap 補齊／確認、重驗及 Run 審核；非阻擋 Gap 只列提醒。dcx inbox保留角色重驗用途。Dashboard 的「我的待辦」改由已登入帳號的產品身分查詢；前端不自行把整個角色的工作當成個人指派。資料不完整或版本不一致時明確提示。
可選
/mcp提供四個唯讀工具：可見產品、本人待辦、單張狀態、來源版本。沿用 Google 身分與逐產品權限，另有明確產品同意、PKCE、15 分鐘 token 及撤銷功能。預設關閉，尚未配置真實 MCP client。每次查詢帶來源 commit、工具版本、快照時間及來源核對結果。可選的觀察器只查固定遠端 branch，檢查過期／失敗或與快照不一致時不宣稱最新；更新快照仍由契約 CI 建置部署。
HTML 教學恢復流程圖優先，點節點可看負責角色、Agent／MR CI 工作與下一棒；長篇參考說明折疊保留。
本機驗證紀錄：Python 回歸共 332 項（331 通過、1 項選配 PyYAML 測試略過）， 前端 56 項、Go 全部測試與 race 檢查、Linux amd64 編譯、15 份生成檔同步檢查均通過。 跨 Python／Go／前端以合成多產品 fixture 核對相同結果；沒有把本機測試當成正式產品驗收。
接手只需完成的接線
先依 framework 的正常 MR／CI／發布流程審查本分支，發布新的不可變版本；不覆蓋既有 tag。產品要使用新能力時，再單獨更新 IM 的
dcx_ref與生成文件，並由該版本建置新快照。依 Dashboard 部署與來源更新說明 更新 IM 試行服務，保留 identity／session 設定與可回復的舊版；來源檢查器採專用唯讀 Git 身分。
依 唯讀 MCP 設定 選定實際 AI 客戶端、註冊精確 callback URI，再啟用 MCP。現階段是單程序、短期授權，重啟或 token 到期後需重新授權。
用真實 Google 帳號與所選 MCP 客戶端核對：登入／同意、IM 本人待辦與 Dashboard 一致、來源更新／逾期顯示，以及撤銷後確實拒絕。這段端到端驗證尚未執行。
上述接線不等於啟用完整品質 Gate；quality.enabled、QA 正式角色與各端部署仍依第 10 節的逐步導入決定。 本次收尾不合併受保護分支、不部署主機、不修改 IM pin／ownership，也不新增其他產品。