ADR 0001: 1.0.0 Support Boundary¶
Status: Accepted for 1.0.0 Date: 2026-08-10 Approved: 2026-08-28 by shawnji, wearing the product, architecture, security, operations and release hats (owner-map.md escalation steps 3-5). This project has one codeowner, so approval and review are the same person; EXC-002 records that deviation and the automated gates that stand in for the second reviewer. Requirements: RC-01, RC-02, RC-03 Decision owners: Product, architecture, security, operations, release
Context¶
The 1.0.0 readiness audit found that public documentation, packaging notes, UI text, and workflows imply broader support than the current evidence proves. Release candidates need one explicit support boundary so implementation slices can either produce evidence for a promise or remove/narrow that promise before release.
Decision¶
Circuit Breaker 1.0.0 will use the conservative support boundary documented in
docs/release/1.0.0-support-contract.md:
- Server support is Linux-only for 1.0.0, with exact distro/version rows promoted only after ACC artifact testing passes.
- Native systemd and Linux Docker Compose are the only supported deployment modes for 1.0.0.
- Proxmox LXC helper support is beta and limited to the helper workflow.
- macOS and Windows are browser/client platforms only. They are not supported server or agent platforms for 1.0.0.
- 1.0.0 is single-node only. High availability is unsupported.
- 1.0.0 is trusted-LAN/VPN first. Direct internet exposure and Cloudflare Tunnel operation remain beta until security acceptance passes.
- Multi-tenancy is not a 1.0.0 security boundary. Separate trust domains require separate deployments.
- IPv4 private-network operation is the supported networking baseline. IPv6 is beta and limited to explicitly tested ULA workflows.
- Air-gapped/offline enrollment and update are unsupported for 1.0.0.
- Public API, SDK, webhook, and metrics schema stability are deferred unless later release-contract slices define and test a stable contract.
Rejected alternatives¶
| Alternative | Reason rejected |
|---|---|
| Claim all platforms produced by packaging code as supported | Build output is not enough; 1.0 support requires install, smoke, upgrade, and failure evidence from artifacts. |
| Claim HA because dependencies can run as separate services | The app lacks a proven multi-process/leader-election/recovery contract for every critical path. |
| Treat tenant fields and UI as multi-tenant support | The audit found tenant isolation is not currently a reliable security boundary. |
| Treat Cloudflare Tunnel documentation as production internet-exposure support | Tunnel setup reduces inbound network exposure, but app hardening, auth, rate-limit, SSRF, and monitoring gates still need release evidence. |
| Claim broad IPv6 support because some UI validation accepts IPv6 ULA prefixes | Full IPv6 support requires discovery, ACL, routing, overlap, and multi-NIC evidence. |
| Promise stable public APIs before documenting compatibility windows | A compatibility policy and contract tests are required before users can depend on API stability. |
Consequences¶
- Public docs must point to the 1.0.0 support contract when describing supported platforms, deployment modes, exposure model, or compatibility.
- Unsupported or beta surfaces may remain in code if they are clearly labeled and do not broaden the 1.0.0 promise.
- Acceptance matrix owners must either provide evidence for a supported row or narrow the contract.
- Release notes must list the known limitations that affect user expectations.
- Future work may expand support through an ADR update plus ACC/AGT evidence.
Migration impact¶
Existing beta users may continue using previously documented workflows, but 1.0.0 support and release-blocking fixes apply only inside the approved boundary. Users relying on unsupported surfaces should either remain on beta/RC builds, run separate deployments for isolation, or wait for a later release that promotes those surfaces.