chore: establish YCode replication baseline and TODO

This commit is contained in:
xiaohan.yuan committed 2026-10-17 02:43:49 +08:00
commit 6dc59f89ba
1118 files changed
+196002

No files matched your search

@@ -0,0 +1,94 @@
# WorkBuddy 1:1 复刻重新评估
> 本文是实施前的评估快照。后续实际实现和验证见 [复刻进展](复刻进展-2026-10-15.md);源码差距表保留当时状态,不作为最新完成度。
日期:2026-10-15。目标版本:本机 WorkBuddy 5.8.2。原版查看全部通过 REA;YCode 源码通过正常项目工具检查。本轮只评估,不改变用户的 1:1 目标,不改产品代码。
## 判断
**不能承诺完整产品的无条件 100% 等价;可以将固定版本、固定环境下的客户端视觉及确定性交互作为严格 1:1 的实施和验收目标。**
当前证据支持继续重建客户端,尚不足以证明全部功能都可原样实现。尤其是原生编辑/沙盒、服务端行为及模型输出,需要分别补证据或获得对应服务能力。它们不能通过完善界面或接入 OMP 自动解决。
“可实施”是工程判断,尚不是已经通过验收。没有依据提供整体完成百分比或精确工期。
| 1:1 的对象 | 本轮判断 | 条件及限制 |
| --- | --- | --- |
| 固定版本的客户端视觉 | 可作为严格目标推进,当前未验收 | 固定 OS、Electron/Chromium、DPR、窗口尺寸、字体、主题、字号、数据及滚动位置;需通过 REA 获取可比较的像素样本 |
| 确定性交互:菜单、选择、编辑、折叠、滚动、取消、恢复 | 可逐场景实现和验证 | 需要完整状态与错误分支证据;只比最终截图不足以验证 |
| 本地 Agent 功能与流程 | 有条件可重建;尚未证明完整等价 | 逐项还原工具契约、权限、提问、子任务、扩展、上下文及生命周期;OMP 需要适配与差距验证 |
| 模型的每次文字回答、工具选择及耗时 | 当前不能保证逐次相同 | 同一提示不等于相同模型版本、提示词、上下文、路由、采样和调度条件;模型生成还可能具有随机性 |
| 官方账号、权益、订单及其他服务端业务结果 | 仅靠客户端证据不能还原官方事实 | 可以实现自己的同类服务;接口形状不包含官方后台状态及完整实现,mock 不构成等价 |
| 原生编辑器与沙盒行为 | 本轮未知;需单独评估 | 观察到相关原生组件存在,未完成其接口、文件兼容性、权限边界与失败模式验证;不能用体积推断不可能或容易 |
| 所有环境、全部隐藏分支、未来版本 | 不能据有限证据作全局等价承诺 | 验收应针对明确版本和覆盖范围;版本变化后需重新对比 |
## 旧评估中需要撤回的推理
1. **“1:1 等于复制原始源码”不成立。** 本项目的工程目标是用户可观察的视觉、交互及功能一致;实现代码可以不同。源码逐字节一致是另一个要求。
2. **“没有 source map / 名称被压缩,所以不能复刻”不成立。** 这会增加理解和重建成本,不自动否定可观察行为的重建。
3. **“原生组件数百 MB,所以不可能重建”证据不足。** 文件体积不等于业务复杂度;应按实际接口、行为覆盖和兼容性要求判断。
4. **“本机没配置反编译器,所以永久做不到”不成立。** 工具配置是当前条件,不是不可改变的技术定理。本轮也未重新确认全部 native provider 状态。
5. **“排除官方云就没有 AI 能力”过度推断。** 可以连接自己的模型服务并提供 AI 功能,但不因此获得原版模型与业务结果的等价保证。
6. **“依赖清单或字符串足以证明原版 Agent 循环来自某 SDK/产品”证据不足。** 依赖存在不等于该调用路径实际承担主循环,需要追踪和运行时证据。
上一轮接手确认了用户目标并收尾取消问题,没有完成全产品可行性验证。不能把“接受 1:1 目标”当成“已证明可以全量 1:1”。
## 本轮新增原版证据
复用先前 ASAR 身份与清单:SHA-256 `035254bc76310ea46317433e4840602094543ef323d2d5c5aff7c131729de918`。
REA 本轮选择分析了:
- `main/index.js`
- `renderer/assets/account-9NjO6QCF.js`
- `renderer/assets/conversation-CmigeZ37.js`
- `renderer/assets/charge-user-api-BAFEErUh.js`
- `renderer/assets/permission-preference-service-BrHJCEMO.js`
5 个 JavaScript 文件均解析成功,遍历 107909 个 AST 节点;观察到 3 个 BrowserWindow 语法记录及 52 个 IPC 操作,其中有动态通道。**这些是静态语法观察,不能写成“运行时创建了 3 个窗口/调用了 52 次 IPC”。**
| 证据 | 实际支持的结论 |
| --- | --- |
| 父分析 `ev_1c590592d84ebb5e65c68816bbfc7c5da005c9b4fb427f96c31f7dbabf0f2ce8`;摘要 `ev_cb9e8d4498e2ab57130dc066d826f83bfef643a56ee7269bd55adc1b9a1cacdc` | 选定文件可进行 AST 分析;其余 11384 个文件未分析;语义图受本轮 8000/12000 节点预算限制,覆盖不完整 |
| 账户模块视图 `ev_864d3c1f1d64164133eae079565619f92f6f8fe42daef515a4a5e7759086ff02` 及导出观察 | 存在账户组件及 CreditsMenuItem / EditionBadge 的静态导出,不能据此声称已还原官方账号行为 |
| 权限模块视图 `ev_d01df66f6751a3ec47ba5b7dfddbe4fbd109cb49627618577f1e2adbe0558d1b` | 存在 ConversationPermissionPreferenceService 的静态导出;完整权限执行机制尚未验证 |
| 权益模块追踪 `ev_cdeb75ab51d531dcc460f74ee0563f5c939429fb4e6906d6e635fafbf6c5f691` | 存在 checkEntitlement / getOrderStatus / refundOrder 等导出及订单/权益返回字段的静态候选;字段值、服务器逻辑和实际调用仍未知 |
| 先前被动 Electron 观察 `ev_07b84c62b706541456e7415ae6d886bc0b3e8e98f1fbf3456e29ba12cb46db9b` | 可通过 REA 读取当前 file 页面结构及脚本元信息,不等于取得了像素与 computed style |
选定证据投影保存在 `.tmp/rea-reassessment-selected-evidence-2026-10-15.json`;它不是完整 Evidence bundle。
完整原始分析仍保留在 REA 会话,前一轮清单 bundle 位于 `.tmp/rea-workbuddy-takeover-2026-10-15.json`。
## REA 的当前验证边界
- `list_electron_targets` 和 `inspect_electron_page` 对当前原版 file 目标可用。
- 本轮对同一目标调用 `capture_web_screenshot`,返回 `target_unavailable` / `reason: target_not_allowed`。**原版结构观察已打通,像素截图验收尚未打通。** 不能绕过用户约束去运行直接 CDP 脚本。
- ASAR 伴随原生文件有完整性声明与实际摘要不符的记录。本轮使用 `record-and-continue` 保留矛盾分析,不能推断其原因或具体功能故障。
- 对通用 `url` 属性的语义追踪完成后超出 MCP 传输预算;对应保留证据为 `ev_239628541386759af69e1a3b16f07d1a5ba84759264f73a43698b63edb22acb9`。本轮没有消费该完整结果,不将其用于端点或服务器实现结论。
- 没有运行原版业务动作、登录、提交订单、读取凭据或重启原版;没有重新验证 CLI 全部代码、原生组件或官方云实现。
## 当前 YCode + OMP 能否直接达到目标
**当前实现不够;继续只补 CSS 和转发 OMP 文本流,达不到完整交互与功能 1:1。** Electron/React 壳层可以保留,状态与协议层需要扩展。
| 源码事实 | 对目标的影响 |
| --- | --- |
| `src/shared/types.ts`:ChatMessage.content 是字符串;ChatEvent 只有 started/text/tool_call/tool_result/done/cancelled/error | 无法直接表达审批、用户提问、结构化内容块、产物、子任务等丰富状态;应先扩展领域模型再接渲染 |
| `src/main/agent/omp-turn.ts`:只映射 text_delta、三类工具事件和终态;其他事件忽略 | 不能把“OMP 已支持”当成“YCode 已支持”;需要逐项核实内核能力和适配映射 |
| 同文件:工具结果摘要限制 600 字符;工具状态只有 running/ok/error | 全量输出、取消中工具、审批、结果产物等需另建数据结构;不能靠摘要完成完整结果交互 |
| `src/main/omp.ts`:固定 ycode profile、进程使用 --no-session;`ipc.ts` 的 OMP 分支只发送当轮文本 | 本地保存的消息尚未重新灌入新内核;会话恢复后的模型上下文可能与 UI 显示分离 |
| `src/renderer/src/stores/chat.ts`:单一 running 状态,运行中拒绝切换/新建/删除 | 当前前端限制并行会话;原版实际并行语义尚需 REA 复核,不能提前宣称一致 |
| 账号/通知/空间及多个入口仍为 mock 或提示;正文纯文本 | 表面具备入口不代表对应功能已实现 |
另有两项可靠性风险:`OmpKernel.handleLine` 将带关联 id 的响应发到 `frame` 后返回,而适配器只监听 `event` 并仅检查 prompt ack 的 `success === false`;如果终态只出现在关联响应中,就可能漏处理。当前也没有回合级终态等待超时,abort 响应/失败被忽略;若没有后续终态事件,界面可能一直运行。是否触发这些风险需 OMP 协议及运行时复核。
本轮审计的是 YCode 适配器,没有证据证明 OMP 本体必然无法提供这些能力,也没有证据证明它可以不经扩展完整承接。暂不作换内核或推倒重写决定。
## 继续实施前的验收关口
1. **客户端参照**:通过 REA 获取固定版本、固定环境的原版截图/状态样本,补齐当前像素采集缺口;为每个页面和关键交互列出参照。
2. **对话协议**:原版文本→工具→审批/提问→取消→恢复等流程建立事件与状态样本;YCode 扩充消息块、工具状态、产物和会话生命周期,再用确定的输入/模型响应重放验证。
3. **内核差距**:逐项映射原版能力与 OMP 的实际接口;已支持就适配,未支持就实现扩展,再决定是否需要其他内核。
4. **外部与原生能力**:账号、模型、同步、文档、沙盒等分别评估可接入服务/自建实现/未知边界;不得将替代实现或 mock 标为原版等价通过。
如果要求“自主运行、所有官方功能和每次 AI 结果都与原版完全相同”,当前结论是**不具备可承诺的可行性**。
如果验收对象是明确版本与环境下的完整客户端视觉、确定性交互及逐项定义的功能契约,结论是**可以继续严格推进,但需要补证据与实现,不能宣称已证明全量可行**。