变更协议

回答：谁能改什么、怎么提议、谁评审、如何回写。

1. 变更分级

级别	影响范围	谁能提议	谁评审	必经流程
L0 错别字 / 链接修复	单文件	任何人 / Agent	单人 review	直接 commit
L1 项目级内容更新	projects/<id>/ 内	项目 Controller 或被授权人	1 人 review	PR + 1 approval
L2 commons 新增 / 修订	commons/ 下	任何人 / Agent	1 人 review + frontmatter 校验	PR + 1 approval
L3 生态级变更	ecosystem/	生态发起人或 Controller 联合提案	生态发起人 + 至少 1 名相关项目 Controller	PR + 评审会议纪要
L4 治理协议变更	governance/	任何人 / Agent	生态发起人 + 公示期	PR + ADR + 7 天公示

1.1 跨目录 / 批量变更怎么定级

• 一次改动跨多个目录：取涉及级别中的最高级（例如同时改 projects/finclaw/ 与 commons/，按 L2 走）。
• 同一次 PR 批量 L0（如错别字 sweep）：按触及的最高敏感目录定级；若只改纯文案且未改动语义，仍可按 L0，但必须在 PR 中列出完整路径供 reviewer 抽查。
• 方法论从项目「升格」到 commons/：默认至少 L2；若还触发 ecosystem/ 对象定义变化，则按 L3。

1.2 边界示例

• 改已有 commons 方法论 vs 新增 commons 文档：两者都按 L2。修订已有方法论会影响复用者；新增 commons 文档会扩大公共知识面，不能降为项目级 L1。
• 改 alignment-protocol.md 字段表且影响所有项目：优先按 L4，而不是 L3。理由：文件位于 governance/ 且改变跨项目协议契约；若只是补充不改变字段语义，可在提议中说明为何降为 L3。
• L0 typo sweep 跨多个目录：仍可按 §1.1 的批量 L0 处理，前提是只改错别字 / 链接展示且不改语义，并在提议或 PR 中列完整路径供抽查。

2. 提议格式

每个变更 PR 必须包含：

• 目标：一句话说明要改什么
• 影响范围：列出受影响的文件路径
• 变更级别：L0 / L1 / L2 / L3 / L4
• 证据：相关讨论 / commit / 评测结果 / 现实事件
• 回写位置：对于过程性结论，明确写回事实源的哪个位置

3. Agent 发起变更

Agent 可以发起 L0 / L1 / L2 / L3 / L4 任意级别的提议，但不能自行合并。所有 Agent 提议必须经人 review 才能进入主分支。Agent 发起的提议在 PR 正文标注 proposed-by: agent；若走 §6.1 本地提议文件，在 frontmatter 使用 proposed_by: agent:<agent-id>（与人名并列合法）。

4. 派生物不可直接改

for-agents/ 下任何文件都是派生物，禁止手动修改。唯一例外：for-agents/topics/<topic-id>/agent-pack.yaml（topic 聚合的手写 manifest source，见 for-agents/topics/README.md）。如需调整派生结果，改派生脚本 scripts/derive-agent-pack.mjs 或源 .md 文件，然后重跑派生。

5. 弃用与归档

• 文档要弃用时改 frontmatter status: deprecated，并在文末加 "Replaced-by: "，至少保留 30 天后再考虑物理删除；
• 物理删除需经 L2 评审。

6. 无 GitHub / 无 issue tracker 的本地 fallback

设计目标：参与生态的每个用户不必假设都用 GitHub PR / GitHub Issues / 某个第三方协作平台。本协议在没有任何第三方工具时也要走得通。

承载目录：proposals/（含 inbox/、accepted/、rejected/ 及各自 README）。创建提议前请先读 proposals/README.md。

当 PR / issue 流不可用时，按以下本地 fallback：

6.1 提议（替代 PR）

在本仓库 governance/proposals/inbox/ 下新增一份 .md：

governance/proposals/inbox/YYYY-MM-DD--<slug>.md

frontmatter 至少：

---
proposal_id: YYYY-MM-DD--<slug>
title: <一句话>
level: L0 | L1 | L2 | L3 | L4
proposed_by: <name> | agent:<agent-id>
status: open | accepted | rejected | superseded
target_paths:
  - <path1>
  - <path2>
evidence:
  - <commit / file / url>
expected_reviewers:
  - <role-or-name>
---

正文内含 §2 要求的全部内容。

6.2 评审决定（替代 PR review）

评审人在同一目录追加 YYYY-MM-DD--<slug>.review.md，写明：

• 评审人 / 评审日期 / 结论（approve / changes-requested / reject）
• 评审依据

接受后，提议作者把变更直接合入对应路径，并把 inbox 内的 status 改为 accepted 后移入 governance/proposals/accepted/YYYY/。

6.3 ADR（L4 / 关键决策 / 跨项目共识）

在 ./decisions/ 下新增一份：

governance/decisions/ADR-NNNN--<slug>.md

NNNN 为四位单调递增序号；frontmatter 至少 adr_id / title / status / date / deciders / superseded_by。L4 ADR 必须在文末附 7 天公示窗口的 start / end 时间。

6.4 命名与路径硬约束

• inbox 文件名必须以 YYYY-MM-DD-- 开头，便于时间排序与机器可读；
• ADR 序号严禁回收（即使 superseded 也保留序号记录）；
• proposals/inbox/ 是单向流入（提议）、proposals/accepted/ 是单向流出（已合入）、proposals/rejected/ 保留拒绝理由作为决策证据。

7. 第三方工具集成下的变更流程

详见 tooling-integration.md。即使集成了第三方工具，本协议规定的最小流程（§1 分级、§2 提议格式、§6 本地 fallback 的命名规则）仍然成立——第三方工具是加速器，不是替代品。