Zeron × Lody.

Our tree includes the Cloudflare Worker and room implementation, the Rust engine and the iOS client. Lody explicitly excludes hosted backends and web/mobile app sources. This gives us a stronger starting point for independent inspection and deployment work. It does not mean Zeron already offers a supported, turnkey self-hosting contract; our architecture explicitly defers that promise.

The same Rust engine supports a desktop viewport and headless service. The transcript watch protocol carries changed entries and text appends, avoiding retransmission of the entire history on every streaming commit. This is a concrete efficiency mechanism. Lody’s Electron/React architecture favors UI reuse across surfaces; it also has subscription isolation and bounded prefetch. We cannot infer a performance win from the implementation language.

Queue rows retain identity through Loro moves. The host serializes delivery and protected editing; edit leases carry generations, stale edits require review, attachment messages wait for compatible turns, and recovered queues start paused. These are valuable details when a phone and desktop control the same running agent. Lody has durable orchestration too; our inspected evidence supports queue depth as a Zeron strength, not a blanket claim that Lody loses queued messages.

Appshots capture another desktop application window, optionally enrich it with accessibility text, and stage it before sending. Lody’s inspected visual tools concentrate on web preview elements. Our advantage is the broader desktop context source. Capture is implemented for macOS and supported Linux paths; Windows capture is absent, and iOS displays received Appshots rather than capturing other apps.

Lody exposes session, project, workspace, machine, agent-config, MCP, export and review commands. Its operation model supports batch session creation and messaging, deadlines, durable-input state, cancellation and parent/child results. Zeron’s CLI primarily manages the daemon, authentication, updates and sync diagnostics. Internal RPC and provider-native subagent display are useful foundations, but they do not give users an equivalent scriptable orchestration product.

Lody represents Agent Roles and MCP servers as workspace Flock rows. Accepted operations capture resolved role configuration so later edits do not silently change an accepted request. This is a stronger reusable-workflow model than repeatedly choosing a harness and model. Private visibility is not a secret-storage guarantee: their own documentation notes that underlying role rows can reach workspace clients.

Their review planner models review-only versus review-and-merge, round budgets, reviewer availability, human intervention, CI state and the approved commit SHA. The code shows much more workflow depth than our diff/comment surfaces. The practical lesson is to adopt the durable review state machine and exact-commit checks before considering automatic merges. Hosted GitHub integration remains a separate capability; source presence does not prove every mode works in the public local build.

Lody’s preview feedback carries element targets, selectors/XPath, viewport geometry and anchor re-resolution, with dedicated annotation composer and overlay components. Zeron has project discovery, a browser and remote preview transport, but I found no corresponding DOM-anchored annotation workflow in the inspected browser/preview code. Appshots and DOM annotations solve complementary problems; keep the former and borrow the latter.

Hosted Lody documents shared machines, projects and conversations, plus web, iOS and Android access. Our registry route creates a per-user room, so an organization is not automatically a shared team workspace. The team-product advantage is clear in intent and public client contracts, but the hosted access-control implementation and mobile quality cannot be verified from this repository. Zeron’s iOS implementation is inspectable; that is a different advantage from platform breadth.

Session text uses LoroText appends. The current ChatRoom stores opaque updates and host-built checkpoints without materializing Loro in the Durable Object. That removes a class of server-side CRDT import/export work. The price is ownership of framing, cursor recovery, checkpoint coverage, deduplication and cross-language compatibility. A transport that does not parse Loro bytes is also not, by itself, end-to-end encryption.

Lody uses Loro Repo with a SQLite store, Flock for keyed catalogs, Streams for remote transport and Mirror for projection. Its local/cloud planes are separated, reconnect sends version-vector deltas, and large local doc updates are chunked. This is a stronger reuse strategy than hand-owning every layer. It still carries adapters, a loro-repo patch, cursor URL aliases and lifecycle fixes; “uses the official stack” does not mean zero integration burden.

Zeron now journals local updates in a SQLite outbox before network admission, replays stable batch IDs across client recreation, and retains rejected batches until checkpoint coverage succeeds. Regression tests cover eviction, disconnected cleanup and failed-checkpoint retry. This is meaningful recovery engineering, but it also shows why CRDT convergence is insufficient: replicas cannot merge operations that never arrive. These tests were inspected, not rerun for this report; no head-to-head reliability claim follows.

Our main event-fold path still parks tool-output sidecar uploads and keeps summaries in the document, with fuller outputs in the host journal. Small replicated documents help constrained links, but remote users cannot assume the synced transcript contains all tool evidence. Other upload call sites exist, so this finding concerns the ordinary event-fold path specifically. Lody’s public code supports richer history/review structures, but this review did not establish identical output retention across every provider.