流程圖
這個設定屬於誰
先問 ownership，再決定 scope。不要先改值，後補理由。
講義入口
圖像講義入口
這一集的閱讀節奏先看流程圖，再看 scope 腦圖。先知道怎麼判斷， 再回頭讀文字會快很多。
Lecture Note
正文講義
Settings 這一集的講義應該直接教你怎麼判斷，不應該只是節目頁的整理版。
這一集真正要解的是 ownership
settings 看起來像很小的事，小到很多人會覺得先改了再說。可是真正讓 repo 開始混亂的，通常不是值本身，而是你根本還沒搞清楚這個值到底屬於誰。只要 owner 沒分清楚，shared config 就會變脆，local experiment 也會開始外溢。
所以這一集不要先背四個 scope。先記住一件事：settings 不是在回答「可不可以改」，而是在回答「該由誰擁有」。順序錯了，後面全部都會錯。
一句話定義
`user` 是個人的跨 repo 預設，`project` 是 repo 共識，`local` 是機器或暫時 override，`managed` 是組織底線。這四層不是四種方便選項，而是四種責任邊界。
也因為它是責任邊界，所以同一個值放在不同 scope，意義完全不一樣。這也是為什麼很多設定明明都叫同一個名字，實際上卻不該落在同一個地方。
四個 scope 的實際判斷法
如果這個設定是你個人跨專案都想保留的工作習慣，那通常是 `user`。如果這個設定換成另一台機器、另一個同事也應該一樣，而且它應該成為 repo 的起始值，那通常是 `project`。如果只是這台機器、這次排錯、這個短期實驗才需要，那是 `local`。如果這已經是公司底線，不應該再讓專案各自改，那就是 `managed`。
這個判斷法看起來很簡單，但非常實用。因為它逼你先找 owner，而不是只看當下哪裡改起來最方便。
最常見的錯誤
- 把 local override commit 進 shared config。 當下很方便，但下一個人看到時就會以為那是正式做法。
- 同一個設定重複出現在多層 scope。 看起來彈性很高，實際上驗收和除錯成本暴增。
- 把個人偏好悄悄升級成團隊標準。 沒經過明確決策，共識就會藏在某個人的機器裡。
settings 做得到什麼，做不到什麼
settings 很重要，但它不是全部治理。它能定義配置放哪裡、誰共享、誰本機 override。它做不到的是：取代政策寫作、讓 local hack 自動變安全、或者讓 review 消失。只要把 settings 想成「配置」而不是「治理總和」，很多誤會就會少很多。
團隊落地時怎麼做
Research 先確認官方語意，Architecture 決定 file taxonomy 與 write boundary，Content 把判斷規則寫成大家看得懂的版本，Instructor 把語氣穩住，Distribution 再把公開頁、講義和音檔全部對齊。這樣 settings 才不會只是「哪裡可以改」，而是能回到「誰負責、誰能改、改了之後會影響誰」。
Episode Promise
這一集要解的是責任，不是選單
大部分設定混亂，不是因為值本身太複雜，而是因為大家把不同責任層 塞進同一個地方。
One-Sentence Model
scope 先決定誰說了算
`user` 是個人預設，`project` 是 repo 共識，`local` 是機器或暫時測試， `managed` 是組織政策。
What Changes
從「改得到」切換成「該不該改」
這一集不是教你把設定放滿，而是教你在動手前先看 ownership， 讓 shared config 和 local override 不再互相打架。
Scope Matrix
四個 scope 的分工
這裡的重點是把責任切清楚。每一格都只有一件事，別把它們混成一個 「反正都可以設」的抽屜。
個人預設
適合放跨專案都會成立的偏好。這是你自己的起始值，不是團隊共識。
repo 共識
適合放整個 repo 都應該遵守的設定。只要會影響別人，就不要留在個人機器裡。
機器或臨時 override
適合實驗、排錯、臨時調整。它應該幫你做事，但不該污染共享設定。
組織政策上限
適合放 org-level policy。這一層不是方便，而是要保證底線一致。
Takeaways
三個重點
這三句是整集最適合拿來交接與複習的版本。
先問 owner
設定不是先看值，而是先看責任歸屬。
shared 和 local 要分開
只要是團隊需要看到的東西，就不要悄悄藏在 local。
override 只做 override
temporary experiment 可以在 local 解決，但不要把臨時值誤寫成永久規範。
Boundaries
每個 scope 的邊界
如果你把 scope 想成四個不同的責任盒子，很多設定爭議會直接少一半。
User
可以放個人習慣，但不要拿來取代 repo policy。
Project
可以放團隊共識，但不要把臨時實驗寫死進來。
Local
可以快速調整，但它的任務不是代表團隊。
Managed
可以定底線，但不要拿來裝成個人偏好。
Minimum Viable Template
最小可行檔案樹
這一集的目的不是堆出更多設定，而是讓團隊知道每一層該落在哪裡。
ai-edu-media/
CLAUDE.md
.claude/
settings.json
settings.local.json
rules/
architecture/
file-taxonomy.md
research/
topic-notes/
settings-and-permissions.md
content/episodes/ep03/
podcast/
distribution/
website/Why It Matters
如果你接手一個設定混亂的 repo
先把 shared defaults 和 local overrides 分開，接著才談更細的權限或自動化。
First Pass
先看哪一層最常被誤用
如果大家都在 local 改同一個值，通常代表 project 層缺了共識文件。
Second Pass
再決定要不要升級成 policy
只有當它真的需要跨人、跨機器、跨時間成立，才值得進更高層的配置。
Closer
這一集的收尾
你現在應該可以很快判斷：這個設定是個人偏好、repo 共識、臨時 override， 還是 org policy。