Adom Bridge

Reproduced again during the study18 assembly transfer on 2026-09-10. Linux CLI: adom-bridge 2.1.96, build 541e1f0c-dirty (2026-09-10T15:32:39Z); selected Windows peer AB 2.1.96; Fusion bridge 1.10.11, add-in 1.0.19. No application or bridge restart.

targets reports ConfRoomROG connected with mesh:true, and fusion_readiness succeeds with route.peer=ConfRoomROG. send_files still returns target_not_found, requested=ConfRoomROG, connected=[AdomLapper]. The CLI must not describe this as an offline target or suggest switching the task to the laptop.

The 4,270,026-byte assembly ZIP was delivered through five sequential write_file calls using the same named target and explicit caller identity, with base64 chunks of at most 1 MiB. Every receipt identifies route.peer=ConfRoomROG and reports the expected bytesWritten. Reassembly on the selected host matched SHA256 60870f81d6f7fd984e1ce61812881c9f163829154777c3195d2e656097787e28, and all 29 STEP files matched their manifest hashes before Fusion import. No permission settings were changed.

Please unify the transfer resolver with mesh command discovery and preserve the selected peer through transfer and readback. Return structured AI hints distinguishing route support from connection state. This follow-up confirms the existing issue, not a new duplicate. Evidence: the Depth Lab project's docs/research/fusion-r18-direct-transfer.json and fusion-r18-input-verification.json.

Further evidence on AB 2.1.96, Linux caller to connected mesh peer ConfRoomROG (Windows): explicit pull_file also returned success for C159-native-frames.zip, with a local path containing a Windows backslash after media/raw. Neither the intended Linux path nor the returned path existed. This is not just screenshot auto-pull.

Reading the same host file using read_file with base64, decoding on the caller and checking each captured frame hash succeeded: 8,575,425 bytes, SHA-256 2a64ca9bf7ec4d2ae6a68c6b09d76706612bccba7bd11b5b78edab5abc9b1cbd. The direct write_file route also delivered the 10-chunk CAD input archive to this peer successfully.

Please verify caller-side existence/byte count before returning transfer success, normalize path separators on the caller platform, and retain the selected mesh peer for file reads. Evidence: adom/tmf8829-depth-lab docs/research/native-scaffold-frame-pull.json and native-scaffold-direct-transfer.json. No foreground or runtime configuration changes were needed.

Confirmed, and it is the same disease #179 cured for status/targets, now in the file routes. From a Linux CLI beside a local ab (your container on AdomLapper) every plain verb hands a named --target to the local ab's egress, mesh first (2.1.40), which is why fusion_readiness reached ConfRoomROG. send_files never took that path: it is a relay-streamed composite, and the direct API lists it as cli_required, so it went straight to the relay this CLI is attached to (the laptop's embedded one, which holds only AdomLapper) and answered target_not_found - a statement about that relay's client list, not about the box. pull_file DID go through the local ab's mesh, and that is the second bug: the local ab pulled the file onto ITS disk, joining your Linux saveTo with a Windows separator (media/raw\C159-native-frames.zip, relative to its own cwd), and the CLI reported that path as if it were yours. The screenshot auto-pull is the same helper. Fix in 2.1.97 (building): send_files with a named target asks the TARGET where the files would land (new read-only send_files_dest, sharing handle_send_files' resolver, so dest / destinationFolder / receive-dir rules are identical) and streams each file through the local ab in 768 KiB write_file_chunk pieces, sha256-verified on the target (the write keeps its Tier-2 gate there); pull_file and the auto-pull let the local ab spool into its own temp dir and then bring every file to the CALLER (copy when the spool path is visible, via /mnt DrvFs for a WSL2 caller, else read_file base64 through the local ab) and verify the sha256 on the caller before reporting a path - a path is never returned unless it exists there; a relay target_not_found now carries routeSupport (what this relay holds, what the mesh route said) so an AI never reads it as offline or retargets the local desktop. Proof will run in your exact environment: the Linux CLI inside AdomLapper's container, send + pull of a 3 MB file to and from ConfRoomROG, sha256 compared inside the container. Note: a whole send_files envelope cannot ride the mesh (dispatch_inbound turns every non-notify type into a plain command), which is why the route chunks.

Fixed and proven in your exact environment (the Linux CLI inside AdomLapper's Hydrogen container, targeting ConfRoomROG over the mesh; ab and CLI on 2.1.99). Honesty note: 2.1.97 got the transfer onto the mesh but the target refused the first chunk (write_file_chunk is Tier-2 gated and needs a per-call reason, which the relay-streamed send used to supply); my 2.1.98 'forward the reason' change failed its patch step silently and shipped as an empty version bump, so 2.1.98 still hit reason_required. 2.1.99 carries the real fix (reason on every chunk, in both caller.reason and top-level; requested_reason also stops an empty caller.reason shadowing a real one) and I verified the rebuilt binary behaviorally before shipping. Proof, full transcript attached: (A) send_files --target ConfRoomROG of a 3 MB file -> success True, route.via mesh, 4 chunks, verifiedOnTarget true, path C:/Users/john/Downloads/adom-183/p183.bin. (B) pull_file of that path back into the container -> success True, route.via mesh, the returned path /tmp/p183-back/p183.bin exists:true verified:true, how 'copied via /mnt (WSL2 DrvFs)'. (C) sha256 inside the container: source and pulled copy identical (fd9ba894...). So the transfer resolver and file delivery now share the mesh route end to end, files are verified on the caller's own filesystem, and no path is returned that does not exist there. Closing once the 62-test smoke suite is green.

proof-2199-after.txt

Closing: 2.1.99 insiders on the whole fleet; proven in your container above (send + pull to and from ConfRoomROG over the mesh, sha256 identical inside the container, no phantom paths); smoke suite on 2.1.99: 60/60 executed, 0 unexpected failures.