CORE
STEP 0 / 6
Anchor — 讀使用者當下實際在哪
為什麼這步 ：對應命題 P8「被動就緒」+ 憲法級「Tool Call Data Honesty」+ 「Active State Re-Anchoring」（5/22 新增）。先讓 AI 讀使用者當下實際所在的視圖/樓層，**所有後續操作以這個 anchor 為基準**——不假設使用者在 1F，不依賴 handson 文件預設的「日本 sample 應該是 53189012」這類 hardcoded 期望。
COPY
📋 Copy 請呼叫 get_active_view 告訴我我現在在 Revit 哪個視圖。
請列出：視圖名稱、類型、樓層、ViewId（4 項都要）。
不要做任何進一步推論。
✓ 預期觀察
AI 回一行：「您目前在『{視圖名}』，類型『{FloorPlan/Section/...}』，樓層『{LevelName}』，ViewId={數字}。」
PASS 如果 AI 開始建議「您可以做 X、Y、Z」——那是它違規（沒被問就答）。命題 P8 被破壞的樣子FAIL AI 列出具體房間 ID 但你沒呼叫 get_rooms_by_level——違反 Tool Call Data Honesty📌 把 ViewId 與 LevelName 抄下來 ，但**這只是「Step 0 時的 anchor」**——後續每個 level/view-anchored 步驟（Step 2/3/5）AI 都應該重新 re-anchor，不依賴 Step 0 的 snapshot
📌 Active State Re-Anchoring 規則（5/22 新增，憲法級）
**任何引用 view-state / level-state 的 claim 之前，AI 必須在 claim 時點重新呼叫 get_active_view 確認**——不能依賴 session 較早的 read 結果。使用者隨時可能切視圖（這是真實設計師工作流，一邊看作業用、一邊翻法規、一邊跳到矩計），AI 沒有任何「異常」可偵測，只是在 stale snapshot 上繼續做 claim。詳見 domain/session-context-guard.md 與 domain/lessons.md L-025。
💭 互動反思
你想要的 AI 是「對」的 AI 還是「快」的 AI？
CORE
STEP 1 / 6
確認當下視圖是否適合後續操作（read-only intake）
為什麼這步 ：5/22 redesign。原版設計「強制切到 1F」是錯的 ——真實設計師不會配合 demo 文件預期，他們會繼續按自己工作流切視圖。Step 1 改為 read-only intake：確認 Step 0 抄下的視圖類型 / 樓層**適不適合**後續 ARCHI 合規檢查；若不適合（例如使用者在 3D 視圖 / 剖面視圖 / 非檢討樓層），由使用者決定要不要手動切到合適的平面。
COPY
📋 Copy 根據 Step 0 抄下的視圖類型與樓層，請判斷後續 ARCHI 合規檢查（外牆開口、排煙、樓梯淨高、採光、樓板有效開口）是否能在這個視圖上正常進行：
- 視圖類型必須是 FloorPlan（平面）——若是 3D/Section/Elevation，請告訴我「請手動切到平面視圖再繼續」
- 樓層必須是有實際房間定義的（不能是 GL/設計GL/外構等）——若是無效樓層，請告訴我「此樓層無房間資料，請手動切到 1F-7F 任一」
- 若視圖名稱含「詳図/作業用/法規チェック/階段/建具/矩計/展開」等專用前綴，視圖內容可能被 view template 過濾——建議切到「平面図 X 階」這類主平面視圖
不要呼叫 set_active_view 替我切視圖——讓我自己決定切到哪。
回報格式：「您目前的視圖『{name}』是 {OK/不建議}，原因：{...}。」
✓ 預期觀察
AI **不呼叫 set_active_view**——這是 read-only intake，光譜決策（要不要切視圖）在使用者端
AI 給出 OK / 不建議的判斷 + 一句原因
若視圖 OK → 直接進 Step 2，**Step 2 會以這個視圖的 LevelName 為基準**
若視圖不建議 → 你手動切到合適平面（或不切，後續結果可能異常）
PASS AI 沒幫你決定要切哪個視圖——光譜在使用者端FAIL AI 自己 set_active_view 切到「它認為對的」視圖——這違反 Step 1 的 read-only intake 精神
⚠ 真實工作流場景（5/22 dry-run 實證）
5/22 dry-run 中段使用者刻意在 Step 1 後再切 6F → 2F duplicate → 不告訴 AI。**正確的 AI 應該在每個後續步驟（Step 2/3/5）開頭都重 re-anchor**，跟著使用者眼前的畫面跑，而不是綁死在 Step 0/1 抄下的 LevelName。這對應雙向 Context Sync 協議——使用者切視圖是天然行為，AI 應主動跟上。
CORE
STEP 2 / 6
看看這層樓有什麼
為什麼這步 ：對應命題 P7「階段完成點」——我們先看「具象成果」是什麼，再決定要檢什麼。
COPY
📋 Copy 請呼叫 get_rooms_by_level 帶 level="<把 Step 0/1 抄下的 LevelName 填這，例如日本 sample 是 1FL>"。
列出這層樓所有房間：ElementId、Number、Name、Area。
表格呈現，不要加任何分析建議。
✓ 預期觀察
AI 回一張 markdown 表格，欄位：Room Number / Name / Area
房間數量視日本 sample 內容而定（住宅 sample 約 5-10 間）
PASS AI 沒主動分析「您的客廳偏小」——這是它正確遵守「不問不答」
💭 哲學意義
這個列表就是命題 P7「具象成果」——你看著它，腦袋才有東西可以跑光譜決策。如果沒列出，後面所有檢查都是抽象的。
★ CORE STAR
STEP 3 / 6 — 整場練習的核心
觸發 ARCHI 合規批次檢查
為什麼這步 ：這是整場 Live Demo 的核心。 對應命題 P4「限制顯現器」+ P16「Work Breakdown 讓階段完成點可識別」+ P22「ARCHI 優先」。一個 prompt 編排 5 個既有工具並行檢查，這就是「96 工具編排平台 = 業界真空白」的具體呈現。
COPY ★ 核心
📋 Copy 我已完成 1F 建築設計（LOD 300 階段完成點）。
請依台灣建築技術規則做 ARCHI 合規批次檢查，並行呼叫以下 5 個工具：
1. check_exterior_wall_openings — 外牆開口 (§45 / §110)
2. check_smoke_exhaust_windows — 排煙窗 (§188)
3. check_stair_headroom — 樓梯淨高
4. get_room_daylight_info — 採光比 (§41)
5. check_floor_effective_openings — 樓板有效開口
回報格式：
- 每個工具 PASS / FAIL（簡短）
- FAIL 的列出不通過項目（房間/牆/樓梯 ID + 為什麼不通過）
- 不要給「應該怎麼修」的建議——那是我的工作
✓ 預期觀察（已對齊 2026-05-18 修復後實機）
AI 並行（或快速序列）呼叫 5 個工具 （含 check_stair_headroom levelName 批次模式）
5 個工具全部正常回應 ，無 C# crash、無 output 超限
日本 sample 1FL 預期結果：
check_exterior_wall_openings → 通常 violations 3 + warnings 5 + passed 32 （445 牆 / 40 開口）— summary 模式回 < 1KBcheck_smoke_exhaust_windows → FAIL × 3 （店舗 26 / 駐車場 27 / ピロティ 141，無窗居室）check_stair_headroom → PASS × 2 （樓梯 ID 53565361 / 53566122，1FL 樓梯全合格）get_room_daylight_info → raw data（20 房間 + 開口清單），不回 PASS/FAIL — 在 Step 4 自算check_floor_effective_openings → FAIL （判定無開口樓層，23 開口全 NeedsManualConfirm）
PASS AI 沒幫你寫「建議改為 1500mm 寬」——對應 P13「MCP 是 0/1 執行器」FAIL 如果 AI 開始長篇分析每個 FAIL 怎麼修 → 它違規 P13PASS AI 對 NeedsManualConfirm 的回應是誠實標示 （如「無法判定開啟方式，需人工確認」），不是編造數據 ——對應 Tool Call Data Honesty
✅ 修復歷程（2026-05-18 同日內 fix）— 這是練習頁的活體案例
5/18 早上第一次跑這個批次時，4/5 工具有問題 （exterior 超限 / smoke 建 80+ 視圖 / stair 不支援 batch / floor C# crash）。當天下午 4 個 fix 全做完、build、deploy、實機驗證 5/5 通過。修復清單：
Issue 5 ：check_floor_effective_openings 的 OfCategory(OST_Walls).Cast<Wall>() 撞 FamilyInstance crash → 改 OfClass(typeof(Wall))（1 行 fix）Issue 1 ：check_exterior_wall_openings output 60K+ chars 超 MCP 上限 → 加 summary 參數預設 true，只回統計 + 違規清單（< 1KB）Issue 2 ：check_smoke_exhaust_windows 每次建 80+ 視圖污染瀏覽器 → 加 createAnnotatedViews 參數預設 falseIssue 3 ：check_stair_headroom 只吃單一 stairId → 加 levelName 參數支援 batch 模式
5/23 demo 講者重點 ：這個「實機測試發現問題 → 同日 fix → 重測驗證」的歷程本身就是 0523 哲學的最佳實證——P15「死線下交付物優先」+ P12「死局求助更多人」（測出 bug 不是繞道而是 fix）+ Tool Call Data Honesty（沒掩飾 bug，直接公開）。
⚠ Tool Scope Mismatch（5/22 新增）— 同批 5 工具的回應範圍不一致
這 5 個工具中，1 個是 project-wide、4 個是 level-scoped ：
check_exterior_wall_openings → project-wide （不吃 level 參數，掃 445 牆全跑）check_smoke_exhaust_windows / check_stair_headroom / get_room_daylight_info / check_floor_effective_openings → level-scoped （吃 levelName / level 參數）
**這意味著**：若你在 2FL 跑這 5 工具，check_exterior_wall_openings 回的 8 項違規 **跨越多個樓層**（含 1F 開口 z=0/100 + 2F 高窗 z=3170），但被混在「2FL 合規報告」中容易誤判。AI 應主動 surface：「以下 5 個工具中，4 個是 X 樓層範圍、1 個是整案範圍——整案結果跨越多樓層，請勿假設它們都發生在當前樓層」。詳見 domain/tool-capability-boundary.md L7 與 domain/lessons.md L-026。
🎤 講者互動點
問現場「你們各位看到的數字一樣嗎？」——同一 sample 應該結果一致 （exterior violations=3 / smoke FAIL=3 / stair PASS=2 / floor 無開口樓層）。這是 MCP 的可重現性 vs 人工檢查的隨機性。順帶提：「如果你今天早上跑會看到工具 crash，下午就修好了——這正是開源協作的價值，也是 0523 哲學想傳達的『工具與工作流共同演化』。」
CORE
STEP 4 / 6
對某個 FAIL 深入查（光譜決策的起點）
為什麼這步 ：對應命題 P11「光譜在設計師端」+ P10「設計 = 解決問題，美學 = 手段」。AI 告訴你「FAIL」，接下來怎麼想是你的事 ，不是 AI 的事。
把 {ROOM_ID} 換成你想深入的房間 ElementId（如 52842360＝駐車場 27 是 5/18 實機跑出的排煙 FAIL 房間，剛好做雙重交叉驗證）
COPY
📋 Copy 請呼叫 get_room_daylight_info 帶 level=1FL 取得本層所有房間採光資料。
從報告中找出 ROOM_ID = {ROOM_ID} 那個房間，列出：
- 房間面積（m²）
- 該房間所有開口的：Category / Width / Height / SillHeight / HeadHeight / IsExterior
- 依 domain/daylight-area-check.md 公式逐筆計算：
· 若 SillHeight ≥ 750mm：Effective Area = Width × Height
· 若 SillHeight < 750mm：Effective Height = HeadHeight - 750mm，Effective Area = Width × Effective Height（負值取 0）
· 僅納入 IsExterior=true 的窗 + IsExterior=true 且含玻璃的門
- 合計 Σ Effective Area
- 採光比 = Σ Effective Area / 房間面積
不要建議任何修改方案，純報告數據。
✓ 預期觀察（已對齊實機）
AI 呼叫 get_room_daylight_info 帶 level=1FL 參數（工具不接 roomId ——schema 只有 level 一個 optional 參數）
回 raw data：本層 20 個房間 + 每房間 Openings 含 SillHeight / HeadHeight / IsExterior / Category
AI 自行套 75cm 公式 算 Effective Height（工具不算）→ 算採光比 = 小數（如 0.087 = 8.7%）
PASS AI 應該引用 domain/daylight-area-check.md 的公式——這是「Domain Method Compliance」憲法生效FAIL 如果 AI 直接用工具回的「數字」當採光面積，沒套 75cm 扣除——它違規 Domain Method Compliance
⚠ 這步是「兩條憲法同時生效」的試金石
Tool Call Data Honesty ：房間面積、SillHeight 等數據必須來自 tool response，AI 不能編Domain Method Compliance ：採光比的計算公式必須來自 domain/daylight-area-check.md，AI 不能用「常識」算看 AI 怎麼把 raw data 跟 domain SOP 接起來——這是 0523 哲學體系最核心的演示時刻
💭 哲學意義 — 光譜決策的起點（適用任何工具 FAIL，不限採光）
不論你拿到的 FAIL 是採光、是排煙、是樓梯淨高、是外牆開口——站在 FAIL 結果前的光譜決策結構是一樣的 ：選項 A ：直接修方案（加窗 / 加排煙設備 / 改樓梯）→ 結構衝突？立面美感衝突？預算？選項 B ：發現規範的扣除/限制太嚴苛 → 法規這樣寫，沒得改，認了選項 C ：改變空間定義（居室→儲藏室 / 一般空間→非檢討範圍）→ 業主的真實需求允許嗎？選項 D ：跳出 AI，找老闆 / 業主 / 結構技師 / 室內設計師（命題 P12 死局求助更多人）MCP 把這個選擇還給了你 ——它不替你決定，但它讓你知道你在決定什麼 。5/18 日本 sample 實測：真正回 FAIL 的是排煙（店舗 26 / 駐車場 27 / ピロティ 141 三間無窗居室）。同樣的 A/B/C/D 框架直接套——A 加排煙窗影響立面 / B 規範就 2% 沒得議價 / C 把店舗改非居室業主不肯 / D 跳出找業主談機械排煙預算。看吧，框架普適。
CORE
STEP 5 / 6
視覺化「規範限制施加的位置」（依規範類型分支：wall-anchored 直染 / room-anchored 走 proxy）
為什麼這步 ：對應 slide 6-4「報告解讀 + 決策路徑」三條路徑命題（P13 MCP 給 0/1、P11 光譜在設計師端、P12 死局求助）+ P3「限制可見」+ P4「限制顯現器」。視覺化的對象是「規範在哪裡施加限制」（規範本體），不是「AI 判定為 FAIL 的房間」（判定結果） 。後者違反 P5/P6 人機分工翻轉——把 AI 判定結果包裝太顯眼就是搶走設計師的光譜決策。
🔀 規範類型決定染色策略（5/22 新增分支）
(A) Wall-anchored 規範 （§45/§110 外牆開口距地界線）→ 染色對象是「違規開口所在的牆段」。直接走下方 Branch A prompt 。
(B) Room-anchored 規範 （§41 採光、§101/§188 排煙、停車淨高）→ 規範施加在「房間整體屬性」，沒有「違規牆段」。走下方 Branch B prompt（hosting walls proxy） 。
判斷方式：看 Step 3 哪個 FAIL 是你要視覺化的——若是 check_exterior_wall_openings 的 violations → Branch A；若是 check_smoke_exhaust_windows / 採光 / 停車 → Branch B。詳見 domain/tool-capability-boundary.md L8 與 domain/lessons.md L-027。
把 <PLAN_VIEW_ID> 換成 Step 0/1 抄下的當前樓層平面 ViewId（**用 re-anchor 後的，不要用 handson 預設的 53189012**）
COPY ★ Branch A — Wall-anchored（§45/§110 外牆開口）
📋 Copy 請先呼叫 get_active_view re-anchor 確認當前視圖 / 樓層（不要依賴 Step 0 抄下的）。
然後把步驟 3 中 check_exterior_wall_openings 回的 violatingOpenings 列表整理出**唯一的 wallId 清單**（同一面牆上多個違規開口算同一道牆），標上每道牆的最壞 status（Fail 或 Warning），然後用 override_element_graphics 在當前平面視圖上色：
- Fail 牆 → 紅色 surfaceFillColor={r:255,g:50,b:50}
- Warning 牆 → 黃色 surfaceFillColor={r:255,g:200,b:50}
呼叫 override_element_graphics 時**必須顯式帶** viewId=<剛剛 re-anchor 取得的 ViewId>。
⚠ Tool Scope 警告：check_exterior_wall_openings 是 project-wide，回的違規開口可能跨多個樓層（看 z 座標判斷）。若你只想染當前樓層的違規，請先過濾 z 座標。
完成後請回報：
1. re-anchor 後的 ViewId / LevelName
2. 呼叫了幾次 override_element_graphics
3. 每次回傳的 ViewName 是否都是當前平面（驗證 viewId 生效）
4. 在 Revit 平面是否真的看到牆段變色
⚠ 不要染房間：override_element_graphics 是給有 Cut Geometry 的元素（牆/柱）用的；Room 沒有 Cut Geometry，染了 API 會 Success 但平面視圖看不到任何視覺效果（5/22 lesson L6）。
COPY ★ Branch B — Room-anchored（§41 採光 / §101§188 排煙 / 停車）
📋 Copy 請先呼叫 get_active_view re-anchor 確認當前視圖 / 樓層。
然後針對 Step 3 / Step 4 找到的 FAIL 房（如排煙 FAIL 房、採光 FAIL 房），由於這是 room-anchored 規範**沒有「違規牆段」可染**，改用 hosting walls proxy 視覺化：
1. 呼叫 get_room_daylight_info 帶 level= 取得房間 Openings 詳資料（含每個 opening 的 HostWallId）
2. 從 FAIL 房的 Openings 列表蒐集出唯一 HostWallId 集合
3. 用 override_element_graphics 把這些 hosting walls 染紅 surfaceFillColor={r:255,g:50,b:50}，顯式帶 viewId=
完成後請回報：
1. FAIL 房名與 ID、它有幾個 Openings、去重後 HostWallId 有幾道
2. 呼叫了幾次 override_element_graphics
3. Revit 平面是否真的看到 FAIL 房的邊界牆變色
📌 視覺意義：這條 proxy 表達「房間的拓樸邊界」——例如事務室 §41 採光 0% FAIL 時，染色後可清楚看到「事務室的鄰居全是內部空間，沒有任何對外牆」這個拓樸問題。
⚠ 這是 proxy，不是命中規範本體：§41 限制施加在「房間的對外採光面積比」上，而非「某幾道牆」。染 hosting walls 只是讓設計師看見房間邊界，方便走光譜決策。詳見 domain/lessons.md L-027。
✓ 預期觀察（已對齊 5/22 redesign）
AI 從 Step 3 的 violatingOpenings 列表**自己去重 wallId**（不是被餵 4 個 ID）——對應 Tool Call Data Honesty「Σ 來自 tool response」
AI 呼叫 override_element_graphics 4 次 （2 紅 + 2 黃），全部顯式 viewId
每次回傳 ViewName 都是「平面図 1階」，且 PatternMode=Cut
Revit 1F 平面：4 道外牆段視覺上明確變色（牆有 Cut Geometry，跟 Room 不同）
PASS AI 沒去染 Room——對應 5/22 lessons：override_element_graphics 不支援 RoomPASS AI 沒染 PASS 牆綠色——AI 沒為視覺對稱而擴大宣稱（其餘 32 牆是「§45/§110 過關」≠「PASS 該被表揚」）FAIL AI 染 3 間 Room（用舊版 prompt 的話）——這是工具邊界，會 API success 但視覺 no-opFAIL AI 自己編了 8 個 wallId（沒去重 violatingOpenings 的重複行）——違反「Σ 來自 tool response」
✅ 修復歷程（2026-05-22 dry-run + 同日 redesign）— 練習頁的第二個活體案例
5/22 早上 dry-run 跑這條 path，原 Step 5 設計是「染 3 間 FAIL 房紅色」，實機跑下來：
C# API 回 Success=true（3 次 override_element_graphics 全部成功）
但 Revit 1F 平面**看不到任何紅色房間**——Room 在 FloorPlan 沒有 Cut Geometry，SetCutForegroundPatternColor 雖然存入 OverrideGraphicSettings，平面視圖視覺上是 no-op
調查發現雙重斷裂：
工具斷裂 ：override_element_graphics 在 5 個既有 skill（element-coloring、fire-safety-check、wall-orientation-check、parking-check、element-query）中的對象都是有 3D 幾何的元素（牆/柱/Parking）。Room 從未在任何 skill 中作為上色對象出現——因為 Room 在平面視圖染色靠 Color Scheme，不靠 SetElementOverrides概念斷裂（更嚴重） ：染 FAIL 房 = 把 AI 判定結果 視覺化 → 違反 slide 6-4 命題「MCP 給 0/1、設計師走光譜」。設計師才是「判定哪裡是問題」的人，AI 不該把答案包裝得太顯眼搶戲。視覺化該做的是「把規範限制本身畫進模型 」（如 fire-safety-check 染防火等級牆），不是「把 AI 判定包裝得搶眼」
同日 redesign：Step 5 改成染 check_exterior_wall_openings 回的 violation 牆段（§45/§110 限制施加位置）。lessons 寫進 domain/tool-capability-boundary.md L6。
5/23 demo 講者重點 ：5/18 是修工具 bug、5/22 是修 demo 設計。前者是「工具與工作流共同演化」的小演化，後者是「命題對齊」的大演化。兩者並列才是 0523 哲學的完整呈現 ——demo 不只是展示作品，是展示作品如何向命題靠攏的過程。對應 P9 滾動式集眾人開源 + P15 死線下交付物優先 + Tool Call Data Honesty（沒掩飾工具邊界）。
🎤 講者互動點
「為什麼染牆不染房？因為 §45/§110 是對牆下限制 ——『開口距地界線太近』是這道牆上的這個門/窗的問題 ，不是『這間房 FAIL』。把規範本身畫進模型，設計師才看得到『限制在哪』，才能決定怎麼跟限制協商（A 改開口 / B 接受 / C 改地界線協議 / D 找鄰地主談）。MCP 不是判定機，是限制顯現器。 」
CORE
STEP 6 / 6 — 光譜決策 + 視覺收尾
站在 4 道紅黃牆前現場走 A/B/C/D（純哲學，不呼叫工具）+ 清牆
為什麼這步 ：對應 slide 6-4 三條路徑 + slide 6-2「同步協作會議」終極場景的縮影。Step 3-5 已經完成「MCP 給 0/1」——現在輪到「設計師走光譜」。這步刻意不呼叫任何 MCP 工具 ——演示「人機分工」是把光譜決策還給人，不是讓 AI 替人決定。最後再 clear 牆收尾，呼應 P7「階段完成點」。
COPY ★ 純哲學決策
📋 Copy 請**不要呼叫任何工具**。我們現在站在 Step 5 染出來的 4 道紅黃牆前面，從中選 1 道 Fail 牆（53970839 或 54801079）做光譜決策示範。
請以「設計師立場」幫我把 A/B/C/D 四條路徑各寫一段話（每段 2-3 行）：
- A 修方案 → 把這道牆上違規的開口移位 / 縮小 / 改類型，工程上做得到嗎？美學上犧牲什麼？
- B 接受規範 → §45/§110 是法定要求，「接受」意味著什麼（基本上不成立，這條路通常死）
- C 改空間定義 → 重新檢視這道牆所在的空間用途 / 邊界線位置（地界線可以協商嗎？這道牆其實是內牆嗎？）
- D 跳出找人 → 跳出 MCP 找誰？業主 / 結構技師 / 鄰地主 / 主管機關？
寫完後**只回答這四段**，不要做任何選擇、不要建議「最好的方案」、不要替我決定——光譜在我這端。
✓ 預期觀察
AI **完全沒有呼叫 MCP 工具**（包括 query 類）—— 對應 P8 被動就緒，光譜決策不需要更多資料
AI 寫出四段 A/B/C/D 各自的論述，但**沒選哪個是「最好」**——對應 P11 光譜在設計師端、P13 MCP 不是判定機
PASS AI 對 D 的建議明確標出「不是技術問題，是溝通協調問題」——對應 P12 死局求助更多人FAIL AI 自己選了一個方案說「我建議 A 因為...」——這就是它違規 P11 P13，搶走設計師的決策權FAIL AI 主動呼叫 query_elements / get_wall_info 想多查資料——違反 P8，「光譜決策不靠加資料，靠人做選擇」
COPY 視覺收尾
📋 Copy 光譜決策示範完，請清掉 Step 5 染的 4 道牆 override：
- 53970839、54801079、54267249、52989520
呼叫 clear_element_override 時必須顯式帶 viewId=（Step 0/1 抄下的 1F 平面 ViewId）。
完成後回報：4 次呼叫的 ViewName 都是 1F 平面 → Revit 平面是否回到原本灰色。
✓ 預期觀察
AI 呼叫 clear_element_override 4 次 （4 道牆 × 1 個視圖）
Revit 1F 平面顏色全消失，回到原本灰色
PASS 對應 P7「階段完成點」：限制可見化 → 光譜決策 → 視覺收尾，回到「設計師繼續設計」的狀態
💭 收尾的意義 — slide 6-4 命題收束
整場 Live Demo 走完一輪 slide 6-4 三條路徑：Step 3 = MCP 給 0/1（5 個工具 PASS/FAIL）Step 4 = MCP 給更精細的 0/1（採光比 0.58% vs §41 12.5%）Step 5 = 規範限制視覺化（§45/§110 在哪幾道牆上）Step 6 = 設計師走光譜（A/B/C/D）+ 視覺收尾你頭腦裡留下的不是『AI 告訴我哪裡有問題』，是『我看到了規範限制，我選擇了 A/B/C/D 哪一條』。 這就是 P5/P6 翻轉的意義——AI 揭露限制、人類放大膽追美學。MCP 給 0/1，光譜永遠在你這端。」