pobsync/docs/roadmap-1.0.md

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.