jcode 跨设备 Worktree 与构建同步让多台机器共用一个逻辑工作树的完整设计解析【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode本文基于 jcode 仓库中仍在设计阶段的提案文档 CROSS_DEVICE_WORKTREE_SYNC.md深入拆解让多台开发机如 MacBook 与 Linux 笔记本像单一逻辑 worktree 单一构建通道一样协同工作的完整技术方案从架构无关的版本标识、基于 git 管道命令的 worktree 原子快照、version beacon 广播与回声抑制到分三阶段B/A/C的落地路径。读完本文你将掌握跨设备构建对齐build parity的原理与判定依据以及如何利用仓库中已存在的 gateway、jade relay、auto-reload 等基础设施以最小的增量改动实现多机开发环境的一致性。需要先明确的前提该方案当前状态为 Proposed (design only, not implemented)即文档已完成设计与现有代码基块的核对verified in code但功能本身尚未实现。本文所有将要发生的描述均指提案设计而非仓库当前行为。问题定义单机多 Agent 与多机开发的鸿沟在单台机器上jcode 的selfdev build reload 流程意味着每次构建后本机所有 jcode 实例都会运行新版本同时多个 Agent 可以共享同一个 worktree因为服务端会中介mediate文件编辑并跟踪冲突——这正是 crates/jcode-base 中FileTouchService与file_activity.rs所承担的编辑中介 冲突追踪职责。一旦开发工作分散到多台机器上述两个性质同时失效Linux 笔记本上执行的selfdev build不会更新 MacBook 上运行的 jcode 版本反之亦然由于不存在共享 worktree一台机器上的改动对另一台机器上的 Agent/会话完全不可见直到手动 push/pull。提案目标让多台机器表现得像一个逻辑 worktree 一个逻辑构建通道就像单机上多个 Agent 已经共享一个 worktree 那样。现有基础设施设计中可直接复用的六个构建块提案文档的一个显著优点是它没有凭空设计新机制而是逐一验证了仓库中已存在的构件verified in code。下表完整继承原文档的构件清单并结合源码逐一说明构建块所在位置为什么重要架构无关的版本标识source_state.rs 中的SourceState::version_label与fingerprintFingerprint 对完整 commit hash status diff --binary HEAD 未跟踪文件内容做哈希。两台机器上相同的源码树会产出相同的 label尽管各架构的二进制不同。更新二进制自动 reloadserver/util.rs 中的server_has_newer_binary、reload_exec_target基于 mtime 的构建通道扫描。同端触发的本地构建只要发布到builds/current即可触发既有 reload 流程零改动。Pull → build → install → exec 流水线session_rebuild.rs已实现接收端流水线的形状hot_rebuild、spawn_background_session_rebuild。网络门户同一协议jcode-base/src/gateway.rs:7643 端口的 WS 纯 HTTP远端客户端与 Unix socket 客户端使用完全相同的 newline-JSON 协议。纯 HTTP 处理器/pair、/health是放置/peer/*端点的自然位置。NAT 友好的设备事件总线jade_relay.rs设备 ID、心跳、长轮询命令事件即使机器间无法直连也能工作。服务端工具执行服务器架构本身工具bash、edit运行在 server 进程中远端客户端 attach 到另一台机器的 server 后可完整获得多 Agent 单 worktree行为包括冲突告警。远端构建先例remote_build.shrsync ssh 同步回传模式。版本标识的源码级实现fingerprint 如何做到架构无关跨设备等价校验是整个方案的第一块基石。查看 crates/jcode-build-support/src/source_state.rs 中current_source_state的实现可以看到 fingerprint 的计算完全基于源码内容与机器架构无关取短/完整 git hashgit rev-parse --short HEAD/git rev-parse HEAD取git status --porcelainv1 -z --untracked-filesall的原始字节取git diff --binary HEAD的原始字节二进制 diff可覆盖任何文件变更取git ls-files --others --exclude-standard -z列出的未跟踪文件并对每个文件的相对路径、长度与完整字节内容做哈希见append_untracked_file_fingerprintL73-L89。以上全部送入一个 FNV-1a 64 位哈希自实现的stable_hash_updateL7-L25刻意不依赖std::hash以保证跨平台稳定性产出 16 位十六进制fingerprint。随后生成version_label干净树version_label short_hash脏树version_label short_hash-dirty-fingerprint 前 12 位。这套设计的直接收益是两台架构完全不同的机器只要源码树逐字节相同就会算出同一个version_label——这成为提案中跨设备版本相等性判定的判据。此外ensure_source_state_matchesL140-L150会在构建前二次校验 fingerprint防止构建等待期间源码漂移说明内容寻址的状态标识在现有构建管线中已是成熟模式。自动 reload 的定向性判断为什么 mtime 是信号提案复用 crates/jcode-app-core/src/server/util.rs 的server_has_newer_binary()作为接收端发布后自动重载的触发器。阅读其源码注释可以发现一个重要的工程决策该函数只在 reload 候选二进制的 mtime 严格新于当前运行的二进制时才报告更新刻意不采用版本标识不同 ⇒ 我落后了的判断。注释中记录了 issue #291 的真实回归——较新的 self-dev daemon 与较旧的 release 客户端并存时因 git hash 不再匹配current/stable通道标记新进程会想通过 reload 把自己降级回去。对跨设备同步而言这一点尤为关键任何两端互相推送新版本的机制都必须有方向性判断否则会产生 reload 死循环提案中称之为 rebuild ping-pong下文 Phase B 的echo suppression正是对此的预防。已知缺口跨机器的仓库身份提案文档指出了现有实现中一个必须先解决的缺口repo_scope_key/worktree_scope_key哈希的是 git common dir / worktree 的本地规范化路径。从源码看source_state.rs L65-L71repo_scope_key对git rev-parse --git-common-dir的结果做canonicalize后哈希worktree_scope_key则直接对 repo 目录做同样处理。这意味着/Users/jeremy/...macOS与/home/jeremy/...Linux永远无法匹配。跨设备功能必须用可移植的键来标识仓库提案给出的两级方案是配置中显式声明仓库名如[sync] repo_id jcode回退到规范化 origin URL 的哈希。三大设计张力提案在展开机制前先诚实地列出了三个根本性约束这三条决定了整个方案为什么选择git 管道 每机构建而不是更直觉的方案二进制不可跨机共享。darwin-aarch64 与 linux-x86_64 的二进制互不兼容。处处同版本只能意味着同一源码状态、每机各自构建跨机等价性由version_label校验。并非所有写入都经过服务器中介。工具编辑走 server但bash、编辑器、cargo会隐形地修改 worktree。跨设备同步因此需要字节级捕获机制git 管道快照和/或文件系统 watcher而不仅仅是转发工具事件。笔记本会离线。纯 live-syncmutagen/syncthing 风格的冲突语义差。基于 Git 的收敛每设备同步 ref 合并能诚实地处理离线分叉。核心机制不触碰 HEAD 的 worktree 状态传输这是全文最精华的一段设计。如何在可能很脏的 worktree 上做一次原子快照同时不移动用户的 HEAD 和 index提案给出如下 git 管道命令序列完整继承自原文档GIT_INDEX_FILE$tmp git add -A # tracked untracked 进入临时 index tree$(GIT_INDEX_FILE$tmp git write-tree) commit$(git commit-tree $tree -p HEAD -m jcode sync: device fingerprint) git push origin $commit:refs/jcode/sync/device逐步解读这四个命令为什么恰好满足跨设备同步的全部需求GIT_INDEX_FILE$tmp将 index 指向临时文件git add -A把已跟踪与未跟踪文件的当前内容全部写入临时 index——工作树、真实 index、HEAD 三者一律不动git write-tree将临时 index 中的所有内容写成对象库中的 tree 对象得到内容寻址content-addressed的 tree 哈希git commit-tree $tree -p HEAD构造一个父提交指向当前 HEAD 的 commit 对象但不更新任何 ref——这是一个悬空的 commit可安全传输git push origin $commit:refs/jcode/sync/device将该 commit 推送到按设备命名的同步 ref接收方通过拉取该 ref 还原状态。文档对这套机制的性质总结为原子单个 commit 对象包含完整树、内容寻址哈希即身份、包含未跟踪文件-A、排除 gitignore 文件add -A受 ignore 规则约束接收方 fetch 该 ref 后将其应用到工作树checkout 或 diff 物化随后校验current_source_state().fingerprint与 beacon 中携带的 fingerprint 是否一致保证逐字节精确复现发送方的 worktree/index/HEAD 全程不动。其中接收方校验 fingerprint这一步可直接复用前面介绍的current_source_stateAPI——发送端与接收端使用同一套指纹算法闭环校验是自洽的。分阶段落地计划Phase B — selfdev build 对齐最先做直接消灭主要痛点Phase B 的目标机器 X 成功selfdev build publish 之后让机器 Y 自动到达同一源码状态并重建。流程分三步计算 SourceState构建管线本来就会做零增量快照 worktree 到refs/jcode/sync/device并推送到共享 git remote。干净树可以跳过快照直接用已有 commit广播 version beacon载荷为{repo_id, version_label, fingerprint, full_hash, sync_ref, device, timestamp}三级投递通道快速路径经由 Tailscale 对端 gateway 做 HTTP POST/peer/version-beacon兜底jade relay 设备事件可穿透 NAT复用 jade_relay.rs 的既有设备事件机制慢速路径对端轮询 git remote 上的 sync refs不依赖任何新端口。机器 Y 的 server 运行一个小型 peer-sync 任务——提案明确其形状same shape asjade_relay::spawn_if_configured这一对应关系在源码中确实成立crates/jcode-app-core/src/server/jade_relay.rs 中的spawn_if_configured正是读取安全配置 → 若已配置则tokio::spawn长驻监听任务的模式peer-sync 任务可直接套用。接收端逻辑收到 beacon若version_label与自己已运行/近期已应用的相同则忽略echo suppression防止两机互相触发重建的乒乓循环——这与前述server_has_newer_binary的定向性判断互为补充共同保证收敛策略门policy gate默认保守worktree 干净且本地 HEAD 是 beacon commit 的祖先 → 自动应用fetch、前移、经 selfdev 构建队列按本机架构重建、发布。随后既有的server_has_newer_binary()轮询会触发自动 reload否则 →不覆盖。在 TUI/状态栏中呈现peer build available: label from device (blocked: local changes)并提供一键确认接受发布完成后Y 的version_label与 X 相等。跨设备等价性从此可以通过比较 label 验证例如在selfdev status与 beacon acks 中。提案给出的配置草图原文完整保留[sync] enabled true repo_id jcode # 可移植的仓库身份 peers [macbook.tail-net.ts.net:7643] auto_apply clean-ff-only # off | clean-ff-only | always-notify其中auto_apply三个取值对应三种信任级别off只提示不自动、clean-ff-only仅干净树且可快进时自动默认推荐、always-notify始终走通知确认流程。Phase A — hub attach双机在线时共用一个权威 worktreejcode attach hostTUI 通过既有 gateway WS 连接到对端机器的 server。由于工具在服务端执行attach 进来的客户端可完整参与该机器的 worktree 行为冲突追踪在内。提案列出的具体工作项客户端传输以 WS 流替代 Unix socket服务端 bridge 已存在需要客户端侧对应实现——协议同源性见 jcode-base/src/gateway.rs远端客户端与 Unix socket 客户端说同一种 newline-JSON 协议配对/认证 UX面向受信个人设备DeviceRegistry 已存在审计客户端侧假设会话所在文件系统的本地磁盘读取提案明确点名了 crates/jcode-tui/src/tui/ui_file_diff.rs 中的std::fs::read_to_string调用。在仓库当前源码中该调用位于 ui_file_diff.rs L201std::fs::read_to_string(file_path).unwrap_or_default()——diff 视图直接读取本地磁盘上的被 diff 文件。对远程 attach 客户端来说该文件在远端机器上此类读取要么需要改造为 server RPC如read_file控制请求要么需要优雅降级当前unwrap_or_default()的写法至少保证了降级不会崩溃但内容会缺失。Phase C — 真正的 worktree 联邦长期目标将 Phase B 的快照机制与 Phase A 的对等连接泛化为持续双向同步数据面向每设备 sync ref 做限流自动快照触发源有三类(a) 服务器中介的工具编辑(b) 针对 bash/编辑器/cargo 写入的 fs watcher(c) 定时器。对端直接拉取 refssh/Tailscale或经由共享 remote 拉取。收敛若本地 HEAD/状态是祖先 → 快进应用若已分叉 → 保留双方快照将仓库标记为 split并让 harness 派生一个 Agent 执行合并——这就是server 管理同机冲突的跨设备类比也是 jcode Agent 即基础设施思路的自然延伸。协调面经对端链路联邦化FileTouchService事件使两台机器上的 Agent 都能跨设备看到另一个 Agent 编辑了 40-60 行的告警可选地为热文件增加咨询性advisory写租约。被否决的替代方案及理由提案完整列出了三个被考虑后否决的替代路线其否决理由本身对多机开发同一代码库这一通用问题很有参考价值Syncthing/mutagen 直接同步 worktree简单但产生字节级冲突文件.sync-conflict多文件编辑无原子性且目标目录/构建产物需要精细排除。相比之下git 管道快照给出的是原子、内容寻址、可合并的状态且使用的正是 git 用户已经熟悉的语义。始终在单机构建 拷贝二进制被架构不匹配直接击穿从 Linux 交叉编译 darwin或反向的 toolchain 成本不值得两台机器都有可用的本地工具链。NFS/SSHFS 共享 worktree惩罚离线使用并拖累 IDE/文件 watcher 性能对笔记本场景不可行。建议的实施顺序原文档给出的最终落地排序完整保留Phase B beacon 接收端auto_apply clean-ff-only仅用 git-remote 轮询不开新端口selfdev status显示对端等价性增加 gateway/peer/version-beacon快速路径 阻塞场景的 TUI 通知Phase Ajcode attachWS 客户端传输 配对 文件读取 RPCPhase C 联邦化复用 beacon 快照机制与 A 中的对端链路。这个排序体现了清晰的工程权衡第 1 步刻意不引入任何新端口/新协议只靠 git remote 既有轮询就解决了两机版本不一致这个被点名的主要痛点快速通道、交互式 attach、双向联邦按依赖关系依次叠加每一步都可独立验证验证判据始终是version_label相等性。小结一个用既有齿轮的跨设备同步设计这份提案的技术价值不在于发明了新概念而在于三件事它证明了跨设备等价的判据version_label/fingerprint、触发器builds/current mtime 定向 reload、传输gateway 同协议 jade relay NAT 穿透在仓库中都已存在跨设备同步只是把这些齿轮接上新传动轴它选择 git plumbingGIT_INDEX_FILEwrite-treecommit-tree per-device sync ref作为字节级状态传输机制用内容寻址换取原子性与可验证性接收端 fingerprint 闭环校验它把收敛与冲突的难题下沉给了 git 与 Agent快进自动应用分叉则交给 harness 派生 Agent 合并且全程有 echo suppression 与保守 policy gate 防止乒乓与覆盖。对希望跟进该功能的读者建议按提案顺序阅读仓库证据先看 crates/jcode-build-support/src/source_state.rs 理解指纹与标签算法再看 crates/jcode-app-core/src/server/util.rs 的 reload 判定与 crates/jcode-app-core/src/session_rebuild.rs 的接收端流水线最后对照 crates/jcode-app-core/src/server/jade_relay.rs 的spawn_if_configured模式理解未来 peer-sync 任务的形状。需要再次强调以上功能均处于设计阶段仓库当前尚无[sync]配置解析、refs/jcode/sync/*推送或/peer/*端点的实现本文所述将要发生的行为以提案文档为准。【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
jcode 跨设备 Worktree 与构建同步：让多台机器共用一个逻辑工作树的完整设计解析
jcode 跨设备 Worktree 与构建同步让多台机器共用一个逻辑工作树的完整设计解析【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode本文基于 jcode 仓库中仍在设计阶段的提案文档 CROSS_DEVICE_WORKTREE_SYNC.md深入拆解让多台开发机如 MacBook 与 Linux 笔记本像单一逻辑 worktree 单一构建通道一样协同工作的完整技术方案从架构无关的版本标识、基于 git 管道命令的 worktree 原子快照、version beacon 广播与回声抑制到分三阶段B/A/C的落地路径。读完本文你将掌握跨设备构建对齐build parity的原理与判定依据以及如何利用仓库中已存在的 gateway、jade relay、auto-reload 等基础设施以最小的增量改动实现多机开发环境的一致性。需要先明确的前提该方案当前状态为 Proposed (design only, not implemented)即文档已完成设计与现有代码基块的核对verified in code但功能本身尚未实现。本文所有将要发生的描述均指提案设计而非仓库当前行为。问题定义单机多 Agent 与多机开发的鸿沟在单台机器上jcode 的selfdev build reload 流程意味着每次构建后本机所有 jcode 实例都会运行新版本同时多个 Agent 可以共享同一个 worktree因为服务端会中介mediate文件编辑并跟踪冲突——这正是 crates/jcode-base 中FileTouchService与file_activity.rs所承担的编辑中介 冲突追踪职责。一旦开发工作分散到多台机器上述两个性质同时失效Linux 笔记本上执行的selfdev build不会更新 MacBook 上运行的 jcode 版本反之亦然由于不存在共享 worktree一台机器上的改动对另一台机器上的 Agent/会话完全不可见直到手动 push/pull。提案目标让多台机器表现得像一个逻辑 worktree 一个逻辑构建通道就像单机上多个 Agent 已经共享一个 worktree 那样。现有基础设施设计中可直接复用的六个构建块提案文档的一个显著优点是它没有凭空设计新机制而是逐一验证了仓库中已存在的构件verified in code。下表完整继承原文档的构件清单并结合源码逐一说明构建块所在位置为什么重要架构无关的版本标识source_state.rs 中的SourceState::version_label与fingerprintFingerprint 对完整 commit hash status diff --binary HEAD 未跟踪文件内容做哈希。两台机器上相同的源码树会产出相同的 label尽管各架构的二进制不同。更新二进制自动 reloadserver/util.rs 中的server_has_newer_binary、reload_exec_target基于 mtime 的构建通道扫描。同端触发的本地构建只要发布到builds/current即可触发既有 reload 流程零改动。Pull → build → install → exec 流水线session_rebuild.rs已实现接收端流水线的形状hot_rebuild、spawn_background_session_rebuild。网络门户同一协议jcode-base/src/gateway.rs:7643 端口的 WS 纯 HTTP远端客户端与 Unix socket 客户端使用完全相同的 newline-JSON 协议。纯 HTTP 处理器/pair、/health是放置/peer/*端点的自然位置。NAT 友好的设备事件总线jade_relay.rs设备 ID、心跳、长轮询命令事件即使机器间无法直连也能工作。服务端工具执行服务器架构本身工具bash、edit运行在 server 进程中远端客户端 attach 到另一台机器的 server 后可完整获得多 Agent 单 worktree行为包括冲突告警。远端构建先例remote_build.shrsync ssh 同步回传模式。版本标识的源码级实现fingerprint 如何做到架构无关跨设备等价校验是整个方案的第一块基石。查看 crates/jcode-build-support/src/source_state.rs 中current_source_state的实现可以看到 fingerprint 的计算完全基于源码内容与机器架构无关取短/完整 git hashgit rev-parse --short HEAD/git rev-parse HEAD取git status --porcelainv1 -z --untracked-filesall的原始字节取git diff --binary HEAD的原始字节二进制 diff可覆盖任何文件变更取git ls-files --others --exclude-standard -z列出的未跟踪文件并对每个文件的相对路径、长度与完整字节内容做哈希见append_untracked_file_fingerprintL73-L89。以上全部送入一个 FNV-1a 64 位哈希自实现的stable_hash_updateL7-L25刻意不依赖std::hash以保证跨平台稳定性产出 16 位十六进制fingerprint。随后生成version_label干净树version_label short_hash脏树version_label short_hash-dirty-fingerprint 前 12 位。这套设计的直接收益是两台架构完全不同的机器只要源码树逐字节相同就会算出同一个version_label——这成为提案中跨设备版本相等性判定的判据。此外ensure_source_state_matchesL140-L150会在构建前二次校验 fingerprint防止构建等待期间源码漂移说明内容寻址的状态标识在现有构建管线中已是成熟模式。自动 reload 的定向性判断为什么 mtime 是信号提案复用 crates/jcode-app-core/src/server/util.rs 的server_has_newer_binary()作为接收端发布后自动重载的触发器。阅读其源码注释可以发现一个重要的工程决策该函数只在 reload 候选二进制的 mtime 严格新于当前运行的二进制时才报告更新刻意不采用版本标识不同 ⇒ 我落后了的判断。注释中记录了 issue #291 的真实回归——较新的 self-dev daemon 与较旧的 release 客户端并存时因 git hash 不再匹配current/stable通道标记新进程会想通过 reload 把自己降级回去。对跨设备同步而言这一点尤为关键任何两端互相推送新版本的机制都必须有方向性判断否则会产生 reload 死循环提案中称之为 rebuild ping-pong下文 Phase B 的echo suppression正是对此的预防。已知缺口跨机器的仓库身份提案文档指出了现有实现中一个必须先解决的缺口repo_scope_key/worktree_scope_key哈希的是 git common dir / worktree 的本地规范化路径。从源码看source_state.rs L65-L71repo_scope_key对git rev-parse --git-common-dir的结果做canonicalize后哈希worktree_scope_key则直接对 repo 目录做同样处理。这意味着/Users/jeremy/...macOS与/home/jeremy/...Linux永远无法匹配。跨设备功能必须用可移植的键来标识仓库提案给出的两级方案是配置中显式声明仓库名如[sync] repo_id jcode回退到规范化 origin URL 的哈希。三大设计张力提案在展开机制前先诚实地列出了三个根本性约束这三条决定了整个方案为什么选择git 管道 每机构建而不是更直觉的方案二进制不可跨机共享。darwin-aarch64 与 linux-x86_64 的二进制互不兼容。处处同版本只能意味着同一源码状态、每机各自构建跨机等价性由version_label校验。并非所有写入都经过服务器中介。工具编辑走 server但bash、编辑器、cargo会隐形地修改 worktree。跨设备同步因此需要字节级捕获机制git 管道快照和/或文件系统 watcher而不仅仅是转发工具事件。笔记本会离线。纯 live-syncmutagen/syncthing 风格的冲突语义差。基于 Git 的收敛每设备同步 ref 合并能诚实地处理离线分叉。核心机制不触碰 HEAD 的 worktree 状态传输这是全文最精华的一段设计。如何在可能很脏的 worktree 上做一次原子快照同时不移动用户的 HEAD 和 index提案给出如下 git 管道命令序列完整继承自原文档GIT_INDEX_FILE$tmp git add -A # tracked untracked 进入临时 index tree$(GIT_INDEX_FILE$tmp git write-tree) commit$(git commit-tree $tree -p HEAD -m jcode sync: device fingerprint) git push origin $commit:refs/jcode/sync/device逐步解读这四个命令为什么恰好满足跨设备同步的全部需求GIT_INDEX_FILE$tmp将 index 指向临时文件git add -A把已跟踪与未跟踪文件的当前内容全部写入临时 index——工作树、真实 index、HEAD 三者一律不动git write-tree将临时 index 中的所有内容写成对象库中的 tree 对象得到内容寻址content-addressed的 tree 哈希git commit-tree $tree -p HEAD构造一个父提交指向当前 HEAD 的 commit 对象但不更新任何 ref——这是一个悬空的 commit可安全传输git push origin $commit:refs/jcode/sync/device将该 commit 推送到按设备命名的同步 ref接收方通过拉取该 ref 还原状态。文档对这套机制的性质总结为原子单个 commit 对象包含完整树、内容寻址哈希即身份、包含未跟踪文件-A、排除 gitignore 文件add -A受 ignore 规则约束接收方 fetch 该 ref 后将其应用到工作树checkout 或 diff 物化随后校验current_source_state().fingerprint与 beacon 中携带的 fingerprint 是否一致保证逐字节精确复现发送方的 worktree/index/HEAD 全程不动。其中接收方校验 fingerprint这一步可直接复用前面介绍的current_source_stateAPI——发送端与接收端使用同一套指纹算法闭环校验是自洽的。分阶段落地计划Phase B — selfdev build 对齐最先做直接消灭主要痛点Phase B 的目标机器 X 成功selfdev build publish 之后让机器 Y 自动到达同一源码状态并重建。流程分三步计算 SourceState构建管线本来就会做零增量快照 worktree 到refs/jcode/sync/device并推送到共享 git remote。干净树可以跳过快照直接用已有 commit广播 version beacon载荷为{repo_id, version_label, fingerprint, full_hash, sync_ref, device, timestamp}三级投递通道快速路径经由 Tailscale 对端 gateway 做 HTTP POST/peer/version-beacon兜底jade relay 设备事件可穿透 NAT复用 jade_relay.rs 的既有设备事件机制慢速路径对端轮询 git remote 上的 sync refs不依赖任何新端口。机器 Y 的 server 运行一个小型 peer-sync 任务——提案明确其形状same shape asjade_relay::spawn_if_configured这一对应关系在源码中确实成立crates/jcode-app-core/src/server/jade_relay.rs 中的spawn_if_configured正是读取安全配置 → 若已配置则tokio::spawn长驻监听任务的模式peer-sync 任务可直接套用。接收端逻辑收到 beacon若version_label与自己已运行/近期已应用的相同则忽略echo suppression防止两机互相触发重建的乒乓循环——这与前述server_has_newer_binary的定向性判断互为补充共同保证收敛策略门policy gate默认保守worktree 干净且本地 HEAD 是 beacon commit 的祖先 → 自动应用fetch、前移、经 selfdev 构建队列按本机架构重建、发布。随后既有的server_has_newer_binary()轮询会触发自动 reload否则 →不覆盖。在 TUI/状态栏中呈现peer build available: label from device (blocked: local changes)并提供一键确认接受发布完成后Y 的version_label与 X 相等。跨设备等价性从此可以通过比较 label 验证例如在selfdev status与 beacon acks 中。提案给出的配置草图原文完整保留[sync] enabled true repo_id jcode # 可移植的仓库身份 peers [macbook.tail-net.ts.net:7643] auto_apply clean-ff-only # off | clean-ff-only | always-notify其中auto_apply三个取值对应三种信任级别off只提示不自动、clean-ff-only仅干净树且可快进时自动默认推荐、always-notify始终走通知确认流程。Phase A — hub attach双机在线时共用一个权威 worktreejcode attach hostTUI 通过既有 gateway WS 连接到对端机器的 server。由于工具在服务端执行attach 进来的客户端可完整参与该机器的 worktree 行为冲突追踪在内。提案列出的具体工作项客户端传输以 WS 流替代 Unix socket服务端 bridge 已存在需要客户端侧对应实现——协议同源性见 jcode-base/src/gateway.rs远端客户端与 Unix socket 客户端说同一种 newline-JSON 协议配对/认证 UX面向受信个人设备DeviceRegistry 已存在审计客户端侧假设会话所在文件系统的本地磁盘读取提案明确点名了 crates/jcode-tui/src/tui/ui_file_diff.rs 中的std::fs::read_to_string调用。在仓库当前源码中该调用位于 ui_file_diff.rs L201std::fs::read_to_string(file_path).unwrap_or_default()——diff 视图直接读取本地磁盘上的被 diff 文件。对远程 attach 客户端来说该文件在远端机器上此类读取要么需要改造为 server RPC如read_file控制请求要么需要优雅降级当前unwrap_or_default()的写法至少保证了降级不会崩溃但内容会缺失。Phase C — 真正的 worktree 联邦长期目标将 Phase B 的快照机制与 Phase A 的对等连接泛化为持续双向同步数据面向每设备 sync ref 做限流自动快照触发源有三类(a) 服务器中介的工具编辑(b) 针对 bash/编辑器/cargo 写入的 fs watcher(c) 定时器。对端直接拉取 refssh/Tailscale或经由共享 remote 拉取。收敛若本地 HEAD/状态是祖先 → 快进应用若已分叉 → 保留双方快照将仓库标记为 split并让 harness 派生一个 Agent 执行合并——这就是server 管理同机冲突的跨设备类比也是 jcode Agent 即基础设施思路的自然延伸。协调面经对端链路联邦化FileTouchService事件使两台机器上的 Agent 都能跨设备看到另一个 Agent 编辑了 40-60 行的告警可选地为热文件增加咨询性advisory写租约。被否决的替代方案及理由提案完整列出了三个被考虑后否决的替代路线其否决理由本身对多机开发同一代码库这一通用问题很有参考价值Syncthing/mutagen 直接同步 worktree简单但产生字节级冲突文件.sync-conflict多文件编辑无原子性且目标目录/构建产物需要精细排除。相比之下git 管道快照给出的是原子、内容寻址、可合并的状态且使用的正是 git 用户已经熟悉的语义。始终在单机构建 拷贝二进制被架构不匹配直接击穿从 Linux 交叉编译 darwin或反向的 toolchain 成本不值得两台机器都有可用的本地工具链。NFS/SSHFS 共享 worktree惩罚离线使用并拖累 IDE/文件 watcher 性能对笔记本场景不可行。建议的实施顺序原文档给出的最终落地排序完整保留Phase B beacon 接收端auto_apply clean-ff-only仅用 git-remote 轮询不开新端口selfdev status显示对端等价性增加 gateway/peer/version-beacon快速路径 阻塞场景的 TUI 通知Phase Ajcode attachWS 客户端传输 配对 文件读取 RPCPhase C 联邦化复用 beacon 快照机制与 A 中的对端链路。这个排序体现了清晰的工程权衡第 1 步刻意不引入任何新端口/新协议只靠 git remote 既有轮询就解决了两机版本不一致这个被点名的主要痛点快速通道、交互式 attach、双向联邦按依赖关系依次叠加每一步都可独立验证验证判据始终是version_label相等性。小结一个用既有齿轮的跨设备同步设计这份提案的技术价值不在于发明了新概念而在于三件事它证明了跨设备等价的判据version_label/fingerprint、触发器builds/current mtime 定向 reload、传输gateway 同协议 jade relay NAT 穿透在仓库中都已存在跨设备同步只是把这些齿轮接上新传动轴它选择 git plumbingGIT_INDEX_FILEwrite-treecommit-tree per-device sync ref作为字节级状态传输机制用内容寻址换取原子性与可验证性接收端 fingerprint 闭环校验它把收敛与冲突的难题下沉给了 git 与 Agent快进自动应用分叉则交给 harness 派生 Agent 合并且全程有 echo suppression 与保守 policy gate 防止乒乓与覆盖。对希望跟进该功能的读者建议按提案顺序阅读仓库证据先看 crates/jcode-build-support/src/source_state.rs 理解指纹与标签算法再看 crates/jcode-app-core/src/server/util.rs 的 reload 判定与 crates/jcode-app-core/src/session_rebuild.rs 的接收端流水线最后对照 crates/jcode-app-core/src/server/jade_relay.rs 的spawn_if_configured模式理解未来 peer-sync 任务的形状。需要再次强调以上功能均处于设计阶段仓库当前尚无[sync]配置解析、refs/jcode/sync/*推送或/peer/*端点的实现本文所述将要发生的行为以提案文档为准。【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
