project-guardrailslisted

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