# Local 2×2 route E2E

This harness runs one bot-free control stack plus four isolated data-node
Compose projects. Every data node contains its own qBittorrent, Syncthing, and
archive-client containers and its own bind-mounted config, secrets, state,
backup, qB data, and sync roots. The stacks share only the explicitly named
`archive-control-e2e` network.

The initial scenario starts with no route folders. With the control policy set
to `eager_mesh`, two cache and two archive registrations must produce four
independent, bidirectionally verified Syncthing routes. The assertion talks to
the loopback-only test adapter through a curl sidecar sharing the control
container's network namespace; Telegram is not initialized.

Run from the archive-clients checkout:

```bash
./e2e/scripts/up.sh
./e2e/scripts/logs.sh
./e2e/scripts/down.sh
```

`up.sh` defaults `ARCHIVE_CONTROL_SOURCE` to the sibling playground
`mogic-bot/mogic-repo` checkout. Set that environment variable to test another
control worktree. `E2E_WAIT_SECONDS` overrides the 360-second assertion
deadline. `down.sh` removes only the five exact Compose projects and the
labelled E2E network; it intentionally retains all bind-mounted runtime state.

Set `E2E_RUN_TRANSFER=1` to follow route verification with a real
cache-1 → archive-1 transfer followed by archive-1 → cache-2 unarchive. The
scenario creates a deterministic one-file torrent in the isolated cache
qBittorrent, submits both jobs through the test HTTP adapter, waits for all five
durable steps in each direction, and verifies target qBittorrent selections,
retained source entries, and target file digests.

The Syncthing 2.1.2 and LinuxServer qBittorrent multi-platform image indexes are
digest-pinned. Runtime secrets are generated with mode 0600 and ignored by
Git. The qBittorrent test config limits its authentication bypass to the
isolated E2E network and must never be reused for deployment.