The .out-of-scope/ directory in a repo stores persistent records of rejected feature requests. It serves two purposes:
repo 中的 .out-of-scope/ 目錄儲存被拒絕功能請求的持久記錄。它有兩個用途：
.out-of-scope/
├── dark-mode.md
├── plugin-system.md
└── graphql-api.md
.out-of-scope/
├── dark-mode.md
├── plugin-system.md
└── graphql-api.md
One file per concept, not per issue. Multiple issues requesting the same thing are grouped under one file.
每個概念一個檔案，而不是每個 issue 一個。請求相同內容的多個 issues 會歸入同一個檔案。
The file should be written in a relaxed, readable style, more like a short design document than a database entry. Use paragraphs, code samples, and examples to make the reasoning clear and useful to someone encountering it for the first time.
檔案應以輕鬆、可讀的風格撰寫——比較像一份簡短的設計文件，而不是資料庫條目。用段落、程式碼範例與實例讓推理清楚明瞭，對第一次接觸它的人有用。
```markdown
This project does not support dark mode or user-facing theming.
The rendering pipeline assumes a single color palette defined in
ThemeConfig. Supporting multiple themes would require:
This is a significant architectural change that doesn't align with the project's focus on content authoring. Theming is a concern for downstream consumers who embed or redistribute the output.
```ts
```markdown
This project does not support dark mode or user-facing theming.
The rendering pipeline assumes a single color palette defined in
ThemeConfig. Supporting multiple themes would require:
This is a significant architectural change that doesn't align with the project's focus on content authoring. Theming is a concern for downstream consumers who embed or redistribute the output.
```ts
// The current ThemeConfig interface is not designed for runtime switching: interface ThemeConfig { colors: ColorPalette; // single palette, resolved at build time fonts: FontStack; } ```
// The current ThemeConfig interface is not designed for runtime switching: interface ThemeConfig { colors: ColorPalette; // single palette, resolved at build time fonts: FontStack; } ```
Use a short, descriptive kebab-case name for the concept: dark-mode.md, plugin-system.md, graphql-api.md. The name should be recognizable enough that someone browsing the directory understands what was rejected without opening the file.
為概念使用簡短、具描述性的 kebab-case 名稱：dark-mode.md、plugin-system.md、graphql-api.md。名稱要夠容易辨識，讓瀏覽目錄的人不需要開啟檔案就能理解什麼被拒絕了。
The reason should be substantive: not "we don't want this" but why. Good reasons reference:
理由應該有實質內容——不是「我們不想要這個」，而是為什麼。好的理由會引用：
The reason should be durable. Avoid referencing temporary circumstances ("we're too busy right now"); those aren't real rejections, they're deferrals.
理由應該耐用。避免引用暫時的情況（「我們現在太忙了」）——那些不是真正的拒絕，而是延後。
.out-of-scope/.out-of-scope/During triage (Step 1: Gather context), read all files in .out-of-scope/. When evaluating a new issue:
在分診期間（第 1 步：收集上下文），讀取 .out-of-scope/ 中的所有檔案。評估新 issue 時：
dark-mode.md.out-of-scope/dark-mode.md. We rejected this before because [reason]. Do you still feel the same way?"dark-mode.md.out-of-scope/dark-mode.md——我們先前因為 [reason] 拒絕過這個。你現在還是一樣的看法嗎？」The maintainer may:
維護者可以：
.out-of-scope/.out-of-scope/Only when an enhancement (not a bug) is rejected as wontfix. This applies to enhancement PRs exactly as it does to issues: a rejected PR is recorded here so the same request doesn't return as fresh code.
只有當enhancement（而非 bug）以 wontfix 被拒絕時。這對 enhancement PR 的適用，與對 issues 完全相同——被拒絕的 PR 會記錄在這裡，這樣相同的請求不會以新程式碼的形式再次出現。
Do not write here when something is closed as wontfix because it's already implemented. That's a built feature, not a rejected one; recording it would poison the dedup checks with false rejections. Instead, the closing comment points to where the feature already lives.
當某個東西因為已實作而以 wontfix 關閉時，不要寫在這裡。那是已建置的功能，而不是被拒絕的；記錄它會以虛假的拒絕污染去重複檢查。相反地，關閉評論會指向該功能已經存在的地方。
The flow:
流程：
.out-of-scope/ file already exists.out-of-scope/ filewontfix label.out-of-scope/ 檔案.out-of-scope/ 檔案wontfix 標籤關閉 issueIf the maintainer changes their mind about a previously rejected concept:
如果維護者對先前拒絕的概念改變了想法：
.out-of-scope/ file.out-of-scope/ 檔案