"Naming"
- 行為事件設計
事件命名規範、屬性設計、funnel 定義 — 行為分析的品質取決於事件設計的品質
- 事件命名規範
namespace.action 格式的事件命名、命名一致性的工程價值、和商業方案命名慣例的對應
- 「名義 integration test」的識別與修正
test 名稱含 integration 但核心依賴全用 fake — 如何辨認、為什麼有害、怎麼修正命名和測試策略
- 名義 Integration Test
名稱含 integration 但核心依賴全用 fake 的 test，驗證內部狀態機而非真實服務互動
- Naming 是 iterated artifact：第一個名字幾乎不對、四輪 review 才收斂
命名（變數 / 函式 / 檔名 / slug / API endpoint）幾乎沒有「一次寫對」的可能：第一個名字基於當下狹窄的 context、會在後續 cross-call-site / grep / 重構中暴露錯位。命名的正確設計是 iterated — 寫第一版 → grep-ability 測試 → cross-call-site 一致性 → impl 洩漏 → 重命名。本卡是 #83 在「命名」場景的特化。
- 集合命名用角色、不內嵌數量：「核心七問」的七是成員數的 derivation、加一問就全面失真
「核心七問」「成長六階段」「四大支柱」這類名稱把成員數量烤進名字裡 — 數量是集合當前成員的 derivation、不是集合的語意身分；成員增減時名稱失真、且名稱是被複製最多次的字串、缺陷隨每次引用繁殖。修法：命名只承載角色與層級（核心問題 / 次要問題 / 撞牆階段）、數量讓清單自己呈現。本卡是 #155 的命名端 sibling（#155 修引用端、本卡讓「語意標題是穩定錨」的前提真正成立）、#44 SSoT 在名稱內容的實例、#84 命名檢驗的數量維度。
- 語意錨用單一字串、同義雙名讓引用修復退回人腦對應
引用錨在語意標題之後、語意名稱本身要是單一字串。同一個結構單位有兩個同義名稱（標題寫「決策記錄 + scaffold 建議」、引用寫「決策收斂階段」）時、語意引用的兩個核心收益同時失效：grep 要掃兩套 pattern 才完整（漏配置一個就漏一半引用點）、重排時的引用修復回到人腦對應。是 #155 引用端、#156 命名端之後的第三塊：命名唯一性。