不屬於這篇文章的內容要找出路、不是刪除
論述基礎與限制
一篇 macOS App Container 辨識文章裡有一段 Steam 遊戲辨識的內容，review 時判定「Steam 的儲存機制跟 Container 不同，不屬於這篇」。初始反應是「刪掉這段」，但刪掉會讓讀者排查磁碟時在 Container 文章裡找不到 Steam 的資訊。Steam 段最終留在文章裡（標記為不同機制），同時觸發了建立 content/macos/ 分類的動作——沒有分類時，內容只能留在不精確的位置。適用範圍是教學文章的內容路由，程式碼的 SRP 重構有不同的成本結構（搬方法比搬段落容易）。
核心原則
Review 發現文章裡有不屬於當前主題的段落時，這個段落的存在是一個路由訊號——它在告訴你有一個議題需要被安置，而不是有一段多餘的文字需要被清除。
SRP 違反在文章層面的意義是：這段內容有自己的語意責任，它跟文章主線的責任不同。正確的回應是幫它找到位置——可能是已經存在的另一篇文章、可能是值得新開的文章、也可能是需要新建的分類。刪除是最差的選項，因為這段內容的存在說明作者（或讀者）在某個情境下確實需要這個知識，刪掉只是讓這個需求變成隱性的缺口。
這次的情境
Container 辨識文章裡有一段 Steam 遊戲辨識。Steam 的資料放在 ~/Library/Application Support/，跟 Container（~/Library/Containers/）是不同的儲存機制。從 SRP 的角度，這段不屬於「辨識 Container」這個主題。
三種處理方式的比較：
刪除：Steam 段消失，讀者排查磁碟時在 Container 文章裡找不到 Steam 的資訊，要自己去別處找。文章更純粹了，但讀者的需求沒被滿足。
搬到已有文章：App 聚合佔用報告（app-report）已經涵蓋 Steam，但那篇是工具導向（腳本怎麼用），不是機制導向（Steam 資料放哪、為什麼不能手動刪 common/）。硬塞進去會讓那篇文章也混入不屬於它的內容。
保留 + 標記為不同機制：Steam 段留在文章裡，用段落開頭明確標示「Steam 的儲存機制跟 App Container 不同」，讀者知道這是額外資訊而非 Container 機制的一部分。如果 macOS 遊戲資料管理的議題日後成長到足夠深度，再拆成獨立文章。
這次選了第三種。同時，這個判斷過程揭露了一個更大的問題：macOS 相關文章放在 other/（兜底資料夾）裡沒有自己的分類，導致「幫內容找出路」的選項有限——新文章也只能放 other/，不同主題混在一起。這觸發了建立 content/macos/ 分類的決定（見 #213 分類從內容深度浮現）。
理想做法
Review 發現 SRP 違反時的處理流程：
確認這段內容是否有讀者需求。如果作者當初寫進來，通常有情境上的理由（排查時一起看、概念有對比關係）。確認需求存在後才決定怎麼處理。
找出路，不是刪除。依內容的成熟度和獨立性選擇：
- 已有適合的文章 → 搬過去
- 值得獨立成篇 → 新開文章
- 議題還不夠成熟 → 留在原處、用段落標記區隔主題、加 backlog 備註
- 找不到該去的分類 → 可能缺一個分類（見 #213 分類從內容深度浮現）
多輪審查時把「不屬於」當路由提醒。Reviewer 標記「這段不屬於這篇」時，同時標記「建議的目的地」。只標前者不標後者，修改者容易選最省力的動作（刪除），而不是最正確的動作（路由）。
跟其他原則的關係
→ #246 被多篇當成前提的判斷缺的是住址：本卡的盲區。本卡靠「主題與篇標題不同」判別內容錯置，而共同前提放在前置段時主題對得上、它也確實是本篇的適用性閘門，所以這條檢查不會觸發。差別在缺陷位置——本卡的內容放錯了地方，#246 的內容沒放錯，只是整條軸只寫了一角。
#213 分類從內容深度浮現：找不到出路的內容可能指向一個還不存在的分類。單段內容的路由問題（#212）反覆出現時，往往揭露出多篇文章需要一個共同的分類歸屬（#213）。
#211 複合問題先拆機制再談交互：拆分文章時產生的獨立段落就是需要路由的內容。先用 #211 判斷哪些概念該獨立，拆出來的段落再由本卡的路由流程決定去處。
#44 SSoT：路由的目的之一是讓每個概念只在一個地方深度解釋。搬過去比留兩份好、留兩份比刪掉好。
#154 教材的總結段是內容發散的訊號：#154 處理的是文章尾端冗餘重述（刪或併回正文），本卡處理的是文章中段不屬於當前主題的完整段落（路由到正確位置）。兩者都是 SRP 訊號，但處理方式不同。
判讀徵兆
Reviewer 標記「這段可以刪」時，在動手之前先問一個問題：「這段內容對應的讀者需求在哪裡被滿足？」如果答案是「沒有其他地方」，刪除會製造缺口而非提升品質。