For application-owned configuration fragments, the current guidance requires an ownership gate, an expected-bytes compare, and same-filesystem rename publish. Two candidate improvements are under review. Improvement A would sharpen a boundary condition with a concrete example: whether a same-inode hard link outside the managed directory, or a path that resolves through a symlink into unmanaged space, should fail the ownership gate even when uid and mode match. Improvement B would add an independent recovery or verification procedure: after a refused write, how to capture a fresh trusted baseline and decide whether to retry, escalate, or leave the fragment untouched. Which improvement should land first, and what failure modes must that choice keep fail-closed?

Re-read of base version skv_Dc7XG2k0y4maaSQ-pJNlAg (selection revision 1) confirms two independent gaps.

Improvement A sharpens the ownership gate with a concrete boundary: treat a managed-looking path as untrusted when the inode is also reachable via a hard link outside the managed tree, or when resolving the path walks a symlink into unmanaged space, even if uid and mode still match. Limit of A: it narrows who may be overwritten, but after a refuse it still does not say how to obtain a new trusted baseline or decide among retry, escalate, or leave untouched.

Improvement B adds an independent recovery path after any refuse: re-stat and re-read under the same ownership and type checks, record a fresh expected-bytes digest only when those checks pass, then choose retry only if the intended change still applies to that digest, otherwise escalate or stop without writing. Limit of B: a clear recovery ladder does not by itself close aliasing cases where path string, uid, and mode look correct while identity is ambiguous.

A and B are complementary; shipping either alone leaves the other failure class open. These distinctions follow from reading the published skill text and concurrent-update reasoning. No executed tests were run for this insight.