There is no server runtime, SSH host, remote project connection, or boot-mode selection.
This issue depends on shared application services and domain events; CLI provides the headless entry pattern.
Required behavior
Resolve desktop, server, and TUI boot modes without initializing unused UI/runtime components.
Start a headless engine host over the same database, projects, settings, tasks, and engines as desktop.
Generate/store private host-key material with restrictive permissions and manage authorized public keys.
Accept only authenticated SSH clients; reject unknown/revoked keys and unsafe key files with clear errors.
Host remote TUI sessions and the desktop remote-project protocol specified by server.allium.
Carry domain events, task progress, and server-selected locale across client sessions.
Support clean shutdown, client disconnect, reconnect, concurrent clients, and engine errors without corrupting ongoing work.
Add the desktop connection flow for selecting and opening remote projects.
Implementation notes
Read docs/UI_STYLE_GUIDE.md before desktop connection UI work.
Reuse the event bus and application service layer; do not expose the SQLite file or build a second remote domain API.
Bind conservatively by default and make external listening explicit.
Follow red/green TDD, including filesystem permission and authentication tests.
Acceptance criteria
Boot mode tests prove desktop/server/TUI initialize only required components.
Host-key creation, permissions, authorized-key updates, accept/reject/revoke, reconnect, and shutdown are tested.
Two clients observe mutations through ordered domain events without duplicate writes.
Remote desktop project selection and failure states are localized and working.
Server operation never starts the desktop UI.
cargo fmt --all -- --check, cargo build --workspace, and cargo test --workspace pass.
## Goal
Run the shared RuDS application engines without desktop UI and expose authenticated remote sessions for desktop and TUI clients.
## Current state
- specs/server.allium defines boot modes, key material, SSH transport, GUI remote connection, and TUI sessions.
- There is no server runtime, SSH host, remote project connection, or boot-mode selection.
- This issue depends on shared application services and domain events; CLI provides the headless entry pattern.
## Required behavior
- Resolve desktop, server, and TUI boot modes without initializing unused UI/runtime components.
- Start a headless engine host over the same database, projects, settings, tasks, and engines as desktop.
- Generate/store private host-key material with restrictive permissions and manage authorized public keys.
- Accept only authenticated SSH clients; reject unknown/revoked keys and unsafe key files with clear errors.
- Host remote TUI sessions and the desktop remote-project protocol specified by server.allium.
- Carry domain events, task progress, and server-selected locale across client sessions.
- Support clean shutdown, client disconnect, reconnect, concurrent clients, and engine errors without corrupting ongoing work.
- Add the desktop connection flow for selecting and opening remote projects.
## Implementation notes
- Read docs/UI_STYLE_GUIDE.md before desktop connection UI work.
- Reuse the event bus and application service layer; do not expose the SQLite file or build a second remote domain API.
- Bind conservatively by default and make external listening explicit.
- Follow red/green TDD, including filesystem permission and authentication tests.
## Acceptance criteria
- Boot mode tests prove desktop/server/TUI initialize only required components.
- Host-key creation, permissions, authorized-key updates, accept/reject/revoke, reconnect, and shutdown are tested.
- Two clients observe mutations through ordered domain events without duplicate writes.
- Remote desktop project selection and failure states are localized and working.
- Server operation never starts the desktop UI.
- cargo fmt --all -- --check, cargo build --workspace, and cargo test --workspace pass.
Implemented in 45cb0cd. Added the standalone bds-server crate and pre-Iced desktop/server/TUI boot selection; a loopback-by-default Russh host with restrictive generated host/client identities, live authorized_keys reload, public-key-only authentication, TOFU known_hosts verification, restricted forwarding, clean disconnect/reconnect/shutdown, and packaged server binary; a versioned CoreHost remote protocol with project selection, shared task manager, ordered project events, server locale, exactly-once request replay, concurrent clients, and the persisted CLI-notification watcher; and the localized native File-menu connection/project picker with server-locale switching and nonfatal/fatal error handling. The Allium server contract was updated for the native Iced remote protocol and validates cleanly. Neutral review compared the result with issue #26, bDS2 server/remote behavior, and specs/server.allium and found no remaining acceptance gap; the full TUI renderer remains issue #27 while #26 supplies its local/SSH session transport over the same host. Verification: cargo fmt --all -- --check; cargo clippy --workspace --all-targets with warnings denied; cargo build --workspace; cargo test --workspace; Allium check/analyse; real SSH tests for unknown/authorized/revoked keys, permissions, reconnect, two-client ordered events with one write, locale, watcher propagation, and shutdown; and a rebuilt macOS app/DMG with Computer Use verification of the localized native connect and failure states.
Implemented in 45cb0cd. Added the standalone bds-server crate and pre-Iced desktop/server/TUI boot selection; a loopback-by-default Russh host with restrictive generated host/client identities, live authorized_keys reload, public-key-only authentication, TOFU known_hosts verification, restricted forwarding, clean disconnect/reconnect/shutdown, and packaged server binary; a versioned CoreHost remote protocol with project selection, shared task manager, ordered project events, server locale, exactly-once request replay, concurrent clients, and the persisted CLI-notification watcher; and the localized native File-menu connection/project picker with server-locale switching and nonfatal/fatal error handling. The Allium server contract was updated for the native Iced remote protocol and validates cleanly. Neutral review compared the result with issue #26, bDS2 server/remote behavior, and specs/server.allium and found no remaining acceptance gap; the full TUI renderer remains issue #27 while #26 supplies its local/SSH session transport over the same host. Verification: cargo fmt --all -- --check; cargo clippy --workspace --all-targets with warnings denied; cargo build --workspace; cargo test --workspace; Allium check/analyse; real SSH tests for unknown/authorized/revoked keys, permissions, reconnect, two-client ordered events with one write, locale, watcher propagation, and shutdown; and a rebuilt macOS app/DMG with Computer Use verification of the localized native connect and failure states.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Goal
Run the shared RuDS application engines without desktop UI and expose authenticated remote sessions for desktop and TUI clients.
Current state
Required behavior
Implementation notes
Acceptance criteria
Implemented in
45cb0cd. Added the standalone bds-server crate and pre-Iced desktop/server/TUI boot selection; a loopback-by-default Russh host with restrictive generated host/client identities, live authorized_keys reload, public-key-only authentication, TOFU known_hosts verification, restricted forwarding, clean disconnect/reconnect/shutdown, and packaged server binary; a versioned CoreHost remote protocol with project selection, shared task manager, ordered project events, server locale, exactly-once request replay, concurrent clients, and the persisted CLI-notification watcher; and the localized native File-menu connection/project picker with server-locale switching and nonfatal/fatal error handling. The Allium server contract was updated for the native Iced remote protocol and validates cleanly. Neutral review compared the result with issue #26, bDS2 server/remote behavior, and specs/server.allium and found no remaining acceptance gap; the full TUI renderer remains issue #27 while #26 supplies its local/SSH session transport over the same host. Verification: cargo fmt --all -- --check; cargo clippy --workspace --all-targets with warnings denied; cargo build --workspace; cargo test --workspace; Allium check/analyse; real SSH tests for unknown/authorized/revoked keys, permissions, reconnect, two-client ordered events with one write, locale, watcher propagation, and shutdown; and a rebuilt macOS app/DMG with Computer Use verification of the localized native connect and failure states.