ADR process

Write an ADR when a change picks one of several real options and the team would be confused six months later. Examples that already qualified: the edge gateway, the event transport, where the relay runs.

Do not write an ADR for a bugfix, a new endpoint that follows an existing pattern, or a library bump.

1. Copy the template. Use the next number.
2. Status Proposed until the change is merged.
3. Put the same file in splick-backend/docs/adr/ when the decision lives in the backend, so older links keep working.
4. Link the ADR from the architecture or service page that would otherwise state the decision as an unexplained fact.
5. Supersede by name. Do not delete the old ADR. Set its status line to point at the new one.

The English pages on this site are the ones new readers should open. If you change a decision, edit both copies or replace the backend file with a short pointer. Leaving them in conflict is how phase-1 Pub/Sub instructions survived past phase 3.