From 67794bf5f825ebbfb21e21aea5a29f7983a25c22 Mon Sep 17 00:00:00 2001 From: clawbot <35+clawbot@noreply.example.org> Date: Mon, 26 Oct 2026 18:59:28 +0100 Subject: [PATCH] README: four sentences fixed for the documents gate (closes #229) The documents gate on `next` failed five README sentences (https://git.eeqj.de/sneak/quak/issues/219#issuecomment-156230). Four are rewritten after a check against the code: - the keywords score sentence is split in two; - `mlData` drops the whole `clip` block, as `src/backup.ts` and `src/metadata-backup.ts` do; - a file name gets its ID past 255 bytes and a collection name past 250, and either is then cut short, as `uniqueNames` does; - `lastTriedAt` is taken once per run, after its refresh. The IDs sentence keeps `-1`: the pinned option parser passes a negative number to a command with no subcommands as an argument, so `quak get -1` reaches the ID check. Nothing else changes; `make fmt` reflowed the touched paragraphs. Model: fable-5-1 (change); opus-5-5 (landing message) --- README.md | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 4c51a1e..8fa5f17 100644 --- a/README.md +++ b/README.md @@ -692,10 +692,10 @@ Update times are in microseconds, as Ente records them. The JSON also holds the machine-learning data Ente computed for the photo, as `mlData`. Ente's apps detect faces in each photo and compute a CLIP embedding for it, a list of 512 numbers that describes what the photo shows. `mlData` -holds everything but that embedding. In its place the JSON holds `keywords`, -derived from the embedding as described under "Keywords". A file with no -machine-learning data has neither field. A file whose data holds no usable -embedding has no `keywords`. +holds everything but the `clip` block, which holds that embedding. In its place +the JSON holds `keywords`, derived from the embedding as described under +"Keywords". A file with no machine-learning data has neither field. A file whose +data holds no usable embedding has no `keywords`. The backup waits for the library's fetch of machine-learning data to finish before it writes the JSON files. When a file's data cannot be fetched, @@ -748,11 +748,11 @@ derives a file's keywords the way the app sorts it. The categories are: Each category has a query, and a text embedding of that query from Ente's CLIP text model. A file's score for a category is the cosine similarity of the file's -embedding and the category's: a number from -1 to 1, higher the more alike the -two embeddings are. The file falls in the category when its score reaches the -category's minimum score. The keywords are the titles of the categories the file -falls in, highest score first. A video never falls in a category marked "no -videos", as in the app. +embedding and the category's. That is a number from -1 to 1; the more alike the +two embeddings are, the higher it is. The file falls in the category when its +score reaches the category's minimum score. The keywords are the titles of the +categories the file falls in, highest score first. A video never falls in a +category marked "no videos", as in the app. #### Collection directories @@ -775,9 +775,10 @@ ignoring case, each gets its ID added: two albums named `Trip` become `Trip (10)/` and `Trip (11)/`. Two files in one collection whose titles match, ignoring case, get their IDs added before the extension: `IMG_0001 (12345).JPG` and `IMG_0001 (12346).JPG`. A collection named like another collection's JSON -file, such as `Trip.json` beside `Trip`, also gets its ID added. A name too long -for a file name, which most file systems limit to 255 bytes, gets its ID added -too. It is then cut short before the ID, just far enough to fit. IDs never +file, such as `Trip.json` beside `Trip`, also gets its ID added. A file name +longer than 255 bytes, the limit on most file systems, gets its ID added too. So +does a collection name longer than 250 bytes, which leaves room for `.json`. +Either name is then cut short before the ID, just far enough to fit. IDs never change, so a name stays the same from run to run until such a clash appears or goes away. @@ -834,7 +835,8 @@ Each entry holds: - `fileID` and `title`; - `classification`: the kind of failure; - `attempts`: how many runs in a row have failed the file; -- `lastTriedAt`: when it was last tried, as a Unix time in milliseconds; +- `lastTriedAt`: when the run that last tried it finished its refresh, as a Unix + time in milliseconds; - `error`: the error, as quak printed it. The kinds are: