范围外知识库（Out-of-Scope Knowledge Base）
仓库中的.out-of-scope/目录存储被拒绝的功能请求的持久记录。它有两个用途：
- 机构记忆—— 功能为何被拒绝，使问题关闭后推理不会丢失
- 去重—— 当新问题与先前的拒绝匹配时，技能可以呈现先前的决定，而不是重新争论
目录结构
.out-of-scope/ ├── dark-mode.md ├── plugin-system.md └── graphql-api.md每个概念一个文件，而不是每个问题一个文件。请求相同内容的多个问题归入一个文件。
文件格式
文件应以轻松、可读的风格编写——更像一份简短的设计文档，而不是数据库条目。使用段落、代码示例和实例，使推理对首次遇到它的人清晰有用。
# 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”
### 文件命名 为概念使用简短、描述性的 kebab-case 名称：`dark-mode.md`、`plugin-system.md`、`graphql-api.md`。名称应足够可识别，使浏览目录的人无需打开文件就能理解被拒绝的是什么。 ### 撰写理由 理由应实质性——不是"我们不想要这个"，而是为什么。好的理由会引用： - 项目范围或理念（"本项目专注于 X；主题化是下游关注点"） - 技术约束（"支持这将需要 Y，这与我们的 Z 架构冲突"） - 战略决策（"我们选择使用 A 而不是 B，因为……"） 理由应是持久的。避免引用临时情况（"我们现在太忙了"）——那些不是真正的拒绝，而是推迟。 ## 何时检查 `.out-of-scope/` 在分诊期间（步骤 1：收集上下文），读取 `.out-of-scope/` 中的所有文件。评估新问题时： - 检查请求是否与现有的范围外概念匹配 - 匹配按概念相似性，而非关键词——"night theme"（夜间主题）匹配 `dark-mode.md` - 如果有匹配，向维护者呈现："这类似于 `.out-of-scope/dark-mode.md` —— 我们之前拒绝过这个，因为[原因]。您仍然持同样看法吗？" 维护者可能： - **确认** —— 新问题被添加到现有文件的"Prior requests"（先前请求）列表中，然后关闭 - **重新考虑** —— 范围外文件被删除或更新，问题按正常分诊流程进行 - **不同意** —— 问题相关但不同，按正常分诊流程进行 ## 何时写入 `.out-of-scope/` 仅当**增强**（非缺陷）作为 `wontfix` *被拒绝*时。这同样适用于增强 PR 和问题——被拒绝的 PR 记录在这里，使相同的请求不会作为全新代码再次出现。 当某物因**已实现**而关闭为 `wontfix` 时，**不要**写入这里。那是已构建的功能，而非被拒绝的功能；记录它会用虚假的拒绝污染去重检查。相反，关闭评论应指出该功能已经存在的位置。 流程： 1. 维护者决定功能请求超出范围 2. 检查是否已存在匹配的 `.out-of-scope/` 文件 3. 如果存在：将新问题附加到"Prior requests"列表 4. 如果不存在：创建一个新文件，包含概念名称、决定、理由和第一个先前请求 5. 在问题上发布评论解释决定，并提及 `.out-of-scope/` 文件 6. 使用 `wontfix` 标签关闭问题 ## 更新或删除范围外文件 如果维护者改变了对先前被拒绝概念的看法： - 删除 `.out-of-scope/` 文件 - 技能不需要重新打开旧问题——它们是历史记录 - 触发重新考虑的新问题按正常分诊流程进行
