README.md

@@ -577,22 +577,18 @@ complete annotated example also lives in
 
 ## roadmap
 
-Items still to do before / shortly after 1.0. Loosely ordered by
+Work planned after 1.0. Loosely ordered by priority.
-priority.
 
 ### correctness and operability
 
-* **Security audit of the encryption implementation.** Pre-1.0
+* **Outside security audit.** Before 1.0 the encryption and
-  blocker if we're advertising "secure" at the top of this README.
+  blob-generation code was reviewed: every bug the review found was
-  age + zstd + content-defined chunking is mostly off-the-shelf
+  fixed, and the risks it accepted are listed in
-  pieces, but the seams (key handling, recipient parsing, manifest
+  [Accepted Risks](docs/REPOSTRUCTURE.md#accepted-risks). No outside
-  trust boundary, restore-time identity validation) need an outside
+  audit has been done. age + zstd + content-defined chunking
-  read.
+  is mostly off-the-shelf pieces, but the seams (key handling,
-* **Error-condition tests.** Today's coverage is the happy path
+  recipient parsing, manifest trust boundary, restore-time identity
-  plus a few specific regressions. Need fault-injection coverage:
+  validation) need an outside read.
-  network failures mid-blob, disk-full during restore, corrupted /
-  truncated / missing blobs, partial uploads, kill -9 between
-  manifest and db.zst.age writes.
 * **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
@@ -615,13 +611,15 @@ priority.
   doesn't resume from where it stopped or skip already-present
   files. 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 frequent backups, such as hourly, skip the full scan.
+  It adds little for the usual runs 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.
-* **`--bwlimit` style human-readable size flags** across the
-  command surface where they're currently raw integers.
 * **`vaultik snapshot diff <a> <b>`** — show which files changed
   between two snapshots without restoring either.
 * **Status reporting hook for `--cron`.** When a backup fails

TODO.md

@@ -14,14 +14,11 @@ pre-1.0
 
 # Next Step
 
-Define the remaining scope for the first tagged release under the 1.0.0
+The 1.0 work is complete on `next`: the scope settled on
-milestone, then cut that tag. The mechanism to cut it now exists and is
+[issue #125](https://git.eeqj.de/sneak/vaultik/issues/125) was the work
-exercised; what is left is the scope decision, which is the owner's.
+already planned for 1.0, and all of it has landed. The mechanism to cut
-This step deliberately names one version number: it previously said
+the tag exists and is exercised; what is left is merging `next` to
-"cut v0.1.0" while the `Makefile` baked in `1.0.0-rc.1` and the issue
+`main` and tagging, both the owner's.
-milestone said 1.0.0, and three different answers to "what is the next
-release" is exactly the contradiction
-[issue #65](https://git.eeqj.de/sneak/vaultik/issues/65) was filed over.
 
 # Completed Steps
 
@@ -693,4 +690,5 @@ release" is exactly the contradiction
 
 # Future Steps
 
-None queued; the release-scoping item is now the Next Step.
+Work planned after 1.0 is listed in the README
+[roadmap](README.md#roadmap).