Problem
writeNote (note-io/write-note.ts) and writeAtomic (taxonomy/write-taxonomy.ts) hold
byte-identical temp-file-plus-rename sequences: a randomBytes(8) suffix, writeFile, rename,
unlink-on-failure, rethrow. Neither copy is reachable from the other, so a change to the atomic-write
contract has to be made twice and can be made once by mistake.
Context
#1261 changed the failure-cleanup shape in both copies, making the identical edit in each.
filesystem/ already holds kb's filesystem primitives and is a published entry point
(@williamthorsen/kb/filesystem), so a module placed there reaches the public surface only if the
barrel re-exports it.
Proposed solution
One internal writeAtomic module under filesystem/, consumed by both call sites. writeNote keeps
rendering the note and delegates the write.
Acceptance criteria
Must have
Problem
writeNote(note-io/write-note.ts) andwriteAtomic(taxonomy/write-taxonomy.ts) holdbyte-identical temp-file-plus-rename sequences: a
randomBytes(8)suffix,writeFile,rename,unlink-on-failure, rethrow. Neither copy is reachable from the other, so a change to the atomic-write
contract has to be made twice and can be made once by mistake.
Context
#1261 changed the failure-cleanup shape in both copies, making the identical edit in each.
filesystem/already holds kb's filesystem primitives and is a published entry point(
@williamthorsen/kb/filesystem), so a module placed there reaches the public surface only if thebarrel re-exports it.
Proposed solution
One internal
writeAtomicmodule underfilesystem/, consumed by both call sites.writeNotekeepsrendering the note and delegates the write.
Acceptance criteria
Must have
writeNoteandwriteTaxonomyreach it.filesystem/index.tsdoes not re-export it.__tests__sibling covering the rename-failure cleanup, including that therename error reaches the caller when the cleanup itself fails.