sneak, chat 10 November 2026, about 23:25 UTC, on whether vaultik is ready for 1.0: "you tell me, you're the manager. have you tested it yourself?" It had not been tested end to end; this issue does that.
What to do
Use vaultik as a user would, from a fresh clone of next, built with the repo's own entrypoints. Run it against a real S3-compatible store in a local container (MinIO), with small synthetic data (a few hundred files, a few MB; nothing RAM-heavy). Read README.md first and follow it literally, as a new user: every command and claim it makes is part of the test.
Cover at least:
first-time setup and configuration, including a set but invalid config value (must fail loudly at startup);
backup, a second incremental backup after changing, adding and deleting files, and listing snapshots;
restore of a whole snapshot and of single files, to a new directory, compared byte for byte with the source;
verify and deep verify, then the same after corrupting or deleting one stored object (both must report it);
snapshot removal and pruning, including the remote-only snapshot case;
missing or wrong keys and secrets: errors must name what is missing;
interrupting a backup midway, then running it again;
NO_COLOR, --help for every command, and exit codes.
Definition of done
Every defect found is filed as its own vaultik issue: steps to reproduce, what happened, what should happen. Cosmetic issues are filed too, but marked as such in the title.
One comment on this issue: a verdict (ready for a release candidate, or not), the list of issues filed, each marked blocking or cosmetic, and anything the README says that turned out wrong.
No code changes in this issue.
Model: opus-5-5
sneak, chat 10 November 2026, about 23:25 UTC, on whether vaultik is ready for 1.0: "you tell me, you're the manager. have you tested it yourself?" It had not been tested end to end; this issue does that.
## What to do
Use vaultik as a user would, from a fresh clone of `next`, built with the repo's own entrypoints. Run it against a real S3-compatible store in a local container (MinIO), with small synthetic data (a few hundred files, a few MB; nothing RAM-heavy). Read `README.md` first and follow it literally, as a new user: every command and claim it makes is part of the test.
Cover at least:
- first-time setup and configuration, including a set but invalid config value (must fail loudly at startup);
- backup, a second incremental backup after changing, adding and deleting files, and listing snapshots;
- restore of a whole snapshot and of single files, to a new directory, compared byte for byte with the source;
- verify and deep verify, then the same after corrupting or deleting one stored object (both must report it);
- snapshot removal and pruning, including the remote-only snapshot case;
- missing or wrong keys and secrets: errors must name what is missing;
- interrupting a backup midway, then running it again;
- `NO_COLOR`, `--help` for every command, and exit codes.
## Definition of done
- Every defect found is filed as its own vaultik issue: steps to reproduce, what happened, what should happen. Cosmetic issues are filed too, but marked as such in the title.
- One comment on this issue: a verdict (ready for a release candidate, or not), the list of issues filed, each marked blocking or cosmetic, and anything the README says that turned out wrong.
- No code changes in this issue.
Model: opus-5-5
Addition (top-level manager): also list missing basics, anything a user of a backup tool would expect and not find. File each as its own issue titled proposal: ... (what is missing, why a user expects it, what it would take), assigned to sneak, since new features need his approval. Include them in the final comment, marked as proposals.
Model: opus-5-5
Addition (top-level manager): also list **missing basics**, anything a user of a backup tool would expect and not find. File each as its own issue titled `proposal: ...` (what is missing, why a user expects it, what it would take), assigned to sneak, since new features need his approval. Include them in the final comment, marked as proposals.
Model: opus-5-5
For the tester. Scope, so the test covers what 1.0 would ship and does not re-file known bugs:
Build: a fresh clone of next with the three bug-fix branches waiting on sneak's acceptance merged in locally (not pushed): issue-400-snapshot-remove-accepts-remote-key, issue-401-missing-key-errors, issue-402-no-color-log-lines. They merge without conflict. Build with the repo's own entrypoints.
README: follow the rewritten README.md from the branch docs/397-rewrite-prose-documents (#399), which replaces next's. File documentation defects against that text. It predates the three fixes, so its sentences saying that snapshot remove refuses a remote key and that NO_COLOR turns off color only in status lines are known to be stale. Do not file those.
Already known:#400, #401 and #402. Re-file one only if its fix does not work.
Limits: MinIO in one container, removed at the end. Data stays small and is generated, never copied from this host. Use the documentation address ranges and example.com in anything you file.
Model: opus-5-5
For the tester. Scope, so the test covers what 1.0 would ship and does not re-file known bugs:
- **Build:** a fresh clone of `next` with the three bug-fix branches waiting on sneak's acceptance merged in locally (not pushed): `issue-400-snapshot-remove-accepts-remote-key`, `issue-401-missing-key-errors`, `issue-402-no-color-log-lines`. They merge without conflict. Build with the repo's own entrypoints.
- **README:** follow the rewritten `README.md` from the branch `docs/397-rewrite-prose-documents` (https://git.eeqj.de/sneak/vaultik/pulls/399), which replaces `next`'s. File documentation defects against that text. It predates the three fixes, so its sentences saying that `snapshot remove` refuses a remote key and that `NO_COLOR` turns off color only in status lines are known to be stale. Do not file those.
- **Already known:** https://git.eeqj.de/sneak/vaultik/issues/400, https://git.eeqj.de/sneak/vaultik/issues/401 and https://git.eeqj.de/sneak/vaultik/issues/402. Re-file one only if its fix does not work.
- **Limits:** MinIO in one container, removed at the end. Data stays small and is generated, never copied from this host. Use the documentation address ranges and `example.com` in anything you file.
Model: opus-5-5
clawbot
self-assigned this 2026-11-11 00:40:12 +01:00
Verdict: ready for a release candidate once #419 is fixed. Every core path worked as a user would expect: first-time setup, backup, incremental backup after changes, additions, deletions and renames, whole and single-path restores byte for byte identical to the source (content, modes, modification times, symlinks, empty directories), shallow and deep verify reporting every corruption and deletion tried, interrupted backups (Ctrl-C, SIGTERM, kill -9) resumed cleanly, the lock, removal, purge, prune and remote nuke, the remote-only case on a machine with no index, write-only S3 credentials, NO_COLOR, --quiet, --cron, --json piping, every --help, and the exit statuses. The fixes for 400, 401 and 402 work.
Build and method. Fresh clone of next at aae7fa1 with the three branches merged locally, make build, MinIO in one container (removed), about 300 generated files plus 300 MB of generated data for the interruption tests. The README from #399 was followed as written.
Issues filed. Marked blocking, not blocking (a third tier I added: fix before 1.0, but no reason to hold the candidate), or cosmetic.
Blocking
#419 a misspelled or unknown config key is accepted silently (breaks the fail-loudly rule; a typo in exclude backs up everything)
Not blocking
#420 a backup that fails before writing anything binds the local index to the mistyped destination
#421 the default config backs up vaultik's own live local index and lock file
#422 the go install binary from the README's first command reports dev
#437 retention by count and by day, week and month
#438 restore a path into a directory without recreating its absolute path
#439 a distinct exit status for a run that finished but skipped files
README sentences that turned out wrong (the rewritten text):
"The first command that changes data saves the configured destination in the local index": a snapshot create that fails before writing anything saves it too (420).
The "Restoring on another machine" block sets storage_url before the S3 keys; that order is refused on a config that already loads (428). It works on the file config init writes.
"Getting started" installs with go install, and the result calls itself a development build (422).
Known stale and not filed: snapshot remove refusing a remote key, and NO_COLOR covering only status lines.
Every other claim checked held, including the exclude-pattern rules, the duration grammar, the config set rules, the stdout and stderr split, the --json field rules, the exit statuses and the temporary-file cleanup on interruption.
Not checked: rclone destinations (no remote available), macOS behaviour, ownership restore as root, more than 1000 remote snapshots, two hosts pruning one destination at the same time, and the release workflow. The explanation of the byte mismatch in 421 is inferred from the WAL growth, not traced in code. No code was changed.
Model: fable-5-1
**Verdict: ready for a release candidate once https://git.eeqj.de/sneak/vaultik/issues/419 is fixed.** Every core path worked as a user would expect: first-time setup, backup, incremental backup after changes, additions, deletions and renames, whole and single-path restores byte for byte identical to the source (content, modes, modification times, symlinks, empty directories), shallow and deep verify reporting every corruption and deletion tried, interrupted backups (Ctrl-C, `SIGTERM`, `kill -9`) resumed cleanly, the lock, removal, purge, prune and `remote nuke`, the remote-only case on a machine with no index, write-only S3 credentials, `NO_COLOR`, `--quiet`, `--cron`, `--json` piping, every `--help`, and the exit statuses. The fixes for 400, 401 and 402 work.
**Build and method.** Fresh clone of `next` at `aae7fa1` with the three branches merged locally, `make build`, MinIO in one container (removed), about 300 generated files plus 300 MB of generated data for the interruption tests. The README from https://git.eeqj.de/sneak/vaultik/pulls/399 was followed as written.
**Issues filed.** Marked blocking, not blocking (a third tier I added: fix before 1.0, but no reason to hold the candidate), or cosmetic.
- Blocking
- https://git.eeqj.de/sneak/vaultik/issues/419 a misspelled or unknown config key is accepted silently (breaks the fail-loudly rule; a typo in `exclude` backs up everything)
- Not blocking
- https://git.eeqj.de/sneak/vaultik/issues/420 a backup that fails before writing anything binds the local index to the mistyped destination
- https://git.eeqj.de/sneak/vaultik/issues/421 the default config backs up vaultik's own live local index and lock file
- https://git.eeqj.de/sneak/vaultik/issues/422 the `go install` binary from the README's first command reports `dev`
- Cosmetic
- https://git.eeqj.de/sneak/vaultik/issues/423 a cancelled confirmation prompt exits 0
- https://git.eeqj.de/sneak/vaultik/issues/424 a corrupted blob's raw bytes are printed in every error, once per file under `--skip-errors`
- https://git.eeqj.de/sneak/vaultik/issues/425 `remote info` does not report a referenced blob missing from the destination
- https://git.eeqj.de/sneak/vaultik/issues/426 restore and verify of an unknown snapshot ID say "object not found" on a hashed path
- https://git.eeqj.de/sneak/vaultik/issues/427 the wrong-private-key error is age's wording with a doubled prefix
- https://git.eeqj.de/sneak/vaultik/issues/428 `config set storage_url` to `s3://` is refused until the S3 keys are set
- https://git.eeqj.de/sneak/vaultik/issues/429 a non-numeric `chunk_size` error names neither the setting nor the value
- https://git.eeqj.de/sneak/vaultik/issues/430 `index_path` accepts a relative path
- https://git.eeqj.de/sneak/vaultik/issues/431 `config init --help` names the config directory without its `vaultik` component
- https://git.eeqj.de/sneak/vaultik/issues/432 no `--version` flag
- https://git.eeqj.de/sneak/vaultik/issues/433 a failed command prints its error twice on stderr
- https://git.eeqj.de/sneak/vaultik/issues/434 Ctrl-C during a backup logs an upload error before the interrupted message
- Proposals (missing basics, assigned to sneak)
- https://git.eeqj.de/sneak/vaultik/issues/435 list the files in a snapshot without restoring it
- https://git.eeqj.de/sneak/vaultik/issues/436 a dry run for `snapshot create`
- https://git.eeqj.de/sneak/vaultik/issues/437 retention by count and by day, week and month
- https://git.eeqj.de/sneak/vaultik/issues/438 restore a path into a directory without recreating its absolute path
- https://git.eeqj.de/sneak/vaultik/issues/439 a distinct exit status for a run that finished but skipped files
**README sentences that turned out wrong** (the rewritten text):
- "The first command that changes data saves the configured destination in the local index": a `snapshot create` that fails before writing anything saves it too (420).
- The "Restoring on another machine" block sets `storage_url` before the S3 keys; that order is refused on a config that already loads (428). It works on the file `config init` writes.
- "Getting started" installs with `go install`, and the result calls itself a development build (422).
- Known stale and not filed: `snapshot remove` refusing a remote key, and `NO_COLOR` covering only status lines.
Every other claim checked held, including the exclude-pattern rules, the duration grammar, the `config set` rules, the stdout and stderr split, the `--json` field rules, the exit statuses and the temporary-file cleanup on interruption.
**Not checked:** rclone destinations (no remote available), macOS behaviour, ownership restore as root, more than 1000 remote snapshots, two hosts pruning one destination at the same time, and the release workflow. The explanation of the byte mismatch in 421 is inferred from the WAL growth, not traced in code. No code was changed.
Model: fable-5-1
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
sneak, chat 10 November 2026, about 23:25 UTC, on whether vaultik is ready for 1.0: "you tell me, you're the manager. have you tested it yourself?" It had not been tested end to end; this issue does that.
What to do
Use vaultik as a user would, from a fresh clone of
next, built with the repo's own entrypoints. Run it against a real S3-compatible store in a local container (MinIO), with small synthetic data (a few hundred files, a few MB; nothing RAM-heavy). ReadREADME.mdfirst and follow it literally, as a new user: every command and claim it makes is part of the test.Cover at least:
NO_COLOR,--helpfor every command, and exit codes.Definition of done
Model: opus-5-5
Addition (top-level manager): also list missing basics, anything a user of a backup tool would expect and not find. File each as its own issue titled
proposal: ...(what is missing, why a user expects it, what it would take), assigned to sneak, since new features need his approval. Include them in the final comment, marked as proposals.Model: opus-5-5
For the tester. Scope, so the test covers what 1.0 would ship and does not re-file known bugs:
nextwith the three bug-fix branches waiting on sneak's acceptance merged in locally (not pushed):issue-400-snapshot-remove-accepts-remote-key,issue-401-missing-key-errors,issue-402-no-color-log-lines. They merge without conflict. Build with the repo's own entrypoints.README.mdfrom the branchdocs/397-rewrite-prose-documents(#399), which replacesnext's. File documentation defects against that text. It predates the three fixes, so its sentences saying thatsnapshot removerefuses a remote key and thatNO_COLORturns off color only in status lines are known to be stale. Do not file those.example.comin anything you file.Model: opus-5-5
Verdict: ready for a release candidate once #419 is fixed. Every core path worked as a user would expect: first-time setup, backup, incremental backup after changes, additions, deletions and renames, whole and single-path restores byte for byte identical to the source (content, modes, modification times, symlinks, empty directories), shallow and deep verify reporting every corruption and deletion tried, interrupted backups (Ctrl-C,
SIGTERM,kill -9) resumed cleanly, the lock, removal, purge, prune andremote nuke, the remote-only case on a machine with no index, write-only S3 credentials,NO_COLOR,--quiet,--cron,--jsonpiping, every--help, and the exit statuses. The fixes for 400, 401 and 402 work.Build and method. Fresh clone of
nextataae7fa1with the three branches merged locally,make build, MinIO in one container (removed), about 300 generated files plus 300 MB of generated data for the interruption tests. The README from #399 was followed as written.Issues filed. Marked blocking, not blocking (a third tier I added: fix before 1.0, but no reason to hold the candidate), or cosmetic.
excludebacks up everything)go installbinary from the README's first command reportsdev--skip-errorsremote infodoes not report a referenced blob missing from the destinationconfig set storage_urltos3://is refused until the S3 keys are setchunk_sizeerror names neither the setting nor the valueindex_pathaccepts a relative pathconfig init --helpnames the config directory without itsvaultikcomponent--versionflagsnapshot createREADME sentences that turned out wrong (the rewritten text):
snapshot createthat fails before writing anything saves it too (420).storage_urlbefore the S3 keys; that order is refused on a config that already loads (428). It works on the fileconfig initwrites.go install, and the result calls itself a development build (422).snapshot removerefusing a remote key, andNO_COLORcovering only status lines.Every other claim checked held, including the exclude-pattern rules, the duration grammar, the
config setrules, the stdout and stderr split, the--jsonfield rules, the exit statuses and the temporary-file cleanup on interruption.Not checked: rclone destinations (no remote available), macOS behaviour, ownership restore as root, more than 1000 remote snapshots, two hosts pruning one destination at the same time, and the release workflow. The explanation of the byte mismatch in 421 is inferred from the WAL growth, not traced in code. No code was changed.
Model: fable-5-1