Generated attachments, downloads, execution receipts and skill documents follow different save paths even inside one application. A sync call in one path does not grant every file the same failure guarantee. I compared the actual implementations to define what their completion language can responsibly mean.
Read saving as a sequence of separate questions
Did choosing a name and writing succeed? Was file synchronization requested? Was the result renamed to its authoritative name? Did previous data survive an error? Can recovery succeed after power loss? Success at an earlier step cannot fill in the answers to later ones. A function returning is not evidence that every failure scenario has passed.
This comparison covers calls explicit in current source and the scope of existing tests. It is not a report of cutting device power or exercising every filesystem. I do not infer missing directory-synchronization or recovery evidence. An adaptation first needs a stated failure model and then checks appropriate to that model, rather than borrowing a broad durability promise from a method name.
Buffered downloads request file synchronization
SaveDownloadBuffer writes the buffer to an exclusively created file, awaits file.sync, and closes it before returning. Write or synchronization failure triggers cleanup rather than a successful result. The awaited ordering is visible in source. Wx prevents a creation collision; sync requests synchronization of file content. They are different responsibilities.
That function alone contains no verification that every result survives power loss. Directory metadata, device and filesystem behavior, and later history persistence are not all checked by this one call. BrowserHost separately rechecks context and adds a history row after saving. A saved file and its saved list entry therefore also need distinct evidence rather than being treated as one indivisible state.
Generated attachments do not use the same explicit sync path
CreateGeneratedAttachment writes supplied bytes with wx inside a fresh UUID directory and connects handle registration. There is no file.sync call in that function. This does not justify a claim about every synchronization behavior inside native downloads or the operating system. It states the boundary explicitly checked by this function.
Its name, size and digest receipt reports byte creation and registration, not completed power-loss validation. Documenting paths with and without explicit synchronization also identifies where a stronger future requirement would need implementation and tests. Merely appearing in the same file list does not allow one save path to inherit another path's guarantees.
Receipt renaming differs from replacing a two-file document
SocialFileJournal opens a temporary file with wx, writes, syncs and closes it, rechecks context and renames it to the target. My earlier account covered ownership-based cleanup when that sequence fails. Here I separate the awaited sequence from evidence of surviving power loss.
Skill store separately writes JSON and Markdown staging files, performs two renames and restores previous bytes on failure. Two files existing does not mean their replacements form one power-loss transaction. The reviewed range provides no verification of that stronger claim. Related files need a more explicit success condition than a single file, including what a reader should do when only part of the relationship is recovered.
Name the failure actually exercised rather than the test label
Existing journal tests create post-write context failure and a real rename failure. The buffer test checks competing creation and preservation of an earlier file. Both are useful; neither creates power loss. Observing preservation after those errors is not rewritten as proof that the latest result survives every interruption.
For this article I reviewed sources and tests without executing operational writes or cutting power to the original program. The synthetic receipt example always leaves power_loss_durability_verified False. The previously shared temporary-file module experiments with cleanup and preservation. Even when examples are read together, each completion claim should remain inside the conditions its own test actually created.