Out-of-Scope 知识库

repo 中的 .out-of-scope/ 目录存储被拒绝功能请求的持久记录。两个用途：

1. 机构记忆 — 功能为何被拒绝，issue close 后 reasoning 不丢失
2. 去重 — 新 issue 匹配 prior rejection 时，skill 可 surface 先前决策而非 re-litigate

目录结构

.out-of-scope/
├── dark-mode.md
├── plugin-system.md
└── graphql-api.md

每个 concept 一个文件，非每个 issue。多个 issue 请求同一事物归在一个文件下。

文件格式

文件应以 relaxed、可读风格撰写——更像短设计文档而非 database entry。用段落、code sample、示例使 reasoning 对首次遇到者 clear 且 useful。

# Dark Mode

This project does not support dark mode or user-facing theming.

## Why this is out of scope

The rendering pipeline assumes a single color palette defined in
`ThemeConfig`. Supporting multiple themes would require:

- A theme context provider wrapping the entire component tree
- Per-component theme-aware style resolution
- A persistence layer for user theme preferences

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;
}

Prior requests

• 42 — "Add dark mode support"

• 87 — "Night theme for accessibility"

• 134 — "Dark theme option"

  
  ```

文件命名

concept 用简短 descriptive kebab-case 名：dark-mode.md、plugin-system.md、graphql-api.md。名应 recognizable，浏览目录时不打开文件也能懂被拒内容。

撰写 reason

reason 应 substantive——不是 "we don't want this" 而是 why。好 reason 引用：

• 项目 scope 或哲学（"This project focuses on X; theming is a downstream concern"）
• 技术约束（"Supporting this would require Y, which conflicts with our Z architecture"）
• 战略决策（"We chose to use A instead of B because..."）

reason 应 durable。避免引用 temporary 情况（"we're too busy right now"）——那些不是 real rejection，是 deferral。

何时检查 .out-of-scope/

分诊期间（Step 1: Gather context），读 .out-of-scope/ 中所有文件。评估新 issue 时：

• 检查请求是否匹配 existing out-of-scope concept
• 匹配靠 concept similarity，非 keyword——"night theme" 匹配 dark-mode.md
• 若匹配，surface 给 maintainer：「这与 .out-of-scope/dark-mode.md 类似——我们之前因 [reason] 拒绝。你还这样认为吗？」

maintainer 可能：

• Confirm — 新 issue 加入 existing 文件 "Prior requests" 列表，然后 close
• Reconsider — 删除或更新 out-of-scope 文件，issue 走 normal triage
• Disagree — issue 相关但 distinct，走 normal triage

何时写入 .out-of-scope/

仅当 enhancement（非 bug）以 wontfix 拒绝时。流程：

1. maintainer 决定功能请求 out of scope
2. 检查是否已有 matching .out-of-scope/ 文件
3. 若有：将新 issue append 到 "Prior requests"
4. 若无：用 concept 名、decision、reason、首个 prior request 创建新文件
5. 在 issue 上 post comment 解释 decision 并提及 .out-of-scope/ 文件
6. 用 wontfix label close issue

更新或移除 out-of-scope 文件

若 maintainer 改变对先前 rejected concept 的想法：

• 删除 .out-of-scope/ 文件
• skill 无需 reopen 旧 issue——它们是 historical record
• 触发 reconsideration 的新 issue 走 normal triage