The problem
“Sent” was not the same as accepted, working, or complete.
Moving AI work between computers revealed problems that a simple “send” button could hide: two writers colliding, a wake-up mistaken for acceptance, queued work that never starts, repeated deliveries, stale availability, long tasks blocking new mail, and oversized histories slowing the handoff.
What it must do
Send work to the right place and report its real status—even when several things happen at once.
- Deliver work to the intended task without ambiguous fallback.
- Keep accepted, working, completed, busy, offline, and waiting states visibly distinct.
- Continue receiving and reporting work while another assignment is still running.
- Recover cleanly after interruption without duplicating or looping deliveries.
- Keep large histories bounded so coordination remains responsive.
- Present one coherent lifecycle across the desktop, background service, command tools, and installer.
Product approach
Make delivery state truthful and recoverable.
Exact destination
Work is associated with the intended task so the user can understand where it went and which result belongs to it.
Visible lifecycle
Delivery, acceptance, active work, completion, and attention states remain distinguishable instead of collapsing into “sent.”
Operational recovery
Interrupted work can resume or report a bounded failure without creating duplicate assignments or hiding uncertainty.
What Shayne owned
Failure discovery, routing boundaries, and live acceptance.
How AI assisted the build
Several specialist agents contributed, with one human acceptance standard.
Specialist agents contributed implementation, integration work, testing, packaging, diagnosis, and review. Shayne retained the authority boundaries, failure reproduction, state-model corrections, prioritization, product decisions, and final live acceptance.
Verification
Established evidence and active development are kept separate.
An earlier matching release completed two-machine LAN acceptance with zero build warnings and errors. Current work continues on scheduling, concurrency, and large-task boundaries.
Result & next stage
A working local-first relay that continues to be refined.
The broader implementation has accepted packaged and two-computer evidence. Current development focuses on scheduling, concurrent work, and large-task behavior, while ARM64 remains a later platform phase.