Squadron Control grows an operations layer
Written by The LynxDock Team, Engineering, LynxDock
Squadron Control is the reason LynxDock exists: a tactical operations center in the same app as your comms, not a chat sidebar with a whiteboard bolted on. The V2 rebuild finally gave it the foundation it deserved - a protocol-first Rust server, a typed event stream, and a client that reconciles to server truth - and once that spine existed, the features came fast. This post covers the stretch that took the board from empty to operational.
The spine first. Every tactical entity - units, wings, objectives, orders, alerts, zones, connections, sketch strokes, routes - lives in the Rust protocol crate as a typed, versioned object with a server-authoritative revision. The TypeScript client types are generated from Rust, so the two sides cannot drift. Mutations are RPCs that persist, then broadcast on the board's own event stream; every client applies the same reducer, so duplicates are idempotent and stale updates lose by revision. When a client detects a gap in the sequence, it resyncs from a snapshot. That one pattern - persist, broadcast, reduce, resync - is behind everything below.
Then the operational surface. Units carry roles and readiness states; wings group them with color and a live readiness roll-up. Objectives, C2 orders with an issued-to-acked-to-done lifecycle, and categorized alerts cover the command loop. Zones paint the map; formations and a zero-dependency command-tree auto-layout arrange it. Ephemeral signals - pings, unit callouts, commander broadcasts - flash across every connected client without ever touching the database. A situation card summarizes the whole operation at a glance.
History became a first-class feature. Every mutation lands in a permanent per-board audit log, which bought us three things at once: sequence numbers that survive server restarts, named snapshots you can save and restore (restores flow through the normal event stream, so live clients converge without a special path), and time-travel replay - a scrubber that reconstructs the exact board state at any point in its history, read-only, with a one-click return to live. Mission templates fell out of the same machinery: stamp any snapshot into a fresh board with new identities and remapped references.
Undo was the hardest correctness problem. Server-side inverse mutations: every operation records its inverse group as it executes, so undoing a unit deletion restores not just the unit but the command edges and wing memberships that were cascaded away with it - as one keystroke. Redo swaps stacks symmetrically. It took a prefix-routed application engine and careful revision bumping to make every restore win last-writer-wins on every client, and it's covered by round-trip tests on both sides of the wire.
Then we changed what the lines mean. Connector edges were graph theory; operations think in movement. The operations layer replaces relationship lines with routes: first-class mission objects with unlimited waypoints, per-kind military styling and direction animation, and vector-style editing - drag a waypoint, click a segment to insert one, split, fork, merge, reverse. Squads advance waypoint by waypoint; completed legs go green, the current waypoint pulses, and a commander panel rolls up every route's progress without anyone asking over voice. All of it undoable, all of it in the audit log, all of it replayable.
One interaction framework drives it all. Every object on the canvas answers to a single action registry, surfaced three ways - right-click context menu, radial pie menu, and a command palette - with hotkeys and undo coming from the same source of truth, so the surfaces can't drift apart. A capability-based permission model evaluates authority on the server and mirrors it client-side for instant feedback, returning readable denials instead of silent failures.
None of this is a demo path. It went through the same discipline as the networking layer before it: workspace-wide test gates, multi-client live verification with deliberate wreck-and-restore passes, a stress harness for large boards, and a written record of what was verified and when. The board that appears in the screenshots on this site is staged demo data - but the synchronization underneath it is the real thing, watched working.
LynxDock is in active development. Squadron Control's operations layer is the current frontier - telemetry-driven live unit positions and multi-altitude route planning are speced next - and the whole platform remains what it set out to be: one process, one database file, on hardware your organization owns.