damacus
## Problem `paperless status` is presented as a status command, but it silently performs a live multi-endpoint operational report: - `GET /api/status/` - `GET /api/statistics/` - `GET /api/tasks/` The implementation in `src/services.rs` builds the status payload by calling `ping`, fetching statistics, and listing tasks. In production this emitted roughly 15,000 lines of live task/history data during a routine health check. This is a safety and usability problem for automation: a health probe should not enumerate operational data, create huge logs, or unexpectedly consume API capacity. ## Reproduction 1. Configure a live Paperless instance. 2. Run: ```console paperless status ``` 3. Observe requests to the status, statistics, and tasks endpoints, plus a large combined response. ## Expected - `paperless status` is a compact, single-purpose health/auth probe, using only `GET /api/status/` (or similarly minimal endpoint). - A separate explicit command, such as `paperless dashboard` or `paperless report`, may fetch statistics and tasks. - All help paths (`paperless --help`, `paperless help …`, and `<command> --help`) must be guaranteed network-free. ## Acceptance criteria - Add an integration test with a mock server proving `paperless status` does not call `/api/statistics/` or `/api/tasks/`. - Add tests proving help paths make no HTTP requests, even when a configured URL is present. - Keep any full operational overview behind an explicit command. - Document the request behavior of `status` and the full overview command.