Review toward 1.0: identify and file all next steps #97

Closed
opened 2026-09-23 05:28:22 +02:00 by clawbot · 2 comments
Collaborator

Top-level manager instruction (2026-09-23), following the owner's directive to review repos toward a usable 1.0: one independent reviewer reads the tree on next2 and the tracker, and files each concrete next step it finds as its own issue.

Definition of done

  • A review summary is posted here as one comment: the state of the tree and what stands between it and a usable, ready 1.0.
  • Every concrete next step exists as its own issue with a definition of done. Nothing duplicates an open issue.
  • Any question that only sneak can settle is posted on the relevant issue with the options and a recommendation, and assigned to sneak.
  • The filed units are then dispatched and gated as usual, with PRs based on next2.

This review does not tag, bump the version or cut a release.

Model: opus-5-5

Top-level manager instruction (2026-09-23), following the owner's directive to review repos toward a usable 1.0: one independent reviewer reads the tree on `next2` and the tracker, and files each concrete next step it finds as its own issue. ## Definition of done - A review summary is posted here as one comment: the state of the tree and what stands between it and a usable, ready 1.0. - Every concrete next step exists as its own issue with a definition of done. Nothing duplicates an open issue. - Any question that only sneak can settle is posted on the relevant issue with the options and a recommendation, and assigned to sneak. - The filed units are then dispatched and gated as usual, with PRs based on `next2`. This review does not tag, bump the version or cut a release. Model: opus-5-5
clawbot self-assigned this 2026-09-23 05:28:22 +02:00
Author
Collaborator

Review of next2 at d05b53d toward a usable 1.0

State of the tree. make check is green in a fresh clone: 563 tests, plus lint in Docker. The protocol layer, the retry policy, atomic writes and the library surface are in good shape, and every command the README documents exists and works as described on its normal path. Four things stand between this and a backup tool someone can rely on:

  • A backup can report success when it did nothing, because a failed or unfinished server refresh is ignored.
  • Real accounts break the album folders: repeated titles and repeated album names.
  • Live photos come out as files no viewer can open.
  • Every runtime error reaches the user as a raw Node stack trace.

The rest are narrower correctness, security and docs fixes.

Filed:

  • #99: backup does not wait for the refresh and ignores its failure, so an empty or old file list exits 0.
  • #100: backup-metadata and the thumbnail helpers answer from a possibly days-old cache.
  • #101: one failed ML request ends backup-metadata halfway.
  • #102: CLI errors print a raw stack trace (reproduced).
  • #103: album folders drop files with repeated titles, merge albums with the same name, and never remove old links (reproduced).
  • #104: a cache directory reused by a second account mixes both accounts' albums and cursor.
  • #105: opening a library deletes another quak process's download in progress.
  • #106: quak backup writes every original twice and precaches the whole account into the per-user cache.
  • #107: live photos are saved as a ZIP under the image's extension. How to store them is a question for sneak, posted there.
  • #108: quak logout leaves the token valid on the server.
  • #109: fix-missing-thumbnails retries uploads the server always refuses (files owned by someone else, and replacements larger than the recorded size).
  • #110: quak login and backup-metadata --exif have no tests.
  • #111: README and TODO.md are out of date (layout, backup layout, open behaviour, test time limit, "Tag v1.0.0" as the next step).

Tracker notes. #12, #29, #30, #33 and #80 are implemented but still open. #31 carries next only; nothing yet proposes next2 toward main.

Not checked: a live login against Ente's servers, make install (it needs nix-shell and bun), and macOS or Windows paths. The server-side behaviour cited in #108 and #109 was read from upstream server source at af32f23, not exercised.

Model: opus-5-5

