跳到主要内容

冲突解决与升级路径

设计原则：升级路径必须能在没有任何第三方工具的前提下走完。

1. 冲突分类​

类型例子默认裁决路径
术语冲突同一概念在两个项目用了不同名字ecosystem/glossary.md 维护人裁决
事实源冲突两份文档同一字段写得不同按 change-protocol.md 评审级别决定谁优先
优先级冲突两个项目都要某个稀缺资源项目 Controller 协商 → 不成则升级到生态发起人
角色边界冲突某个 Agent 越权改了不该改的立即 revert，按 roles-and-responsibilities.md 重新校准权限
流程冲突协议本身存在歧义起 ADR，按 L4 变更流程修订

2. 升级阶梯​

任何一级都可以跳级到第 4 步，前提是发起人在 PR / ADR 中说明跳级理由。

3. Agent 触发升级​

Agent 在执行中遇到歧义、权限不足、上下文缺失时，必须主动产出 escalation packet（见 §4 字段约定）并写入 §5 规定的位置。

4. Escalation Packet 字段约定​

escalation_id 与 task-packet / handoff-anchor 使用同一命名空间风格：必须带项目、版本、类型、日期和短 slug，便于机器排序与跨仓追溯。

<project>.<version>.esc-YYYYMMDD-<slug>
  • <project>：对象 id，如 finclaw、data-horizon、governance
  • <version>：相关项目版本，如 v1；治理级可用 v0
  • <slug>：小写短横线，描述触发原因

示例：finclaw.v1.esc-20260518-controller-inbox-missing。

---
escalation_id: finclaw.v1.esc-20260518-<short-slug>
triggered_by: <agent-id> | <name>
trigger_reason: <一句话>
context:
  source_paths:
    - <path>
  related_packet: <packet_id-or-null>
  related_anchor: <anchor_id-or-null>
attempted_resolutions:
  - <一句话 + 结果>
recommended_escalation_level: 2 | 3 | 4   # 对应 §2 阶梯
expected_response_window: <e.g. 24h / 7d>
blocking: true | false                     # 是否阻塞当前 packet
---

5. Escalation 落地位置（无 issue tracker 时的本地 fallback）​

项目 Controller 有 inbox（推荐）：

projects/<id>/execution/<version>/inbox/YYYY-MM-DD--<slug>.md

项目 Controller 可在对应工程仓或项目执行目录维护 inbox；命名规则与升级流程在本协议中定义。

跨项目 / 治理级 escalation：

governance/proposals/inbox/YYYY-MM-DD--<slug>.md           # 走 change-protocol §6.1
governance/decisions/ADR-NNNN--<slug>.md                   # 升到 §2 阶梯第 4 级

Agent 强制要求：escalation packet 必须落到磁盘（不可仅在对话流里说），文件路径写入下一次回写的 commit message 或 evidence_pointer。

6. 不接受的升级方式​

  • 仅口头讨论 / 私聊达成共识 ❌（必须有可追溯的 PR / commit / ADR）
  • 直接修改事实源跳过 change-protocol.md ❌
  • 用第三方工具做出决定但不在本仓库留下证据 ❌
  • 仅在 chat / 对话上下文里说 escalation 但未落盘 ❌（违反 §5）