Add docs/adr/ with a chronological ADR set reconstructed from the project history (no orchestrator, one storage format, derived-state sync, SQL-over-SSH contract, WireGuard beneath SSH, IaC boundaries, non-root image, runtime data paths, bounded lake scans), an index README, and a template. Distinguish repo-local ADRs from ecosystem-wide ASRs. Expand AGENTS.md with a decision-records section and a runtime/operations guide (service URLs, rebuild workflow, CPU budget knobs). Reference the ADRs from README, CONTRIBUTING, and the affected design docs, and add an open question for T1 partition pruning.
1.7 KiB
1.7 KiB
ADR-0001: No swarm-wide orchestrator; coordinate through data
Status
Accepted (2026-07-08)
Context
The fleet flies fully autonomously with no internet uplink and only intermittent mesh connectivity between drones. A conventional control plane (Kubernetes across the swarm, a leader election, a central scheduler) assumes stable membership and low-latency links — exactly what a swarm does not have. Partitions are the normal case, not the exception.
Options
| Option | Pros | Cons |
|---|---|---|
| A — Cluster orchestrator spanning the swarm | Familiar tooling | Assumes stable membership; a partition stalls coordination; single point of failure in the air |
| B — Each drone autonomous, coordinating through exchanged data | Survives partitions; no air-side control plane to fail | No global view; behaviour must be derivable from local state |
Decision
Every drone is an autonomous node. There is no orchestrator spanning the swarm. Coordination happens by exchanging derived state (see ADR-0003), and each drone makes its own in-flight decisions against its local data window. Orchestration tooling (Kubernetes, Flux) is confined to the ground segment (ADR-0006).
Consequences
- The platform degrades gracefully under partition: a drone that loses peers keeps flying and recording.
- There is no single "fleet state" to query in the air; health questions are answered from each drone's own store and reconciled on the ground.
- Design principle 1 in
../../README.mdand the on-board model in../02-architecture.mdfollow from this.