vaultik

235 Commits 7 Branches 0 Tags

3 Commits

Author	SHA1	Message	Date
clawbot	753bc3ef60	Correct remote layout and privacy docs for hashed snapshot keys (closes #67 ) check / check (pull_request) Failing after 1s Details check / check (push) Successful in 3m11s Details Three documents showed the remote layout with a plaintext snapshot ID as the metadata directory name, and docs/REPOSTRUCTURE.md blamed those IDs for the observable backup time. The store actually names each metadata directory with a one-way hash of the ID, so hostname and snapshot name are not visible; the backup time is, through the plaintext timestamp in the manifest, which is accepted behaviour. README, ARCHITECTURE.md, docs/DATAMODEL.md and docs/REPOSTRUCTURE.md now show the hashed layout, the derivation is documented once, and the privacy section lists what the unencrypted manifest exposes. Two code comments that claimed the timestamp was hidden are corrected. No behaviour change. Judgement call: docs/DATAMODEL.md was not named in the issue but had the same error. model: claude-opus-4-8 (implementation, review); claude-fable-5-1 (merge)	2026-09-21 19:24:44 +02:00
clawbot	d2a0510cb4	Trigger CI on next, not only main (closes #122 ) check / check (pull_request) Failing after 0s Details check / check (push) Successful in 3m33s Details `check.yml` ran only on push to `main` and on pull requests against `main`. Every unit is a PR based on `next`, and `next` is pushed on each squash-merge, so no unit PR and no push to `next` ever ran CI; a broken `next` would first surface on the milestone PR. `next` is added to both branch lists; nothing else in the workflow changes. The README Entrypoints section now says where CI runs. Disclosure: the CI run on the PR itself fired (the proof the trigger works) but was red because the runner had no disk space left before any check step ran; the local gate was green. Model: opus-4-8 (implementation and review) model: claude-fable-5	2026-09-21 14:55:59 +02:00
clawbot	583f65040a	Correct --cron flag help to name warnings as unsuppressed (closes #87 ) check / check (pull_request) Failing after 0s Details `--cron` sets the UI quiet, but `Warningf` and `Errorf` are unconditional, and the snapshot summary is routed through `Warningf` on purpose so cron delivers something on a successful run. The help string said `silent unless error`, so a user could read normal cron output as a failure. It now says `silent unless warning or error`, matching the README. String only; no behavior change. Model: opus-4-8 (implementation and review) model: claude-fable-5	2026-09-21 14:55:45 +02:00

Author

SHA1

Message

Date

clawbot

753bc3ef60

Correct remote layout and privacy docs for hashed snapshot keys (closes #67 )

check / check (pull_request) Failing after 1s

Details

check / check (push) Successful in 3m11s

Details

Three documents showed the remote layout with a plaintext snapshot ID as the metadata directory name, and docs/REPOSTRUCTURE.md blamed those IDs for the observable backup time. The store actually names each metadata directory with a one-way hash of the ID, so hostname and snapshot name are not visible; the backup time is, through the plaintext timestamp in the manifest, which is accepted behaviour.

README, ARCHITECTURE.md, docs/DATAMODEL.md and docs/REPOSTRUCTURE.md now show the hashed layout, the derivation is documented once, and the privacy section lists what the unencrypted manifest exposes. Two code comments that claimed the timestamp was hidden are corrected. No behaviour change.

Judgement call: docs/DATAMODEL.md was not named in the issue but had the same error.

model: claude-opus-4-8 (implementation, review); claude-fable-5-1 (merge)

2026-09-21 19:24:44 +02:00

clawbot

d2a0510cb4

Trigger CI on next, not only main (closes #122 )

check / check (pull_request) Failing after 0s

Details

check / check (push) Successful in 3m33s

Details

`check.yml` ran only on push to `main` and on pull requests against `main`. Every unit is a PR based on `next`, and `next` is pushed on each squash-merge, so no unit PR and no push to `next` ever ran CI; a broken `next` would first surface on the milestone PR. `next` is added to both branch lists; nothing else in the workflow changes. The README Entrypoints section now says where CI runs.

Disclosure: the CI run on the PR itself fired (the proof the trigger works) but was red because the runner had no disk space left before any check step ran; the local gate was green.

Model: opus-4-8 (implementation and review)
model: claude-fable-5

2026-09-21 14:55:59 +02:00

clawbot

583f65040a

Correct --cron flag help to name warnings as unsuppressed (closes #87 )

check / check (pull_request) Failing after 0s

Details

`--cron` sets the UI quiet, but `Warningf` and `Errorf` are unconditional, and the snapshot summary is routed through `Warningf` on purpose so cron delivers something on a successful run. The help string said `silent unless error`, so a user could read normal cron output as a failure. It now says `silent unless warning or error`, matching the README. String only; no behavior change.

Model: opus-4-8 (implementation and review)
model: claude-fable-5

2026-09-21 14:55:45 +02:00