解剖 /develop：AI 憑什麼不用問你

/develop

/develop 
ldap 後端進度如何？
我要開始處理前端，針對他提供的 api 幫我釐清一下，有哪些方向以及對應的 UI？

skill 啟動後，啟動一個 team lead 並自動判讀以下狀態以接續行動：

triage, clarify, planned

team lead 第一件事是釐清兩個狀態。

第一個：這條分支上有沒有沒跑完的 run？
.claude/runs/<feature>/PLAN.md 存在，就讀出本端的 phase：
clarify、planned、go、developing、dev-done、reviewed、docs-done，從那個字接著跑。
換人、換 session、隔天再來，都是同一趟。
新 session 接手時，已封存設計的關鍵事實前提都會自行先重驗一次，
前提破了就直接問，不准當沒事繼續。

因為某天，我不小心按了 /clear，然後進度付之一炬。

第二個：這趟該多重？
你只是要改十行 code ，可依舊繁文縟節的重裝跑完成流程？
浪費時間。讓 team lead 自己判定要不要走不就得了。
意圖單純的小改動、不跨專案、無重大變更（契約 / schema / 遷移 / 併發等），
全中走 quick mode，一句話確認範圍後派工，跑完就報，報完交付。

同一個小更動，派工次數可以從 40 次降低為 8 次。

兩個狀態確認完，換問需求。

一、這次的範圍是：登入頁加一個「用 LDAP 登入」的入口，還是要包含一個獨立的 LDAP 設定管理頁（網域／connection 設定）？
二、LDAP 認證失敗或服務不可用時，要 fallback 回本地帳密，還是直接擋下不給登入？
三、我在 docs/features/ 底下沒看到 LDAP 對應的資料夾——這次要新開一個（例如 ldap-auth）記錄這個功能的 criteria 嗎？
四、現有登入頁的 e2e 測試會覆蓋到你要動的這幾個 selector／route 嗎？如果會，這次要不要一併補 LDAP 分支的測試案例？

需求不明朗時絕不瞎猜，team lead 批次提問逐步 clarify：
確認你是要更動哪一端的項目，抑或是一次處理完整個 flow。
實作不清楚直接派調查員回報，將前提驗證清楚；
是否破壞先例以及商業邏輯，派研究員畫 impact map；
edge case 如何因應，詢問並建議。

一切就緒開始 planned：
拆解工作事項、細節整理，
避免日後偏離，白費工夫又燒 token。
最終列出大方向給人類過目，直至人類喊出個 go。

go, developing

此階段我要的目標就是程式寫完、測試滿足、審查驗證，
GO 之後怎麼派、派幾個 subagents、分幾輪，全是 team lead 自己的判斷。
我完全不管，我只提供預先設定的 role (coder, tester, reviewer, syncer, etc.)、工具與相關知識，你自己判斷要用什麼。
在核可範圍內，若驗證發現 critical issues 則自我修復；若需要改變需求或設計，就回頭確認。

一段輸入框的驗證邏輯，舊寫法為只在使用者點開別的地方時才檢查；
但此次規格要求打字當下就要即時驗證。審查在送出前抓到這個落差，回報 team lead，
而 team lead 再度派出 coder 改掉。
當然，人類這時還在喝咖啡，甚至不需要知道這件事。

另一個前提是每個角色不會共享其他人的 context，以避免自己考試自己計分。
全數依靠 team lead 的最基本指令傳遞，以及自身的契約，專注獨立達成一件事。
因此，reviewer 才能以盡量公正的角度看待成果。

不過肯定也會遇上無解問題的時候，有些事就是要跑過才知道。
可若一味地要求自我修復，問題還沒解決時間跟錢已經耗盡了一大半。
失敗必須有上限，達到上限或需破壞原始設計時凍結整趟 run，把錯誤原文攤給使用者決定。
其餘全部自己決定，留下一行記錄以供備查。

LDAP 登入的測試寫完了，tester 卻自己舉手：
這份測試會過，但它什麼也沒測到，它只是照著程式本身抄出來的。
明明塗個綠就能交差，它把這句話送到人類面前。

dev-done

工作項全部帶著證據交完，這一格才打得開。
不過前階段的分片式實作，每輪只會注重當下，卻少了全局觀。
因此此階段只做一件事：把整趟 run 的成果從頭到尾再審一次，
然後決定哪些發現可以自己修、哪些必須攤開來問。

審查是兩路並行的。
程式本身與商業邏輯。

/code-review 從不同面向檢視程式碼與測試碼。
另一位 reviewer 專門看領域邏輯與契約正確性。

為什麼不合併？
因為當一個 reviewer 帶著所有知識進來，橫跨數十檔案，注意數十面向，結果就是樣樣通樣樣不精。
臭蟲是埋在某片葉子底下的，可不是晃過一眼就會發光的翹著屁股說我在這裡。

還有一條規矩：使用者先前已經裁決過的項目會當作參數一起送進去，
命中的在分流時就丟掉，不重報、不重審。
被否決過的建議不該每一輪都復活一次。

上一輪的 reviewer 問「你有沒有照著做」；
這一輪的 reviewer 問「這件事誰決定過」。
回來的發現分成三堆：

• 證據確鑿的 bug 與 critical：直接修，不必問；
• 違反專案規則的：直接修，不必問；
• 判斷題：永不自動套用，進建議表，交給人裁決。

那這些 reviewer 只要理直氣壯地回報就可以信任？那可不行。
規則要求每一個發現都要帶檔案的出處，
沒有引文的結論一律當臆測，動不了任何決定；
份量夠重的還要另外派人去反駁它，反駁不掉才算數。

一個 reviewer 報說：某個錯誤碼在所有設定檔裡都沒有定義。
另一個 reviewer 搜尋一次便結束爭論：它在其中一份的兩個地方都寫著。

最後是建議表，詢問 user 是否要當個童子軍順手做某些事：
夾帶著來源、現狀、建議、成本、建議處置，
連零影響、預設不採納的列都照樣列出來給人看過。
修完再迅速複驗，不再重跑一次 /code-review。
建議歸零，phase 才翻得成 reviewed。

reviewed, docs-done, finished

程式審完了，建議消除了，終究得來個全套測試。
在測試進行時，可以同步派遣 syncer 去更新文件。
一邊測試、一邊改文件，兩邊的檔案不重疊。

文件可不是照抄最初計畫，而是總結成果：
做了什麼、偏離了什麼、接下來哪一端要交接。

要記住的是，文件有兩大面向：
給非技術人員的總結、給下次 agent 能閱讀的從程式中看不出來的決策。
畢竟曾經的我也通靈一個月前的我為何要這樣寫。

最終，team lead 問一句開發者：
「是否要 retro ？」
把整段開發流程的摩擦點全數記錄下來，審視自己、評判效率、剔除無謂、提出建議。
化為一檔，跟隨開發者最終同意的 commit 等待收割。

它不相信任何人說「做完了」，
包括它自己。

後端有一支清理腳本，負責在測試跑完之後把留下的容器收乾淨。
每一趟測試的回報上都寫著同一行：已由 hook 自動清理完成。
然而那支腳本從來沒有被執行過。
它總是報著「這件事應該會自動發生」，不是「我看到它發生了」。
它在那裡躺了快兩個月，沒有人發現，直到最後被自我檢查標記，然後刪除。