v0.3

ROADMAP.md

@@ -1,27 +1,3 @@
 # RustProxy roadmap
 
 This file records **work still requiring acceptance or planned future consideration**, rather than repeating completed release history. Implemented functionality is described in the [documentation](docs/README.md), and operator-visible changes by release are in the [changelog](CHANGELOG.md).
-
-## 0.34.1 — outstanding development acceptance
-
-- Build with the project's required Rust toolchain and run the full unit and integration test suite.
-- Verify `--config` concurrent edit rejection, file permissions, atomic writes, migration and restore, plus systemd reload on a running install.
-- Exercise RO/RW API token allowlists and IP/HTTPS enforcement, token revocation, Prometheus rotation/revocation (including legacy environment-token fallback), and unauthorized requests.
-
-## 0.34.0 — outstanding release verification
-
-- Compile the exact 0.34.0 source candidate on the supported target environments and run the current Rust regression suite.
-- Exercise full HTTP/1.1, TLS, HTTP/2, HTTP/3, WebSocket, frontend/backend routing, retry, cache/privacy, certificate and administration scenarios.
-- Test selective HOT/COLD invalidation through configuration edits, restart and persistent cache recovery; verify related regression cases and migration behavior.
-- Verify optional Linux `sendfile=auto` with eligible static files and that all ineligible requests use safe normal delivery.
-- Perform backup/restore and managed install/update acceptance on supported systems, including the container deployment where applicable.
-
-## Longer-term directions
-
-Future work must be tracked separately from shipped features. Potential areas include better operational verification, additional diagnostics/alerting, clearer configuration and migration UX, and compatibility work as HTTP/ACME/runtime dependencies evolve. These are **not commitments or implemented features** without a separately tested release.
-
-## Documentation policy
-
-- Update existing guides when code behavior changes; remove obsolete instructions and avoid version-by-version implementation notes inside functional guides.
-- Keep the changelog technical from an operator's perspective (features, settings, compatibility, defaults, fixes) without Rust allocation/lock/microbenchmark details.
-- Preserve old audit/development evidence in a separate archival package if an engineering investigation requires it, not in the live product Reader.