拿別人的 spec 時要把問題分成三堆

別人給的規格與自己寫的規格，關鍵差異是你沒有改它的權限。所以審出洞之後多一層分流；分不清「能自己決定」和「必須問」，結局就是被阻塞到死或自作主張做錯。

類型	處理
能自己決定	記成「假設」寫進自己 repo 的補充規格，標明「未經 owner 確認」——陳述它，不要問它
必須問 owner	進阻塞清單，立刻送出，並且送出後不要停：把阻塞的 AC 標記起來，其他照走
對方顯然沒想過	送出，但同時附上建議答案

第三堆是 turnaround 的勝負點

問「重送會怎樣？」對方可能想三天；問「重送我打算做成冪等、回同一個結果，可以嗎？」通常當天回。

先確認 spec owner 是誰、回問管道、turnaround 多久 —— 這決定你的阻塞成本；也先確認你能不能改那份文件（通常不能 → 另外維護補充規格，不去改對方的）
自己建一張有 id 的 AC 表（外部 spec 通常是散文、沒有可引用的單位）。自己寫 spec 時這張表是免費的，這裡要額外做一遍——但這是唯一能建立追溯鏈的機會，別省 → AC id 追溯鏈讓改規格的影響變成一個 grep
契約凍結後要回送給 owner 確認：這份契約其實是你對他的 spec 的正式解讀，而契約是具體的，回送它比讓對方讀一份問題清單有效得多。不確認的話，誤解會被凍結進去，然後炸掉所有平行線。

外部 spec 是假具體的重災區——對方寫的時候不需要實作，很容易停在「拒絕」「處理完成」這種層級。