流水线 RFC 协同机制

“凡改流水线，必留取证、必记决策、必带测试。”

当你在真实业务项目中遇到与 Atlas 自身流水线设计相关的问题（门禁误报、契约盲区、规则不合理、新特性诉求）时，请遵循三位一体 PR 协同机制。

---

协同四步法

  1. 发现流水线缺陷与客观报错
          │
          ▼
  2. 基于模板记录问题取证与决策权衡
     cp proposals/TEMPLATE.md proposals/RFC-YYYYMMDD-01-主题.md
          │
          ▼
  3. 修改代码并追加测试钉子 (tests/)
          │
          ▼
  4. 发起 PR ──► 维护者一眼看清前因后果，一键审查合并！

---

为什么必须三位一体？

在传统的开源项目协作中，常见的低效痛点是：

1. 只提代码，不记原因：发一个 PR 改了两行正则，过两个月谁也想不起为什么改，后来人一重构又改回去了；
2. 只发抱怨，不带取证：提个 Issue 说“你们的校验器报错了”，没有环境、没有日志、无法复现；
3. 缺少决策权衡：改动只图自己省事，却暗中破坏了其他项目的兼容性。

Atlas 要求所有对流水线本体的改动，必须将**“问题记录 + 决策记录 + 代码/测试改动”作为一个 PR 一并提交**。

---

提案模板详解 (proposals/TEMPLATE.md)

每个提案包含四个核心章节：

1. 现象与取证 (The Problem & Evidence)：
   • 触发场景与业务背景；
   • 终端报错输出截取、Git Diff 或最小可复现的代码片段；
2. 决策与权衡 (The Decision & Trade-offs)：
   • 为什么选择当前方案；
   • 否决了哪些备选方案（为什么不能简单把报错降级为跳过）；
   • 潜在的代价与兼容性影响；
3. 改动面清单 (Affected Surface)：
   • 涉及的契约、校验器、适配器；
4. 验证与测试结果 (Verification)：
   • 本地 pytest tests/ 与 atlas check 输出。

---

维护者的一键审批体验

当维护者打开你的 PR 时，通过查看 proposals/ 中的提案记录，可以一秒看懂：

• 前因后果：你在什么场景下报了什么错；
• 为什么这么解：否定了哪些不合理的方案；
• 代码与测试：改动是否克制，全套出厂测试（pytest tests/）是否全绿。

审批通过后一键合入主干，所有使用 Atlas 的团队即刻受惠！