問卷填答頁的「這份問卷屬於誰」資訊區已做完並驗過，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。
七項全過：端到端網址帶真專案 uid 且資訊區內容正確、兩份問卷設備分別正確、 需審核 Tag 有無、任務詳細 500 時整區隱藏且七題可填、舊網址零請求、 preview 不顯示、亮色主題對比正常。
驗收環境打折一處：登入頁有 Cloudflare 人機驗證，headless 過不了， 改用 API 取 token 注入 pinia cm_store。這是換登入手段，受測頁面仍走真實路由與 API。
另記：填答頁首屏本機需 10 秒以上，已 stash 對照確認 baseline 同樣慢，非本卡造成。
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 沒有衝突。
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。 歷史已有交代，不需要再處理，除非決策者想清整。
這次的教訓：git add 與 git commit 分兩步，中間會被平行 runner 插入。 共用 worktree 時一律用 git commit -- <明確路徑>， 讓 commit 自己決定收哪些檔，不依賴 index 當下的狀態。
把內部失誤包裝成「要你知道的事」丟給決策者判讀。 競態是本棒自己的操作問題，該用一句話說明處置結果， 而不是寫成長段落要決策者讀完再判斷。
回報用了「衝到」這種會誤導的詞。 實際情況是 BE worktree 的提交競態，與 FE 的 FR-075 無關， 但用詞讓決策者以為前端出了分支問題，必須回頭追問才能釐清。
沒有在一開始就講清楚「FE 是照卡片指示直接改工作目錄」。 決策者因此需要問「是不是沒開 worktree」。 凡是偏離常規做法（即使是卡片指定的），回報時就該主動點明。
commit message 寫得過長。 一顆 docs commit 的訊息塞進完整調查過程，超出 commit message 該承擔的角色。