Multiplatform: remote host, browser client, phone shells (parked)

[Tryanks]

Draft — parked for later. This is the multiplatform work from #173, taken back out of main by #174 and held here until we pick it up again.

Nothing was failing. All seven CI jobs were green when #173 merged; it was parked by choice, not by defect.

Why this branch and not the original

Re-merging feat/multiplatform-groundwork would not work. Its commits are still ancestors of main through the merge #174 reverted, so git treats them as already applied and a PR from it shows an empty diff. Reverting the revert is the way back, which is what the single commit on this branch does.

What it contains

A sync host the desktop app starts on loopback at launch, plus tcode-server for machines with no display. A wire protocol (docs/sync-protocol.md) where clients send commands and the host streams events, each carrying a per-session sequence number a reconnecting client resumes from. A shared client UI compiled to wasm, Android and iOS — one implementation, three shells — that follows a session, sends turns, and answers approvals. Devices get in with a six-character pairing code, once.

Four CI jobs that actually gate it. The previous workflow proved only that the desktop build worked: client-app is outside the workspace and five other crates compile to empty shells on a host. These build them for their real targets, with no failure suppression.

Known state when parked

	Status
Desktop host, headless host, browser client	Exercised end to end
Android	Links for aarch64-linux-android, all JNI entry points exported. Never run on a device
iOS	Links against the iOS SDK. Never run on a device or simulator

The mobile rows are the open question. Linking proves every symbol GPUI, wgpu, Metal, Vulkan and psm need resolves — which cargo check does not — and is still not the same as having seen a frame. The likely first failure on both is renderer creation meeting real hardware.

docs/remote-and-mobile.md is the user-facing guide; docs/multiplatform-plan.md records the architecture and the approaches rejected along the way.

🤖 Generated with Claude Code

[Tryanks]

Draft — parked for later. This is the multiplatform work from #173, taken back out of main by #174 and held here until we pick it up again.

Nothing was failing. All seven CI jobs were green when #173 merged; it was parked by choice, not by defect.

Why this branch and not the original

Re-merging feat/multiplatform-groundwork would not work. Its commits are still ancestors of main through the merge #174 reverted, so git treats them as already applied and a PR from it shows an empty diff. Reverting the revert is the way back, which is what the single commit on this branch does.

What it contains

A sync host the desktop app starts on loopback at launch, plus tcode-server for machines with no display. A wire protocol (docs/sync-protocol.md) where clients send commands and the host streams events, each carrying a per-session sequence number a reconnecting client resumes from. A shared client UI compiled to wasm, Android and iOS — one implementation, three shells — that follows a session, sends turns, and answers approvals. Devices get in with a six-character pairing code, once.

Four CI jobs that actually gate it. The previous workflow proved only that the desktop build worked: client-app is outside the workspace and five other crates compile to empty shells on a host. These build them for their real targets, with no failure suppression.

Known state when parked

	Status
Desktop host, headless host, browser client	Exercised end to end
Android	Links for aarch64-linux-android, all JNI entry points exported. Never run on a device
iOS	Links against the iOS SDK. Never run on a device or simulator

The mobile rows are the open question. Linking proves every symbol GPUI, wgpu, Metal, Vulkan and psm need resolves — which cargo check does not — and is still not the same as having seen a frame. The likely first failure on both is renderer creation meeting real hardware.

docs/remote-and-mobile.md is the user-facing guide; docs/multiplatform-plan.md records the architecture and the approaches rejected along the way.

🤖 Generated with Claude Code

[Tryanks]

Draft — parked for later. This is the multiplatform work from #173, taken back out of main by #174 and held here until we pick it up again.

Nothing was failing. All seven CI jobs were green when #173 merged; it was parked by choice, not by defect.

Why this branch and not the original

Re-merging feat/multiplatform-groundwork would not work. Its commits are still ancestors of main through the merge #174 reverted, so git treats them as already applied and a PR from it shows an empty diff. Reverting the revert is the way back, which is what the single commit on this branch does.

What it contains

A sync host the desktop app starts on loopback at launch, plus tcode-server for machines with no display. A wire protocol (docs/sync-protocol.md) where clients send commands and the host streams events, each carrying a per-session sequence number a reconnecting client resumes from. A shared client UI compiled to wasm, Android and iOS — one implementation, three shells — that follows a session, sends turns, and answers approvals. Devices get in with a six-character pairing code, once.

Four CI jobs that actually gate it. The previous workflow proved only that the desktop build worked: client-app is outside the workspace and five other crates compile to empty shells on a host. These build them for their real targets, with no failure suppression.

Known state when parked

	Status
