docs: publish archive control design set

docs/README.md

@@ -0,0 +1,41 @@
+# Archive Control design documentation
+
+This directory is the implementation contract for Archive Control. These
+documents incorporate the decisions made during the design review and
+supersede conflicting details in the original private problem statement. That
+statement is intentionally not published because it contains deployment
+credentials and host-specific details.
+
+## Reading order
+
+1. [Decisions](decisions.md)
+2. [Implementation plan](implementation-plan.md)
+3. [System design](system-design.md)
+4. [Resource and workflow model](workflows.md)
+5. [Daemon protocol](protocol.md)
+6. [Storage safety and recovery](storage-safety.md)
+7. [qBittorrent and Syncthing integration](service-apis.md)
+8. [Configuration, deployment, and usage](deployment-and-usage.md)
+9. [Telegram UX](telegram-ux.md)
+10. [Testing strategy](testing.md)
+
+The independent protobuf source of truth lives in the
+`cabbage/archive-control-proto` repository. Generated bindings in this
+repository record the exact source commit.
+
+## Implementation status
+
+As of 2026-07-23, implementation phases 0–7 are complete across the proto,
+control, and client repositories. This includes registration, recovery,
+on-demand inventory, automatic route provisioning, transfer preview and delta
+planning, selective archive/unarchive merging, durable execution and
+compensation, safe cache eviction, database backup/restore, and the integrated
+Telegram flows.
+
+The local 2×2 topology passes archive, eviction, and unarchive happy paths plus
+selective/partial merges, multiple archive coverage, restart/replay,
+pure-v2/hybrid identities, stalls, disk exhaustion, hostile preconditions, and
+protocol duplication/reordering. The integrated bot also has an isolated dummy
+backend for interactive Telegram conversation review and trace export.
+Remaining work is the broader release/chaos matrix and the separately approved
+staged deployment described in phases 8–9.