團隊討論文件 · INITIAL HANDOFF READINESS
DSA-15030｜接單資訊充分性評估
工單大致能說明「要支援什麼」，但未充分說清楚「支援到什麼範圍、交付什麼、如何驗收」。共用文件可補足平台背景與部分技術方向；DSAF2 的參考較具體，Lift OS template 的交付邊界較模糊，FIPS 則需先確認需求可行性。
討論目標：不是要求工單寫好每行程式，而是確認接單者能否從工單與指定文件判斷工作範圍、前置條件及完成標準，不依賴未記錄的口頭背景。
5 張平台與測試框架適配
3 張Secure Boot 模組回歸
3 張FIPS 平台／回歸／每日排程
來源 Epic：DSA-15030。分類數量不是完成率，也不是投入工時。
1. 分析邊界：排除接單後補寫的個人材料
| 資料 | 本次處理 |
|---|---|
| 工單標題、描述、Action Items、Acceptance Criteria | 作為「假設剛接單」的基本資訊。 |
| Epic、工單原有共用文件與文件內的參考 | 檢查這些文件能補足哪些資訊。 |
| Criz 後補的 Requirements／Design、Development Brief | 排除，不拿個人補寫的文件證明原始工單足夠。 |
| 後補驗證、調查、PR、Jenkins run、其他後續留言 | 排除最初接單資訊分析。 |
| Done／Rejected 等結案資訊 | 不作為最初接單資訊；本文件不報告個人成果。 |
| 兩份自動維護的 Barbarians 彙整頁 | 排除，不拿事後彙整反推原始資訊充分。 |
| 共用文件中的後續修正 | 可說明「現在是否能釐清」，不能回推最初就已清楚。 |
歷史版本限制：本次以現行工單描述模擬接單，未還原首次指派當下的工單與文件版本。這是現有接單材料的充分性評估，不是對當時文件原貌的認定。
Jira／Confluence 查閱全程唯讀；「拿掉個人文件」僅指排除分析，沒有刪除任何資料。此 HTML 僅為本機新增文件。
2. 假設剛接單：有哪些工作、資訊及未解問題？
11 張單都有 Purpose、Action Items、Acceptance Criteria，但具體程度不同。以下「清晰度」是本次分析判斷，不是 Jira 狀態。
文件可釐清主要方向部分清楚，範圍／驗收待補需先確認需求與前置條件
A. 平台與測試框架適配：5 張
| 工單 | 單內直接提供 | 共用文件可補足 | 判斷與待釐清事項 |
|---|---|---|---|
| DSA-15160Lift Preview | 建立 Ubuntu 26.04 OS template；Lift 入口、ISO repository；能觸發 DSA／DSR 安裝升級、New Platform、AC／IM／LI／AM／Sensor 測試。 | Kickoff 可補平台版本、x86_64 架構、Beta／GA 時間與支援背景。 | 部分清楚 OS template 是映像、snapshot、平台設定，或全部？支援哪些 Lift 環境？Preview 用哪個固定映像／版本？此次實跑哪些驗收？ |
| DSA-15161VMPD pipeline | 指定 lift-pipelines、platform.vmpd.properties；若改 Ansible／Groovy 要聯絡 VMPD owner；驗收是 pipeline 可成功觸發。 | Kickoff 可補 porting 流程位置與平台／套件背景。 | 方向較清楚，驗收待補 沒有指定 pipeline job、測試輸入、owner 聯絡入口。「成功觸發」只指排程成功，還是執行完成並產生有效結果？ |
| DSA-15188DSAF2 framework | 指定 dsaf2、dsaf2-hc-server、dsaf2-hc-client；連到 DSAF wiki；要求辨識平台並執行 feature tests。 | Wiki 說明平台辨識、DSM／C1WS 顯示資訊對應、基本命令；提供 MIRACLE_LINUX 三個 PR 範例。 | 主要技術方向可釐清 仍缺 Ubuntu 26.04 的預期辨識結果、代表性驗收案例。工單稱 wiki 記錄待改檔案，實際頁面是目的與 PR 範例，未直接列 Ubuntu 26.04 待改檔案。 |
| DSA-15191Lift GA | 建立 GA OS template；Lift 入口；驗收項目與 Preview 類似。 | Kickoff 可補 GA 時間、架構、Agent branch／package naming。 | 部分清楚 與 Preview 的差異是替換映像、增加平台或重新驗證？GA 映像／kernel 基準、支援環境與驗收組合未明確。 |
| DSA-15194Lift Secure Boot | 建立 Secure Boot enabled OS template；Lift 入口；可觸發 Secure Boot agent testing。 | Kickoff 可確認 Secure Boot 是要求支援的功能。 | 部分清楚 未指定適用環境、啟用方法、狀態確認方式，以及驗收到 OS 開機、agent 安裝或 driver／模組運作哪一層。 |
核心問題：「建立 OS template」是工作方向，不一定是清楚的交付物定義。接單者可以研究實作方式，但不應靠猜測決定支援環境與完成邊界。
B. Secure Boot 模組回歸：3 張
| 工單 | 單內直接提供 | 共用文件可補足 | 判斷與待釐清事項 |
|---|---|---|---|
| DSA-15209AM regression | Ubuntu 26.04＋Secure Boot＋AM；VMware／AWS TestCase_Robust 入口；所有案例通過或失敗已驗證。 | 平台背景與整體 regression 階段；已讀文件未指定 AM 案例清單。 | 測試方向清楚，契約待補 哪些 suite／case、build、環境？AM 測試模式是否有指定？ |
| DSA-15210AC regression | Ubuntu 26.04＋Secure Boot＋AC；同樣的兩個 job 入口與驗收文字。 | 已讀文件未補出 AC 的具體矩陣與案例。 | 部分清楚 缺指定 suite／case、build、環境組合與失敗處理標準。 |
| DSA-15211IM regression | Ubuntu 26.04＋Secure Boot＋IM；同樣的兩個 job 入口與驗收文字。 | 已讀文件未補出 IM 的具體矩陣與案例。 | 部分清楚 缺指定 suite／case、build、環境組合與失敗處理標準。 |
- 兩個 job 都要跑，還是可選入口？列出 VMware／AWS，沒有明說覆蓋要求。
- 「failed tests are verified」怎樣才算完成？確認既有問題、開 bug、取得 owner 接受，或仍須重測通過，是不同結案條件。
- 要留下什麼驗收證據？Run、測試報告、失敗分類、Secure Boot 狀態等未被指定。
例：提供 TestCase_Robust 首頁能找到工具，但不等於已指定「用哪個 build、跑哪些案例、哪些失敗可接受」。
C. FIPS：3 張
| 工單 | 單內直接提供 | 現有共用文件可釐清 | 判斷與待釐清事項 |
|---|---|---|---|
| DSA-15737Lift FIPS 平台 | 建立 Ubuntu 26.04 FIPS-enabled OS template；Lift 入口；可觸發 FIPS agent testing。 | 現行 Ubuntu Kickoff 已刪除 FIPS 支援要求，記錄當時無法啟用 FIPS updates。 | 需先確認需求與可行性 初始材料未明確提供 OS 支援確認、映像／entitlement 條件；FIPS 指 runtime mode 還是正式認證？ |
| DSA-15743FIPS regression | AWS 回歸入口；FIPS 安裝、升級、AC／IM／LI／AM 回歸；通過或失敗已驗證。 | 現行 Kickoff 說明當時 Ubuntu 26.04 FIPS 測試前提不成立。 | 先有可用環境，再定義測試 缺前置環境達標方式、build／case／失敗處理規則。 |
| DSA-15745FIPS daily regression | 每日 FIPS 安裝／升級回歸；Azure dashboard／Dashboard Index；結果顯示於 mothra。 | 現行 Kickoff 可釐清 FIPS 支援前提；dashboard 提供結果查閱入口。 | 前提與實作入口待補 改哪個排程／設定？每日組合與結果識別方式？Dashboard 首頁不是新增 daily job 的操作指南。 |
現在是否能判斷該不該做？現行 Kickoff 可說明當時排除 FIPS 的決定。
能否證明最初資訊足夠？不能。後續修正不能當作最初已有資訊；原始描述預設 FIPS-enabled 環境可建立，已讀材料未提供這項前提的驗證依據。這也不是對最新 Ubuntu FIPS 可用性的重新查核。
3. 現有共用文件補了什麼？
| 文件與來源 | 實際能補足 | 不能據此認定 |
|---|---|---|
| DSAF test framework update | 平台辨識、console 資訊對應、OS 命令支援；其他平台三個 repo 的 PR 範例。 | 不是 Ubuntu 26.04 逐檔修改清單；未指定此次驗收案例。 |
| Ubuntu 26.04 x86_64 Kickoff | 架構、Beta／GA、Agent branch 20.0.3、package／artifact 命名、功能範圍、porting 分工與時程；現行 FIPS 排除說明。 | 不是 Lift 設定指南、測試矩陣或逐單驗收規格。 |
| 2026 Q3 Kickoff | 平台清單、release／rollout 規劃、平台專屬 Kickoff 入口。 | 主要是計畫索引，不是執行指南。 |
| Release Schedule Board | RC、soaking、release、rollout 時程與 release 文件入口。 | 時程不能取代這單的交付物定義。 |
| New Platform Support Involving Scope | 新 distribution／architecture 涉及的產品服務與整合範圍。 | 未補足這 11 單的 Lift／framework／regression 操作細節。 |
| New Platform Support Process — LINUX | 確認頁面主要為 Gliffy 流程圖。 | 本次未讀到圖內內容：文字版沒有內容，圖片讀取需登入；不能斷言圖中沒有相關指引。 |
DSAF 文件提供的既有範例
文件引用 MIRACLE_LINUX 的三個 PR，可作為改動方向參考，並非 Ubuntu 26.04 的現成規格。本次未讀取 PR diff。
工單本身提供的操作／查閱入口
| 對應工單 | 既有入口 | 用途界線 |
|---|---|---|
| 15160、15191、15194、15737 | Lift Jenkins | 平台／pipeline 入口，不等於環境規格或完整操作說明。 |
| 15160 | ISO repository | 映像來源入口，未指定本單應使用的固定版本。 |
| 15209、15210、15211 | VMware TestCase_Robust · AWS TestCase_Robust | 測試入口；沒有明說兩個環境都必須跑。 |
| 15743 | AWS TestCase_Robust | FIPS regression 入口；前置環境與案例仍待確認。 |
| 15745 | Azure Data Explorer dashboards · Dashboard Index | 結果查閱入口，不等於 daily regression 新增方式。 |
這些操作入口僅整理自工單，未登入 job、dashboard 或 ISO repository 查核設定。沒有保留任何接單後的個人 run／PR／Requirements／Design 連結。
4. 文件時間性：現在有，不等於最初就有
| 觀察到的時間 | 對本次評估的意義 |
|---|---|
| DSAF 參考頁目前版本更新於 2025-10-30 | 早於這批工單建立，較能作為既有參考。 |
| 前 8 張單建立於 2026-03-24 | 15160、15161、15188、15191、15194、15209、15210、15211。 |
| Epic 現在引用的 Q3 Kickoff 頁建立於 2026-04-15 | 不能用該頁證明 03-24 建單時就有這份資訊；也未認定該連結在建單當天就存在。 |
| FIPS 三單建立於 2026-05-28 | 15737、15743、15745；現行 Kickoff 的 FIPS 排除說明記錄的是後續調整。 |
| Ubuntu 專屬 Kickoff 建立於 2026-01-16，目前為 第 76 版（2026-09-24） | 頁面早於工單，但現在內容不能直接當作首次接單時的內容。 |
建立／更新時間不是首次指派時間。本次沒有歷史版本與首次指派快照，因此不據此判定當時是否已能取得每一項資訊。
5. 團隊討論：工作契約缺什麼？
| 討論題目 | 涉及工單 | 建議確認的最低資訊 |
|---|---|---|
| Support／Create OS template 的交付邊界？ | 15160、15191、15194、15737 | 映像、平台設定、pipeline 接入各自是否在範圍內；適用環境；可參考哪個既有平台。 |
| 每張單要驗證到哪一層？ | 平台／framework 單 | 成功排程、完成執行、辨識正確、功能通過，哪些是必要條件；代表性驗收方式。 |
| Regression 輸入與範圍由誰決定？ | 15209–15211、15743 | Build、suite／case、環境、kernel／模式矩陣；是否已有權威設定可直接引用。 |
| 失敗已驗證，是否能結案？ | Regression 單 | 可接受失敗的條件、誰批准、需要留下什麼紀錄。 |
| 可行性由開單者先確認，還是接單者先調查？ | FIPS 三單 | OS／供應商支援證據、FIPS 定義。若要先調查，應列為待辦，而不是預設可實作。 |
| 文件入口能否持續代表正確範圍？ | 全部 | 權威文件、維護者；範圍變更是否同步回工單，不只是更新 Kickoff。 |
建議的最小接單資訊
不必每張單都寫長篇 Design，但工單或明確引用的文件至少能回答：
- 交付物與不包含的範圍。
- 適用環境與平台版本基準。
- 修改／操作入口，以及既有參考。
- 必要輸入與前置條件。
- 可判定完成的驗收方式及證據。
最小改善：若已有 SOP，不必重寫；把正確入口、適用範圍及必要驗收連回工單。讓接單者研究「如何做」，而不是自行猜測「要做到哪裡」。
6. 可用的討論開場
這批單不是完全沒有資訊：平台、工作方向、部分 repo／job 入口與高階驗收條件都有。但排除接單後補寫的文件，仍有不少範圍與驗收決策需要靠背景知識或再問人。DSAF 的共用文件提供了比較具體的參考；Lift template 與 regression 單則較缺交付邊界及測試矩陣。FIPS 更需要先確認可行性。希望討論的是：哪些資訊應在開單時就提供，哪些可以由接單者研究，以及哪些決策不能留給接單者自行猜測。
評估界線：上述缺口針對本次已讀的工單與指定文件，不代表團隊其他地方一定沒有 SOP。Linux 流程圖內容未能讀取；首次指派與歷史版本未還原；原有操作入口未登入驗證。