Desktop host, headless host, browser client	Exercised end to end
Android	Links for aarch64-linux-android, all JNI entry points exported. Never run on a device
iOS	Links against the iOS SDK. Never run on a device or simulator

The mobile rows are the open question. Linking proves every symbol GPUI, wgpu, Metal, Vulkan and psm need resolves — which cargo check does not — and is still not the same as having seen a frame. The likely first failure on both is renderer creation meeting real hardware.

docs/remote-and-mobile.md is the user-facing guide; docs/multiplatform-plan.md records the architecture and the approaches rejected along the way.

🤖 Generated with Claude Code

[Tryanks]

Draft — parked for later. This is the multiplatform work from #173, taken back out of main by #174 and held here until we pick it up again.

Nothing was failing. All seven CI jobs were green when #173 merged; it was parked by choice, not by defect.

Why this branch and not the original

Re-merging feat/multiplatform-groundwork would not work. Its commits are still ancestors of main through the merge #174 reverted, so git treats them as already applied and a PR from it shows an empty diff. Reverting the revert is the way back, which is what the single commit on this branch does.

What it contains

A sync host the desktop app starts on loopback at launch, plus tcode-server for machines with no display. A wire protocol (docs/sync-protocol.md) where clients send commands and the host streams events, each carrying a per-session sequence number a reconnecting client resumes from. A shared client UI compiled to wasm, Android and iOS — one implementation, three shells — that follows a session, sends turns, and answers approvals. Devices get in with a six-character pairing code, once.

Four CI jobs that actually gate it. The previous workflow proved only that the desktop build worked: client-app is outside the workspace and five other crates compile to empty shells on a host. These build them for their real targets, with no failure suppression.

Known state when parked

	Status
Desktop host, headless host, browser client	Exercised end to end
Android	Links for aarch64-linux-android, all JNI entry points exported. Never run on a device
iOS	Links against the iOS SDK. Never run on a device or simulator

The mobile rows are the open question. Linking proves every symbol GPUI, wgpu, Metal, Vulkan and psm need resolves — which cargo check does not — and is still not the same as having seen a frame. The likely first failure on both is renderer creation meeting real hardware.

docs/remote-and-mobile.md is the user-facing guide; docs/multiplatform-plan.md records the architecture and the approaches rejected along the way.

🤖 Generated with Claude Code

[Tryanks]

Draft — parked for later. This is the multiplatform work from #173, taken back out of main by #174 and held here until we pick it up again.

Nothing was failing. All seven CI jobs were green when #173 merged; it was parked by choice, not by defect.

Why this branch and not the original

Re-merging feat/multiplatform-groundwork would not work. Its commits are still ancestors of main through the merge #174 reverted, so git treats them as already applied and a PR from it shows an empty diff. Reverting the revert is the way back, which is what the single commit on this branch does.

What it contains

A sync host the desktop app starts on loopback at launch, plus tcode-server for machines with no display. A wire protocol (docs/sync-protocol.md) where clients send commands and the host streams events, each carrying a per-session sequence number a reconnecting client resumes from. A shared client UI compiled to wasm, Android and iOS — one implementation, three shells — that follows a session, sends turns, and answers approvals. Devices get in with a six-character pairing code, once.

Four CI jobs that actually gate it. The previous workflow proved only that the desktop build worked: client-app is outside the workspace and five other crates compile to empty shells on a host. These build them for their real targets, with no failure suppression.

Known state when parked

	Status
Desktop host, headless host, browser client	Exercised end to end
Android	Links for aarch64-linux-android, all JNI entry points exported. Never run on a device
iOS	Links against the iOS SDK. Never run on a device or simulator

The mobile rows are the open question. Linking proves every symbol GPUI, wgpu, Metal, Vulkan and psm need resolves — which cargo check does not — and is still not the same as having seen a frame. The likely first failure on both is renderer creation meeting real hardware.

docs/remote-and-mobile.md is the user-facing guide; docs/multiplatform-plan.md records the architecture and the approaches rejected along the way.

🤖 Generated with Claude Code

[Tryanks]

Draft — parked for later. This is the multiplatform work from #173, taken back out of main by #174 and held here until we pick it up again.

Nothing was failing. All seven CI jobs were green when #173 merged; it was parked by choice, not by defect.

Why this branch and not the original

Re-merging feat/multiplatform-groundwork would not work. Its commits are still ancestors of main through the merge #174 reverted, so git treats them as already applied and a PR from it shows an empty diff. Reverting the revert is the way back, which is what the single commit on this branch does.

What it contains

