# CM-1660 交接（2026-09-11）

## 一句話

問卷填答頁的「這份問卷屬於誰」資訊區已做完並驗過，patch 落在 BE FR-080 worktree，
Notion 卡已回寫、狀態「修正待驗證」。**未 push。** 待決策者複測。

---

## 一、這棒交付了什麼

| 項目 | 位置 |
|---|---|
| FE 改動 patch（228 行） | `compliance-manager-be-fr080/docs/features/FR-080-2609-jedi-consolidation-and-service-path/handoff/CM-1660-survey-fill-context.patch` |
| 套法／疑點全文／手測結果 | 同目錄 `CM-1660-survey-fill-context-README.md` |
| commit | `8d127d0b`（branch `feature/FR-080`，未 push） |
| Notion | CM-1660 已 append 回寫，狀態＝修正待驗證 |

改的是 FE 兩個檔（`JobExecutionDrawer.vue` +6/-1、`SurveyPreview.vue` +138），
patch 已驗證 `git apply --check` 通過。

---

## 二、卡片要釐清的疑點：結論

`main_project_uid` **不是專案 uid**，與抽屜用的專案 uid 本來就是兩個不同的東西：

- `main_project_uid` → `compliance.workflow_executions`（流程執行，type `MAIN_PROCESS`）
- 抽屜的 → `compliance.projects`

不同表、不同 id 空間。之所以一直沒出事，是因為任務詳細端點
`GET /grc/project/<project_uid>/job/<job_uid>` 的 handler **收下 `project_uid` 後沒用它**，
只拿 `job_uid` 查。實打四種值（真專案 uid／`main_project_uid`／全 0 uuid／字串 `garbage`）
**全部 200 且回應 md5 相同**。

**採用解法**：由抽屜把它本來就有的真專案 uid（`props.projectId`）當 query 參數帶進填答頁。
舊網址沒帶就不打任務詳細、資訊區隱藏，填答不受影響。

**衍生安全疑慮（未處理，建議另案）**：該端點不驗歸屬，任何登入者換個專案編號
都能讀到同一筆任務，與 FR-086 B1 那四條「只驗身分不驗歸屬」同型。本卡純 FE 未動 BE。

---

## 三、手測結果（DEV，BE 8000 / FE 5180，headless Chromium 實跑）

七項全過：端到端網址帶真專案 uid 且資訊區內容正確、兩份問卷設備分別正確、
需審核 Tag 有無、任務詳細 500 時整區隱藏且七題可填、舊網址零請求、
preview 不顯示、亮色主題對比正常。

**驗收環境打折一處**：登入頁有 Cloudflare 人機驗證，headless 過不了，
改用 API 取 token 注入 pinia `cm_store`。這是換登入手段，受測頁面仍走真實路由與 API。

**另記**：填答頁首屏本機需 10 秒以上，已 stash 對照確認 baseline 同樣慢，非本卡造成。

---

## 四、下一棒要知道的三件事

### 1. FE 沒有 worktree，改動走 patch，工作區已還原

FE repo 只有一個工作目錄，在 `feature/FR-075`（`git worktree list` 只有一筆）。
卡片與派工都明寫「不要開 worktree、不要在 FR-075 commit」，
所以做法是：改檔 → 跑起來手測 → `git diff` 存 patch → `git checkout` 還原。

現況已確認乾淨：分支 `feature/FR-075`、`git status` 無輸出、`git stash list` 空。
**FE 全程沒有任何 commit，與 FR-075 沒有衝突。**

### 2. BE FR-080 worktree 有一顆訊息與內容對不上的 commit（已被下游補救）

`98e2122c` 掛著 CM-1660 的訊息，內容卻是 CM-1661 的四個檔
（RLS migration、manifest、init schema/stamp）。

成因是**共用 worktree 的提交競態**：本棒 `git add` 之後、`git commit` 之前，
平行跑的 CM-1661 runner 對同一個 worktree staging 了它的檔案，commit 收到的是它的內容。
（FR-080 worktree 有自己的 index，但同一時間兩個 session 對它讀寫仍會互相覆蓋。）

處置：本棒先完整備份該 commit 內容，改用 `git commit -- <指定路徑>` 限定路徑
重新 commit 成 `8d127d0b`（內容正確），**未改寫 `98e2122c`**（共用分支歷史＋別人的成果）。
已逐檔 diff 確認 CM-1661 四個檔完好，無工作遺失。

**後續**：CM-1661 那棒已自行補上 `acde6b7c` 說明該情況並指向 98e2122c。
歷史已有交代，**不需要再處理**，除非決策者想清整。

### 3. 多 session 共用同一個 worktree 時的 commit 做法

這次的教訓：**`git add` 與 `git commit` 分兩步，中間會被平行 runner 插入。**
共用 worktree 時一律用 `git commit -- <明確路徑>`，
讓 commit 自己決定收哪些檔，不依賴 index 當下的狀態。

---

## 五、本棒的判斷失誤（誠實記錄，供下一棒避開）

1. **把內部失誤包裝成「要你知道的事」丟給決策者判讀**。
   競態是本棒自己的操作問題，該用一句話說明處置結果，
   而不是寫成長段落要決策者讀完再判斷。

2. **回報用了「衝到」這種會誤導的詞**。
   實際情況是 BE worktree 的提交競態，與 FE 的 FR-075 無關，
   但用詞讓決策者以為前端出了分支問題，必須回頭追問才能釐清。

3. **沒有在一開始就講清楚「FE 是照卡片指示直接改工作目錄」**。
   決策者因此需要問「是不是沒開 worktree」。
   凡是偏離常規做法（即使是卡片指定的），回報時就該主動點明。

4. **commit message 寫得過長**。
   一顆 docs commit 的訊息塞進完整調查過程，超出 commit message 該承擔的角色。

---

## 六、待辦

- [ ] 決策者複測填答頁資訊區（抽屜 →「指派人員測試」專案 IA.L1-3.5.1 [b] → 開啟問卷）
- [ ] 複測通過後 push（**等令**）
- [ ] `98e2122c` 是否清整 — 已有 `acde6b7c` 交代，預設不處理
- [ ] 任務詳細端點不驗 `project_uid` — 建議併入 FR-086 那類授權缺口另案評估