| Name | Modified | Size | Downloads / Week |
|---|---|---|---|
| Parent folder | |||
| caprock_0.45.2_windows_amd64.zip | 2026-09-02 | 8.8 MB | |
| caprock_0.45.2_windows_arm64.zip | 2026-09-02 | 8.1 MB | |
| checksums.txt | 2026-09-02 | 600 Bytes | |
| caprock_0.45.2_darwin_amd64.tar.gz | 2026-09-02 | 8.7 MB | |
| caprock_0.45.2_darwin_arm64.tar.gz | 2026-09-02 | 8.3 MB | |
| caprock_0.45.2_linux_amd64.tar.gz | 2026-09-02 | 8.6 MB | |
| caprock_0.45.2_linux_arm64.tar.gz | 2026-09-02 | 8.0 MB | |
| README.md | 2026-09-02 | 748 Bytes | |
| v0.45.2 source code.tar.gz | 2026-09-02 | 5.7 MB | |
| v0.45.2 source code.zip | 2026-09-02 | 6.0 MB | |
| Totals: 10 Items | 62.3 MB | 0 | |
Fixed
- Why a weekly report never arrived is remembered now. The reason a send failed was held in memory, so restarting the daemon erased it — and restarting is exactly what somebody does when a feature seems broken, which made investigating the problem the thing that destroyed the evidence.
This matters more than it sounds because of how the feature fails: a message that stops arriving is an absence, and nobody notices an absence. The settings panel was the only place the reason appeared, and it was empty by the time anyone looked. Telegram's own words — "chat not found", "bot was blocked by the user" — are kept, because both are things only the user can fix, and a week later they are still the answer.