A sync host the desktop app starts on loopback at launch, plus tcode-server for machines with no display. A wire protocol (docs/sync-protocol.md) where clients send commands and the host streams events, each carrying a per-session sequence number a reconnecting client resumes from. A shared client UI compiled to wasm, Android and iOS — one implementation, three shells — that follows a session, sends turns, and answers approvals. Devices get in with a six-character pairing code, once.

Four CI jobs that actually gate it. The previous workflow proved only that the desktop build worked: client-app is outside the workspace and five other crates compile to empty shells on a host. These build them for their real targets, with no failure suppression.

Known state when parked

	Status
Desktop host, headless host, browser client	Exercised end to end
Android	Links for aarch64-linux-android, all JNI entry points exported. Never run on a device
iOS	Links against the iOS SDK. Never run on a device or simulator

The mobile rows are the open question. Linking proves every symbol GPUI, wgpu, Metal, Vulkan and psm need resolves — which cargo check does not — and is still not the same as having seen a frame. The likely first failure on both is renderer creation meeting real hardware.

docs/remote-and-mobile.md is the user-facing guide; docs/multiplatform-plan.md records the architecture and the approaches rejected along the way.

🤖 Generated with Claude Code

[Tryanks]

Draft — parked for later. This is the multiplatform work from #173, taken back out of main by #174 and held here until we pick it up again.

Nothing was failing. All seven CI jobs were green when #173 merged; it was parked by choice, not by defect.

Why this branch and not the original

Re-merging feat/multiplatform-groundwork would not work. Its commits are still ancestors of main through the merge #174 reverted, so git treats them as already applied and a PR from it shows an empty diff. Reverting the revert is the way back, which is what the single commit on this branch does.

What it contains

A sync host the desktop app starts on loopback at launch, plus tcode-server for machines with no display. A wire protocol (docs/sync-protocol.md) where clients send commands and the host streams events, each carrying a per-session sequence number a reconnecting client resumes from. A shared client UI compiled to wasm, Android and iOS — one implementation, three shells — that follows a session, sends turns, and answers approvals. Devices get in with a six-character pairing code, once.

Four CI jobs that actually gate it. The previous workflow proved only that the desktop build worked: client-app is outside the workspace and five other crates compile to empty shells on a host. These build them for their real targets, with no failure suppression.

Known state when parked

	Status
Desktop host, headless host, browser client	Exercised end to end
Android	Links for aarch64-linux-android, all JNI entry points exported. Never run on a device
iOS	Links against the iOS SDK. Never run on a device or simulator

The mobile rows are the open question. Linking proves every symbol GPUI, wgpu, Metal, Vulkan and psm need resolves — which cargo check does not — and is still not the same as having seen a frame. The likely first failure on both is renderer creation meeting real hardware.

docs/remote-and-mobile.md is the user-facing guide; docs/multiplatform-plan.md records the architecture and the approaches rejected along the way.

🤖 Generated with Claude Code

[Tryanks]

Draft — parked for later. This is the multiplatform work from #173, taken back out of main by #174 and held here until we pick it up again.

Nothing was failing. All seven CI jobs were green when #173 merged; it was parked by choice, not by defect.

Why this branch and not the original

Re-merging feat/multiplatform-groundwork would not work. Its commits are still ancestors of main through the merge #174 reverted, so git treats them as already applied and a PR from it shows an empty diff. Reverting the revert is the way back, which is what the single commit on this branch does.

What it contains

A sync host the desktop app starts on loopback at launch, plus tcode-server for machines with no display. A wire protocol (docs/sync-protocol.md) where clients send commands and the host streams events, each carrying a per-session sequence number a reconnecting client resumes from. A shared client UI compiled to wasm, Android and iOS — one implementation, three shells — that follows a session, sends turns, and answers approvals. Devices get in with a six-character pairing code, once.

Four CI jobs that actually gate it. The previous workflow proved only that the desktop build worked: client-app is outside the workspace and five other crates compile to empty shells on a host. These build them for their real targets, with no failure suppression.

Known state when parked

	Status
Desktop host, headless host, browser client	Exercised end to end
Android	Links for aarch64-linux-android, all JNI entry points exported. Never run on a device
iOS	Links against the iOS SDK. Never run on a device or simulator

The mobile rows are the open question. Linking proves every symbol GPUI, wgpu, Metal, Vulkan and psm need resolves — which cargo check does not — and is still not the same as having seen a frame. The likely first failure on both is renderer creation meeting real hardware.

docs/remote-and-mobile.md is the user-facing guide; docs/multiplatform-plan.md records the architecture and the approaches rejected along the way.

🤖 Generated with Claude Code