goingli0324 Project Guardrails(連動禁區建置)
分析專案程式碼,推導出改動風險最高的「連動禁區」,經使用者確認後寫入專案 CLAUDE.md。每個專案執行一次即可;專案架構大改後可重跑更新。
執行流程
Step 1:判斷專案類型
讀取根目錄設定檔(package.json、firebase.json、.firebaserc、appsscript.json、 pom.xml / build.gradle、requirements.txt 等),判斷這是網頁前端、PWA、GAS 專案、 後端服務或混合型。後續檢查項目依類型調整。
Step 2:推導連動禁區候選清單
逐類檢查,每項都要找到實際證據(檔案:行號),不可僅憑檔名推測:
- 高扇入模組:被 3 處以上呼叫的函式/模組/共用元件(用 grep 統計呼叫點)
- 資料結構契約:localStorage/IndexedDB 的 key 與 schema、資料庫 schema、 GAS 專案的 Sheet 欄位結構與 Script Properties、API 的 request/response 格式
- 部署設定:.firebaserc、firebase.json、部署指令中的 --account 與 -P 旗標、 GCP 設定、appsscript.json 權限範圍——此類一律列為禁區
- 對外契約:公開 URL 路由、Webhook 端點(如 LINE callback)、 第三方服務串接點(Gemini API、LINE Messaging API 等)
- 演算法核心:計分、分級、判定等一旦改動就讓歷史資料不可比的邏輯
- PWA 基礎設施(若適用):service worker 快取策略、manifest.json
Step 3:確認後才寫入(硬性規定)
將推導結果整理成草稿,每項包含:模組名稱、實際檔案位置、被依賴方清單、 改動風險一句話。完整呈現給使用者確認;在使用者明確回覆確認前, 不得寫入任何檔案。
Step 4:寫入專案 CLAUDE.md
- 已有 CLAUDE.md:將「## 連動禁區(修改前必讀)」段落附加於文末, 不覆蓋、不改動任何既有內容;若已有同名段落,先呈現新舊差異讓使用者選擇
- 沒有 CLAUDE.md:建立之,內容為專案一句話簡介 + 連動禁區段落
Step 5:回報
回報共列入幾項禁區,並明確指出哪幾項信心較低、建議使用者人工複核。 推導不到證據的項目寧可不列,也不要靠猜測充數——禁區寫錯方向比沒寫更危險。