跳到主要内容

Sync Packet

状态：基线收束草案 最后更新：2026-05-08 用途：定义项目实践如何向生态层同步重要发现、接口变化、复用机会和潜在风险

1. 本目录定位​

packets/sync/ 是项目向生态层发起低强度回流的入口。

它用于记录项目推进中已经值得生态层知晓、登记、观察或预先吸收的事项，但这些事项暂时还没有达到必须正式裁决、修改基线或强制约束其他项目的程度。

一句话：sync 是“需要被生态层看见并跟踪”的信号，不是“请求生态层立即裁决”的事项。

2. 什么时候用 sync​

以下情况适合使用 sync：

  • 项目实践产生了新的跨项目接口线索，但接口还没有稳定到需要正式定稿；
  • 某个项目发现了可被多个项目复用的能力、数据对象、评估方法、工作流或学习资产候选；
  • 项目实践与当前生态基线存在轻微偏差，但尚未形成明确冲突；
  • 某个风险、边界或用户误解迹象值得生态层提前关注，但暂时还不需要裁决；
  • source/ 或 references/ 中的材料已经部分影响项目判断，需要登记吸收状态；
  • 项目级 current-state.md、CONTEXT.md、PRD、issue 或实验材料发现了可能影响上游事实的趋势；
  • 项目 owner 希望让其他项目 owner 或个人域 Agent 看到某个新事实、新约束或新问题。

3. sync 不是什么​

