架构分层设计：四层模型

本架构旨在将同步系统的数据容器、同步逻辑、执行层与编排流程完全解耦，提供极简且类型安全的开发体验。

1. 架构概览

系统分为四层，依赖关系严格从上到下：

本层不包含业务逻辑，仅定义数据契约。

SyncNode[T]: 核心状态机容器。
- origin_data: 原始数据（对应 data_id）。
- data: 计算后的最新目标数据。
- data_id: 业务主键ID。加载时必定有值，CREATE 节点初始为空字符串 ""（布尔值为 False，可通过校验）。
- action: 同步意图 (NONE, CREATE, UPDATE, DELETE)。
- status: 执行状态 (PENDING, IN_PROGRESS, SUCCESS, FAILED, SKIPPED, PRECONDITION_FAILED)。
  - 详见状态定义规范 § 5.A
- binding_status: 绑定状态 (UNCHECKED, NORMAL, MISSING, DEPENDENCY_ERROR, ABNORMAL, WARNING)。
  - 详见状态定义规范 § 1
- error: 异常详情。
DataCollection: 节点的集合，提供类型安全的查询和过滤方法。
BindingManager:
- ID 映射: 维护 local_node_id <-> remote_node_id 的双向映射。
- 绑定键: 使用 node_id 作为绑定记录的键，一致不变。CREATE 成功后只更新节点的 data_id，绑定记录不变。
- 持久化: 将映射关系持久化到存储（如 JSON/数据库）。
Enums: SyncAction, SyncStatus, BindingStatus 等。

核心业务逻辑层。通过实现 SyncStrategy 接口来定义特定实体的同步逻辑。

SyncStrategy[T] 接口:
- bind():
  - 职责：判定 binding_status (NORMAL/MISSING/ABNORMAL/WARNING/DEPENDENCY_ERROR)
  - 详见状态定义规范 § 1-3
- create():
  - 职责：处理孤儿节点（MISSING），在对方侧创建新节点并设置 action=CREATE
  - ID 替换: 创建新节点时，复制数据并将依赖字段的本地 ID 替换为远程 ID
  - 内联检查: 通过 IDResolver.resolve_and_validate() 验证依赖 ID 解析
  - 详见状态定义规范 § 4.C
- update():
  - 职责：处理差异节点（NORMAL 且有 diff），设置 action=UPDATE
  - ID 替换: 准备更新数据时，替换数据中的依赖 ID
  - 内联检查: 验证目标节点 data_id 完整性，失败则设置 PRECONDITION_FAILED
  - FAILED 保护: 自动跳过 status=FAILED 的节点
  - 详见状态定义规范 § 4.A

作为各个后端的适配器，负责数据加载与持久化。

最高层级，负责流程编排。

职责:
- 显式顺序: 直接在代码中按顺序调用同步逻辑（例如：先同步项目，再同步合同）。
- 故障传播: 若前置实体某节点同步失败（FAILED），编排器在处理后续依赖节点时可将其标记为 DEPENDENCY_ERROR。
- 生命周期管理: 初始化 BindingManager 和 DataCollection，同步结束后调用持久化方法。

为了解决本地数据引用本地 ID 与远程数据引用远程 ID 的冲突，系统采用以下映射逻辑：

注意: ID 替换在 Strategy 的 create/update 阶段完成，DataSource 只负责盲目执行已准备好的数据。