# 设计决策记录（Design Decisions）

这里记录 Light 在演进中做出的**边界级决策**——尤其是"要不要从某个外部系统/论文借鉴某个机制""某个能力做到哪为止"这类一旦定下、后续就该一致遵守的判断。

## 为什么要写下来

技能包是多人、多轮、跨会话演进的。如果"为什么当初这么定"只存在某次对话里，下一次遇到同类问题就会重新拍脑袋，甚至和上次相反。把触碰边界的决策写成一页文档，后续遇到相似问题时先翻这里，保证同一条边界被一致地应用，而不是每次即兴发挥。

这个做法本身是从 ARS（Academic Research Skills，CC BY-NC，仅借鉴其"边界写成文档"的思路、未复制其任何文本）的 design-lesson 实践中学来的，并按 Light 自己的定位重写。

## 什么样的决策值得记

- 是否从外部系统/论文借鉴某机制，以及借到什么程度
- 某个技能的能力边界（做什么、明确不做什么）
- 两种科研哲学冲突时，Light 选哪一边、为什么
- 一个会影响多个技能的全局约定的由来

不值得记的：具体 bug 修复、措辞调整、一次性的实现细节——那些进 CHANGELOG 或代码注释即可。

## 怎么写

每个决策一个文件，命名 `YYYY-MM-DD-短标题.md`，包含：
- **背景**：遇到什么问题 / 在看什么外部系统
- **决策**：定了什么
- **理由**：为什么这么定，拒绝的备选是什么
- **影响范围**：牵涉哪些技能 / 约定
- **复核问题**：下次遇到同类问题时，用一句话判据来对齐（例如"谁掌握下一步研究状态的转移权？"）

## 已记录的决策

| 日期 | 决策 | 影响 |
|------|------|------|
| 2026-06-08 | [向 ARS 学习的取舍：学诚实工程，不照搬其拒绝边界](2026-06-08-ars-borrow-boundary.md) | m03 / m04 / 全局定位 |
| 2026-06-08 | [编排器的引入与"分级编排"边界](2026-06-08-orchestrator-tiered.md) | light-orchestrator / ROUTER / memory-pm |
| 2026-06-08 | [PRISMA 与文风校准：做成可执行脚本而非纯文档](2026-06-08-prisma-style-scripts.md) | literature-search / paper-polishing |
| 2026-06-08 | [向 nature-skills 学习：图表诚实性与深层论证审查](2026-06-08-nature-skills-borrow.md) | figure-drawing / paper-polishing |
