# 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.