sync 不是：

  • 项目内部日常状态汇报；
  • 个人任务进度、会议纪要或普通 backlog 更新；
  • 已经需要生态层正式裁决的问题；
  • 直接替代 baseline/、registry/、contexts/、projects/* 或治理文档的更新；
  • 绕过项目 owner、生态 owner 或正式文档评审的快捷通道；
  • 没有影响范围、证据或后续动作的模糊提醒。

如果事项已经要求生态层判断“应该改什么事实、边界或责任”，应转入 ../escalation/README.md。

4. 与 escalation 的区别​

类型目的典型状态结果
sync让生态层知晓、登记、观察、预备吸收有信号，但尚未需要正式裁决进入观察、补充证据、等待后续项目实践
escalation请求生态层正式判断、裁决、更新基线或改变边界已形成冲突、缺口或正式决策需求修改正式文档、记录决策、退回澄清或设置下游约束

判断规则：

  • 如果只是“这件事值得其他项目知道”，用 sync；
  • 如果已经是“当前正式口径不够用，必须有人判断”，用 escalation；
  • 如果 sync 后证据变强、影响变大或冲突变明确，应升级为 escalation；
  • 如果 escalation 被判断证据不足，也可以退回 sync 继续观察。

5. 最小结构​

一份最小 sync 应至少包含：

  • 标题；
  • 日期；
  • 来源项目或来源材料；
  • 触发背景；
  • 新发现 / 新情况；
  • 证据或来源链接；
  • 影响范围；
  • 当前建议；
  • 后续观察点；
  • 是否可能转为 escalation；
  • 需要同步给哪些项目、文档或 owner；
  • 未解决项 / open gaps（必填，参见 §11.A）。

6. 建议模板​

# Sync: <简短标题>

日期：
来源项目 / 材料：
提交人 / 责任人：
当前状态：Draft / Observing / Absorbed / Escalated

## 1. 触发背景

## 2. 新发现 / 新情况

## 3. 证据或来源

## 4. 影响范围

受影响项目：
受影响文档：
受影响接口 / 对象：

## 5. 当前建议

## 6. 后续观察点

## 7. 是否需要转 escalation

## 8. 吸收状态

## 9. 未解决项 / Open Gaps

| 项 | 严重性 | Owner | 缺口具体内容 | 解除条件 |
| --- | --- | --- | --- | --- |
| ... | P0/P1/P2 | ... | 未做 / 未验证 / 外部依赖 / 数据缺失 | 何时何条件下可标 closed |

如果本 sync 不是 closeout 性质（仅信号、登记、观察），可写"无未解决项 / 本 sync 不主张完成判定"。
**严禁仅写"无"或"全部完成"而无证据**。

该模板是最小协作协议，不是固定表单。真实 sync 可以更短，但不应缺少背景、证据、影响范围和后续动作。closeout 性质的 sync 必须填 §9 Open Gaps，参见 §11.A。

7. 当前典型场景​

7.1 Data Horizon / 数据视界 -> FinClaw​

如果 Data Horizon / 数据视界 在实践中发现某类信息感知输出更适合作为共享上游输入标准，可以先发 sync。

例如：

  • 新的信息对象类型；
  • 来源质量评分方式；
  • 结构化事件对象；
  • 下游可消费性问题；
  • 感知输出如何被 FinClaw 使用的反馈。

若该发现要求改变 Data Horizon / 数据视界 -> FinClaw 的生态协同边界，则转 escalation；若只是系统对接设计细节，则应回到项目工程化落地环节处理。

7.2 FinClaw -> AI Trading Matrix​

如果 FinClaw 发现某类认知输出、策略假设、风险约束或执行前检查点可能被 AI Trading Matrix 消费，可以先发 sync。

例如：

  • 新的认知输出对象；
  • Market Cognition Thread 中稳定出现的下游消费字段；
  • 研究 follow-up 形成的行动前检查点；
  • target price、rating、portfolio analysis、backtesting 或 strategy suggestions 的证据边界表达方式。

只要仍停留在认知型决策支持层，可以先 sync。若该事项触及真实账户、订单、资金、链上动作、自动执行或执行系统调用，应转 escalation，并由 AI Trading Matrix 或授权执行链路承接。

7.3 AI Trading Matrix -> Reinforcement Learning Engine​

如果 AI Trading Matrix 在仿真、回测、授权执行或用户反馈中发现某类结果记录可成为反馈对象，可以先发 sync。

例如：

  • 授权 / 拒绝 / 撤销行为；
  • 风控拦截记录；
  • 执行前检查点命中情况；
  • 仿真或回测结果；
  • 可复用的 Outcome / Result Record 或 Feedback Event 候选。

若这些反馈对象将改变 RLE 启动条件、学习资产边界或金融风险治理方式，应转 escalation。

7.4 Reinforcement Learning Engine -> Financial Expert Foundation Model​

如果 RLE 发现某类反馈对象、失败案例、评估样本或学习资产可能进入 FEFM 的长期能力建设，可以先发 sync。

例如：

  • 可复用评估样本；
  • 失败推理案例；
  • 学习资产候选；
  • 任务适配能力缺口；
  • 模型能力反哺前台产品的潜在路径。

若该事项意味着 FEFM 应正式启动训练、微调、样本治理或模型路线决策，应转 escalation。

8. 生态层收到 sync 后的处理方式​

生态层收到 sync 后，可以采取以下动作：

  • 仅登记并观察；
  • 要求来源项目补充证据、例子或影响范围；
  • 标记为某个正式文档的待吸收输入；
  • 同步给相关项目 owner；
  • 建议创建后续 issue、PRD、协同边界记录或 CONTEXT.md 更新；
  • 判断其已经达到 escalation 条件；
  • 判断其不影响生态层，退回项目内处理。

sync 被吸收后，应在原 sync 中标明吸收位置或处理结果。

如果多个 Program Controller 同时产生公共入口、索引、manifest 或发布面更新请求，应按 ../../governance/knowledge-update-closure-protocol.md 分批处理，并在发布前后验证 GitHub、Docusaurus / Pagefind、docs-manifest.json、llms.txt 与线上部署是否一致。

9. 不需要发 sync 的事项​

以下事项通常不需要默认 sync：

  • UI 文案、样式或交互细节；
  • 单项目内部 backlog 排序；
  • 不改变项目边界的工程实现选择；
  • 不影响生态边界的商业化实验；
  • 一次性探索草稿；
  • 已经完全被项目文档吸收且不会影响其他对象的本地事实。

但如果上述事项暴露金融风险、用户误导风险、跨项目接口变化或可复用资产，则仍应发 sync。

10. 当前阶段建议​

当前阶段可先手工维护 sync 文档，不急于抽象完整 schema。

更重要的是形成习惯：

  • 项目实践一旦影响生态级事实，就不要只停留在个人记忆或项目局部文档中；
  • 先用 sync 捕捉信号；
  • 信号变成冲突、决策或边界变化时，再转 escalation；
  • 被正式吸收后，回到对应正式文档更新，并在 sync 中保留追溯链接。

11.A Closeout 类 sync 的强制要求​

任何 sync packet 如果包含以下语言之一：

  • "completed"
  • "closed"
  • "satisfied"
  • "resolved"
  • "addressed"
  • "accepted"（单独使用，不是 accepted-deferred 这种带状态后缀的复合用法）
  • "已完成"
  • "已闭环"
  • "全部解决"
  • "本轮收尾"
  • "收口"

或在 frontmatter status 字段使用上述语义，必须强制填入：

  1. §9 Open Gaps 表格（不允许仅写"无"），列出所有未解决 / 未验证 / 外部依赖 / 数据缺失项；
  2. Reader Test 等级与 evidence 路径：按 ../../governance/reader-testing-protocol.md §4 等级表选定 L0/L1/L2/L3，并附 evidence/reader-tests/<DATE>-<TAG>/ 路径；
  3. 发布闭环边界声明：明确写 "本 closeout 不把 build success / publish smoke 视为内容验收"（FR-008 纠偏内化）；
  4. doc alignment vs project progress 区分：明确写"本 closeout 是 doc alignment / project progress / publish evidence 中的哪一项"（FR-016 纠偏内化）。

不满足 §11.A 任一项的 closeout sync packet 视为 incomplete-closeout，应退回补齐，不得进入 Admin / Controller 的 final state。

判断这条 sync 是否属于 closeout 类，可参考：

信号是否 closeout 类
仅信号、登记、观察、追踪否
标 status: active / draft / observing否
标 status: completed / closed是
标记某 lane / batch 关闭是
标记某验收门通过是
把 FR / acceptance item / batch 改为 satisfied / resolved是
把 audit / review 标为完成是

12. 当前真实 sync​

当前已有真实 sync：