## Review of `next2` at `d05b53d` toward a usable 1.0 **State of the tree.** `make check` is green in a fresh clone: 563 tests, plus lint in Docker. The protocol layer, the retry policy, atomic writes and the library surface are in good shape, and every command the README documents exists and works as described on its normal path. Four things stand between this and a backup tool someone can rely on: - A backup can report success when it did nothing, because a failed or unfinished server refresh is ignored. - Real accounts break the album folders: repeated titles and repeated album names. - Live photos come out as files no viewer can open. - Every runtime error reaches the user as a raw Node stack trace. The rest are narrower correctness, security and docs fixes. **Filed:** - https://git.eeqj.de/sneak/quak/issues/99: `backup` does not wait for the refresh and ignores its failure, so an empty or old file list exits 0. - https://git.eeqj.de/sneak/quak/issues/100: `backup-metadata` and the thumbnail helpers answer from a possibly days-old cache. - https://git.eeqj.de/sneak/quak/issues/101: one failed ML request ends `backup-metadata` halfway. - https://git.eeqj.de/sneak/quak/issues/102: CLI errors print a raw stack trace (reproduced). - https://git.eeqj.de/sneak/quak/issues/103: album folders drop files with repeated titles, merge albums with the same name, and never remove old links (reproduced). - https://git.eeqj.de/sneak/quak/issues/104: a cache directory reused by a second account mixes both accounts' albums and cursor. - https://git.eeqj.de/sneak/quak/issues/105: opening a library deletes another quak process's download in progress. - https://git.eeqj.de/sneak/quak/issues/106: `quak backup` writes every original twice and precaches the whole account into the per-user cache. - https://git.eeqj.de/sneak/quak/issues/107: live photos are saved as a ZIP under the image's extension. How to store them is a question for sneak, posted there. - https://git.eeqj.de/sneak/quak/issues/108: `quak logout` leaves the token valid on the server. - https://git.eeqj.de/sneak/quak/issues/109: `fix-missing-thumbnails` retries uploads the server always refuses (files owned by someone else, and replacements larger than the recorded size). - https://git.eeqj.de/sneak/quak/issues/110: `quak login` and `backup-metadata --exif` have no tests. - https://git.eeqj.de/sneak/quak/issues/111: README and `TODO.md` are out of date (layout, backup layout, open behaviour, test time limit, "Tag v1.0.0" as the next step). **Tracker notes.** https://git.eeqj.de/sneak/quak/issues/12, https://git.eeqj.de/sneak/quak/issues/29, https://git.eeqj.de/sneak/quak/issues/30, https://git.eeqj.de/sneak/quak/issues/33 and https://git.eeqj.de/sneak/quak/issues/80 are implemented but still open. https://git.eeqj.de/sneak/quak/pulls/31 carries `next` only; nothing yet proposes `next2` toward `main`. **Not checked:** a live login against Ente's servers, `make install` (it needs `nix-shell` and bun), and macOS or Windows paths. The server-side behaviour cited in https://git.eeqj.de/sneak/quak/issues/108 and https://git.eeqj.de/sneak/quak/issues/109 was read from upstream server source at `af32f23`, not exercised. Model: opus-5-5
Author
Collaborator

Definition of done met. Every next step filed in the review has been implemented, independently reviewed and squash-merged to next2, which is green at 6a7a10f. Two follow-ups found in the reviews landed too: #117 and #93. The one open item is #107 (how to store live photos), which is sneak's decision and is assigned to him. next2 becomes the new next when #31 is merged.

Model: opus-5-5

Definition of done met. Every next step filed in the review has been implemented, independently reviewed and squash-merged to `next2`, which is green at `6a7a10f`. Two follow-ups found in the reviews landed too: https://git.eeqj.de/sneak/quak/issues/117 and https://git.eeqj.de/sneak/quak/issues/93. The one open item is https://git.eeqj.de/sneak/quak/issues/107 (how to store live photos), which is sneak's decision and is assigned to him. `next2` becomes the new `next` when https://git.eeqj.de/sneak/quak/pulls/31 is merged. Model: opus-5-5
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/quak#97