專案邏輯地圖
幫助維護者和 AI 回答：改什麼、影響哪裡、不能破壞什麼、如何驗證。
選擇任務範圍
- 初次生成：從需求和程式碼取證，生成 Markdown 關係地圖。用戶需要視覺瀏覽或已有 HTML 時，同時生成或維護視覺圖。
- 增量更新：保留穩定編號，僅更新變化的事實、關聯、狀態與圖。檢查被刪除節點的引用。
- 影響分析：圍繞給定改動追蹤輸入、消費者、狀態、異常分支、約束和驗證；用戶只問分析時，不實施改動。
優先使用專案現有檔案與編號。新專案預設輸出 docs/LOGIC_MAP.md；視覺版預設 docs/logic-map.html。已有命名或用戶指定位置優先。
先取證，再建關係
讀取專案約定、需求基線、關鍵入口、頁面/工作區、狀態與儲存、業務流程、測試和發布記錄。沿核心用戶任務讀取必要程式碼，不必逐檔案窮舉倉儲。
明確區分：需求承諾、實際實現、自動化檢查證據、執行環境驗證、外部審核。舊記錄標日期與證據範圍；未執行的檢查不能寫成通過。
重點追蹤：
- 多個入口是否真的共享同一處理鏈，哪些繞過了某些步驟。
- 資料由誰建立、持有、消費、覆蓋、釋放，是否持久化或離開本機。
- 取消、空資料、拒絕、超限、解析失敗各自如何結束。
- 高頻更新、批次、閾值等是否承擔專案特定的不變量。
發現文件與程式碼衝突時分別記錄，不為了圖好看強行合併。發現程式碼風險可寫入缺口，不自動擴大任務為修復。
建立可追溯模型
讀取 references/model.md，採用其中節點、關係和證據欄位；結合專案已有編號簡化或調整。
先寫核心任務的一句話定義和主鏈，再補正常/異常分支、跨頁面狀態、介面、約束和驗證。圖上相鄰不等於有關係；每條邊都要能解釋其含義與依據。
預設交付結構：
- 能力總覽：讓讀者先知道產品能做什麼。按真實用戶任務歸組，不能把技術分圖數量當成能力數量，也不要固定為本例的五組。
- 單項能力流程：展開入口、動作、處理、狀態與出口，標註分支條件。
- 節點說明與證據：職責、直接關聯、實現位置、約束、驗證與狀態。
- 改動影響索引：常見改動對應哪些節點、檔案和檢查。
總覽可以省略次要關係，但完整模型或節點說明必須能找回。需求文件繼續負責需求裁決，地圖不要另建一套需求基線。
HTML 視覺交付
需要 HTML 時讀取 references/visual.md。如需具體參考，再查看 references/wechat-example.html；它是已實現專案的例子，不是通用事實或固定佈局模板。
讓節點與語義邊共用一份資料。檢視座標、路由、主題單獨管理，Markdown 與 HTML 使用相同 ID。簡單專案可直接維護小型資料結構，不強制引入生成器或圖形庫。
保留用戶已確認的視覺方向。預設採用居中限寬、能力總覽入口、單項流程導航、圖下方說明與淺暗雙主題。節點數量和分圖方式由內容密度決定。
不要複製範例的微信專屬術語、大小閾值、待驗證狀態或手工座標到其他專案。產品根分組僅為展示結構時，明確標記，不把它當新增業務能力。
驗證與交付
內容與結構：
- ID 唯一；邊的端點存在；關鍵能力都有下鑽入口；刪除節點無懸空引用。
- 包含、資料流、依賴、約束和驗證各有語義，不將它們混成執行順序。
- 儲存生命週期、異常出口、實現位置和狀態可以由證據支援。
- 自問一次具體改動，例如「改變排版會影響什麼」，地圖應能追到相關狀態、消費者和驗證。
視覺版還需實際開啟瀏覽器檢查：
- 總覽同時展示全部主要能力，文字清楚，箭頭不穿節點或文字。
- 逐個開啟能力流程，驗證下鑽、跨圖關聯、選中狀態、取消選擇。
- 檢查淺色與暗色的文字、節點、連線、箭頭和說明；捕捉截圖。
- 檢查目標桌面尺寸的總覽完整性；窄視窗保持可讀字號，允許圖內捲動或改為分圖。
靜態語法或結構檢查不能替代視覺檢查。瀏覽器不可用時交付檔案並明確未完成的檢查，不能拿舊截圖冒充當前結果。
交付連結、主要關係變化、實際檢查結果與剩餘缺口。按專案 Git 約定儲存工作；不自行發布網站或安裝全域 Skill。