ADR Process

An ADR captures one decision that had real alternatives: the context, the options weighed, the choice, and its consequences — so future maintainers (including us, later) don’t re-litigate or accidentally reverse it blind.

Process

1. Copy 0000-template.md → NNNN-short-slug.md (next free number), status proposed.
2. Discuss in the PR; land it proposed if implementation must wait for evidence (spikes), or accepted when decided.
3. Accepted ADRs are immutable. Changing course = a new ADR with Supersedes: NNNN (and the old one gains Superseded-by).
4. Small reversible choices don’t need an ADR. Anything expensive to reverse — protocol shapes, licenses, platform commitments — does.

Index

ADR	Title	Status
0001	WebRTC + GStreamer for media transport	accepted
0002	Ubuntu 24.04 / GStreamer 1.24 baseline	accepted
0003	Polyglot monorepo	accepted
0004	Rust for the signaling server	accepted
0005	TS core + React bindings + demo split	accepted
0006	Desktop backend selection	proposed (M2 spikes)
0007	webrtcbin+FrameHub vs webrtcsink	proposed (M1 spike)
0008	DataChannel topology & reliability classes	accepted
0009	Privilege separation on the robot	proposed
0010	Devcontainer + compose + Xvfb robot-sim	accepted
0011	AGPL-3.0 open core + commercial licensing	accepted
0012	Agent in C++	accepted
0013	WebSocket signaling with a transport seam	accepted
0014	Astro + Starlight for the website	accepted
0015	Backend integration: unified contract, sidecar + managed twin	accepted
0016	SWUpdate as the OTA foundation	proposed (M8)
0017	libsoup-3 for agent networking	accepted