(docs) Move 1.0 roadmap tracking to Gitea

Create the 1.0 milestone and roadmap issues in Gitea, making Gitea the
leading tracker for release work.

Remove the repository roadmap document and README reference now that the
roadmap is tracked as milestone issues.

README.md

@@ -185,7 +185,3 @@ systemctl status pobsync-web pobsync-worker pobsync-scheduler
 Development, Docker, maintainer tooling, and architecture notes live in:
 
 - [docs/development.md](docs/development.md)
-
-The 1.0 delivery roadmap is tracked in:
-
-- [docs/roadmap-1.0.md](docs/roadmap-1.0.md)

docs/roadmap-1.0.md

@@ -1,112 +0,0 @@
-# pobsync 1.0 Roadmap
-
-This roadmap tracks the remaining chunks before a 1.0 release. Keep chunks scoped and commit them separately. When a
-chunk is completed, mark it as done here and include the final commit message in the review notes.
-
-## 1. Production Install And Update Flow
-
-Goal: installing and updating pobsync should be predictable without needing to remember Django environment details.
-
-- [ ] Add a `pobsync-manage` wrapper that loads `/etc/pobsync/pobsync.env` before running Django management commands.
-- [ ] Add or document an explicit update flow for native systemd installs.
-- [ ] Make update output quiet by default and verbose only with a flag.
-- [ ] Extend Self Check with env file, database path, service user, backup root ownership, and service runtime checks.
-- [ ] Document install, update, rollback, restart, and log inspection in the README.
-
-Suggested commit tag: `(feature)` or `(ops)`
-
-## 2. Run Detail And Logging Polish
-
-Goal: a failed or slow backup should be debuggable from Django without shell access.
-
-- [ ] Split run detail into clear sections: summary, command, log, stats, retention, and raw result.
-- [ ] Show recent rsync log output inline with a link to the full log.
-- [ ] Show failure classification prominently when available.
-- [ ] Surface prune/retention warnings as a first-class panel instead of only JSON.
-- [ ] Improve log filtering by service, host, run, severity, and time window.
-
-Suggested commit tag: `(ui)` or `(feature)`
-
-## 3. Backup Safety And Preflight Validation
-
-Goal: catch bad configuration before a real backup starts.
-
-- [ ] Add preflight checks for SSH reachability, remote rsync availability, source root existence, and key selection.
-- [ ] Add per-host effective config preview for source root, SSH, rsync args, includes, excludes, and retention.
-- [ ] Warn for dangerous or confusing combinations, such as backing up `/` without root-level excludes.
-- [ ] Make dry-run summaries easier to read: files seen, transfer estimate, warnings, and log link.
-- [ ] Keep real backup actions gated by clear state: ready, warning, or blocked.
-
-Suggested commit tag: `(feature)`
-
-## 4. Retention UX And Safety
-
-Goal: pruning should be transparent, safe, and understandable.
-
-- [ ] Improve the retention plan view with keep/delete reasons.
-- [ ] Highlight when a planned deletion exceeds `prune_max_delete`.
-- [ ] Show whether base snapshots are protected and why.
-- [ ] Make retention warnings visible on dashboard, host detail, and run detail.
-- [ ] Keep manual retention apply flow explicit with host confirmation.
-
-Suggested commit tag: `(ui)` or `(feature)`
-
-## 5. Dashboard 1.0
-
-Goal: the dashboard should be a useful operational starting point.
-
-- [ ] Polish host cards for scanability and mobile layout.
-- [ ] Show running, queued, warning, and failed states more clearly.
-- [ ] Separate "last good backup" from "latest failed/warning run".
-- [ ] Make disk usage and growth estimates easier to interpret.
-- [ ] Improve empty states for fresh installs.
-
-Suggested commit tag: `(ui)`
-
-## 6. Restore Story
-
-Goal: pobsync 1.0 should clearly explain how to restore data.
-
-- [ ] Document manual restore from snapshot directories.
-- [ ] Add snapshot detail restore guidance with source and destination examples.
-- [ ] Include rsync restore command examples using the selected snapshot.
-- [ ] Explain hardlinks/link-dest implications for restores.
-- [ ] Defer automatic restore execution unless the manual story is solid.
-
-Suggested commit tag: `(docs)` or `(feature)`
-
-## 7. Config Cleanup And Legacy Removal
-
-Goal: Django/systemd should be the primary mental model, with old CLI concepts minimized.
-
-- [ ] Remove or hide remaining legacy config language from the README and UI.
-- [ ] Keep management commands only where useful for operations, automation, or debugging.
-- [ ] Normalize labels: service user, SSH user, source root, backup root, schedule expression, retention.
-- [ ] Keep Docker documented as development/test tooling, not the primary production path.
-- [ ] Review old command aliases and decide which stay for compatibility.
-
-Suggested commit tag: `(refactor)` or `(docs)`
-
-## 8. Release Hardening
-
-Goal: ship 1.0 only after install, update, backup, retention, and restore flows have been exercised.
-
-- [ ] Run the full test suite.
-- [ ] Fresh install on a clean VM/server.
-- [ ] Upgrade test from the current production install.
-- [ ] Confirm scheduled backup, manual backup, dry-run, cancellation, retention, log view, and dashboard.
-- [ ] Add or update `CHANGELOG.md`.
-- [ ] Set package/application version to `1.0.0`.
-- [ ] Tag the release.
-
-Suggested commit tag: `(release)`
-
-## Gitea Tracking Option
-
-This file is the canonical roadmap in the repository. It can be mirrored into Gitea later as:
-
-- one `1.0` milestone
-- one issue per roadmap chunk
-- optional child issues for each checkbox
-
-If Gitea API access is available, the roadmap can be converted into issues with a small script or manual API calls.