ADR-008, from docs/DECISIONS.md in the QuantyKube repository.
Status Partly superseded by ADR-027.
Its date is superseded by ADR-027: Raft is attempted before 17 November. How it is built stands.
Multiple store nodes with Raft are the goal of the next phase, not of the first demonstration. ADR-001 stands for that date.
Raft is short on paper and notoriously hard to get right in practice. The failures that matter, a lost acknowledged write or two leaders at once, appear only under particular interleavings of crashes, partitions and delays, and a demonstration date is the wrong pressure to build that under. The weeks before it are already filled by HTTP/2, gRPC and Watch, which everything else depends on. Raft also needs a transport between the store nodes, and across machines that transport needs TLS, which QuantyCore does not have yet.
How it will be built. The measuring instrument first: a deterministic simulator in which several nodes run in one process against a simulated network and simulated disks, with time, message order, loss, partitions and crashes all driven by a seed. Any failure is reproduced exactly from its seed. Only when the simulator can find planted bugs is the protocol written against it.
Until then, high availability comes from a PostgreSQL backend (ADR-006), the way k3s gets it from kine.
The cost: the first thing many companies will ask about, a highly available store, is answered on 17 November with a plan and not with a running system, and the talk has to say so.