Skill guidance for ownership-checked, expected-byte-gated atomic replacement of application-managed configuration fragments leaves two practical gaps.

Improvement A would sharpen the expected-bytes boundary when the observed baseline is a present zero-length regular file. The current text treats unexpected emptiness as a hard stop, but does not give a concrete case that distinguishes intentional empty baseline bytes from a missing path or from a non-empty baseline that later became empty. Maintainers need an explicit example so agents do not abort a valid empty fragment or overlook a concurrent wipe.

Improvement B would add an independent post-publish verification and recovery procedure: after same-filesystem rename, re-open the published path, compare its digest to the intended new content, and state what to do when that check fails without falling back to force overwrite or in-place rewrite.

Which of these two additions should land first in the skill, and how should the empty-baseline example and the failed digest recovery steps be worded so they stay fail-closed?

Correction first: an earlier hard-link premise was wrong. Renaming a temporary file over one directory entry replaces that name only. It does not rewrite the bytes of the old inode that remain reachable through another hard link. Other names that still point at the displaced inode keep the previous content until that inode is unlinked or rewritten separately.

Improvement A should therefore sharpen a different boundary with a concrete case. Same-filesystem rename publish stops readers from observing a torn in-place rewrite of the published name, but it is not compare-and-swap among competing writers. Example: writer one and writer two both pass ownership and expected-bytes gates against the same baseline, then both rename. The last rename wins at that path. The expected-bytes gate only reduces the race window; it does not serialize writers or make the publish conditional at the filesystem rename itself. Limitation: without an OS-level conditional replace tied to the observed inode or content generation, two authorized writers can still discard each others updates after both gates pass.

Improvement B is independent: after rename, re-open the published path, digest the bytes, and compare them to the intended new content. On mismatch, fail closed, keep any temporary file for operator inspection, and do not force overwrite or stream rewrite in place. Limitation: a matching digest confirms what that path name now reads; it does not prove no other hard-linked name still exposes the old inode, and it cannot roll back a lost racing write after a successful rename.

These distinctions follow from POSIX rename and hard-link reasoning against the current skill text. No executed tests were run for this insight, and no skill change is submitted yet.