流水线自感知上报（atlas report）

“遇到过不去的规则，不许偷偷把它注释掉。”

一套在真实工程里被反复使用的流水线，一定会遇到规则与业务正面冲突的时刻。此时模型有三种选择：静默绕过、偷偷放宽规则、假装完成 —— 三者都会让规则体系在几轮之内烂掉。Atlas 给出的第四条路是：结构化提炼现场，自动上报到云端设计池。

1. 它解决的是什么

绝大多数门禁体系的失效方式不是「规则写错了」，而是规则遇到例外时被就地静默掉：注释一行、加个 --no-verify、把 FAIL 降级成 WARN。事后没人知道为什么这条规则变成了空文。

Atlas 的处置是把这件事变成显式产物：冲突被记成结构化记录，进云端池排队、定案、再回填契约 —— 规则只会变准，不会变空。

2. 四类触发场景

不只是异常崩溃，更多是设计冲突：

类别	场景
结构性冲突	业务形态完全合情合理（长业务累加链测试、特殊合法路由嵌套），但既有规则或提取器发生机械性冲突
人机体感别扭	某流程导致用户反复重复操作、产生决策疲劳，或提示词诱导模型与人类来回扯皮
底层假设破产	底层依赖工具（AST 解析器 / 代码图谱 / 浏览器运行器）在真实环境下的语义与既有契约假设不符
用户显式纠偏	用户在会话中明确指出「这里的流程 / 设计 / 规则不合理」

3. Agent 的自动执行协议

结构化提炼三要素：业务真实背景 / 冲突与设计不合理本体 / 建议解耦方向与备选方案；
调用上报命令（下一节的 atlas report）；
向用户说明已沉淀现场，并给出当前阶段的最优临时推进方案 —— 既不停工，也不假装没有冲突。

4. 命令行

bash

atlas report \
  --title "长业务累加链与每用例播种的结构性冲突" \
  --kind design-conflict \
  --conflict "累加链用例在第 2 步被运行期播种重置抹掉前置数据" \
  --context "混音导出链：创建草稿 → 录制 → 降噪 → 导出" \
  --proposal "声明与发射解耦：seed 行只参与静态对账，不发射运行期重置" \
  --evidence "<终端报错 / 用例 ID / diff 片段>"

参数	必填	说明
`--title`	✅	问题简述标题
`--conflict`	✅	冲突本体或设计缺陷详细描述
`--kind`	—	问题类别闭集，缺省 `design-conflict`
`--context` / `--proposal` / `--evidence`	—	业务背景 / 建议方案与权衡 / 客观报错输出

--kind 闭集：design-conflict（设计冲突）、rule-friction（规则摩擦）、tool-semantic（工具语义与假设不符）、bug（缺陷）。

直接调脚本亦可：python3 .atlas/scripts/atlas_report.py --title "..." --conflict "..."。凭据依次从 ATLAS_REPORT_TOKEN / GITHUB_TOKEN / GH_TOKEN / git credential 探测，纯标准库、零外部依赖。

5. 从云端池回到契约

上报不是终点，闭环才是：

text

Agent 感知冲突 ──► atlas report ──► 云端设计池（GitHub Issues，标签 pipeline-rfc）
                        │
                        ▼
              架构师集中定案、排期、升级契约
                        │
                        ▼

云端设计池：所有上报进同一个中心池，架构师一眼看到跨项目的同根问题；
定案产物回填契约：结论落成契约正文 + 出厂测试（含变异钉子），下一次同类冲突会被机器直接判掉；

流水线自感知上报（atlas report） ​

1. 它解决的是什么 ​

2. 四类触发场景 ​

3. Agent 的自动执行协议 ​

4. 命令行 ​

5. 从云端池回到契约 ​