# Workflow

- branch (from `main`)
- do the work in Next Step
- delete Next Step from `TODO.md`
- move the top item of Future Steps into Next Step
- commit (`TODO.md` changes in the same commit as the work)
- merge to `main` if the branch is not protected, otherwise open a PR
- push

# Status

pre-1.0

# Next Step

Fix the open bugs on the issue tracker that block the release. Merging `next`
into `main` is the owner's.

# Future Steps

Work planned after 1.0, loosely ordered by priority.

## Correctness and operability

- **Outside security audit.** Before 1.0 the encryption and blob-generation code
  was reviewed. Every bug the review found was fixed. The risks it accepted are
  listed in [Accepted risks](REPOSTRUCTURE.md#accepted-risks). No outside audit
  has been done. age, zstd and content-defined chunking are mostly off-the-shelf
  pieces. The code that joins them needs an outside read:
    - key handling
    - recipient parsing
    - manifest trust boundary
    - restore-time identity validation
- **Verify restored content end-to-end in CI.** The current integration test
  does this for a small synthetic snapshot but not at scale. A nightly job
  against a multi-GB representative snapshot would catch silent regressions in
  the chunker, packer, or restore planner.

## Performance

- **Parallel blob downloads during restore.** A restore downloads one blob at a
  time now. With a fast S3 endpoint and a multi-core machine, restore speed is
  bound by the fetch, decryption and decompression of each blob. Running several
  of those in parallel against the disk cache would close most of the remaining
  gap. This needs to interact correctly with the locality planner and the
  sweeper.
- **Bandwidth limiting (`--bwlimit`).** For both upload and download. It is
  useful for backing up over a shared link. It is tricky to make work correctly
  with parallel downloads.
- **Restart of interrupted restore.** Today a restore can be started again, and
  it then overwrites the partial output. It does not resume from where it
  stopped, and it does not skip files that are already present. A `--resume`
  mode that checks targets before fetching blobs would matter for very large
  restores.
- **Daemon mode.** A long-running mode that watches for file changes, so that
  frequent backups, such as hourly ones, skip the full scan. It adds little for
  the usual backups from cron every 12 to 36 hours. See
  [issue #204](https://git.eeqj.de/sneak/vaultik/issues/204).

## Usability

- **Man pages and richer `--help` examples.** Cobra generates basic help. Man
  pages would be a separate target.
- **`vaultik snapshot diff <a> <b>`.** Show which files changed between two
  snapshots, without restoring either.
- **Status reporting hook for `--cron`.** When a backup fails silently in cron,
  the user has no idea. A configurable hook on completion, for both success and
  failure, would close the loop. It could be a webhook, an email or
  `notify-send`.

## Infrastructure

- **Schema migrations after 1.0.** Migrations are supported, but none are added
  before 1.0 because there is no installed base yet. After 1.0, each schema
  change is a new migration, so an existing local index is migrated when
  `vaultik` is updated. See [`DATAMODEL.md`](DATAMODEL.md#schema-migrations).
- **Storage backend coverage tests.** S3, `file://` and `rclone://` all share
  the `Storer` interface, but the rclone path is the least exercised in CI.