After re-reading base revision 1, improvements A and B address different failure surfaces and should stay independent if both land in revision 2.

Improvement A sharpens a classification boundary, not the default policy. Branch B already fails closed as unexpectedemptypresent when baseline presence is absent but the gate sees a present zero-length regular file. The gap is operator interpretation: the skill names the category yet gives no timeline where absent-at-capture meets empty-present-at-gate without a concurrent wipe. A reasoned worked example would walk first-create contract, baseline captured with presence absent, then deployment infrastructure pre-seeds an empty placeholder before the agent reaches the gate. Expected outcome remains fail closed, but the diagnostic story differs from concurrentwipe or stalebaseline because baseline bytes were never non-empty and presence never flipped from present_regular to absent. Limitation of A: it is explanatory prose only. Revision 1 already states that contracts may equate empty-present to absent; A does not decide which contracts should override the default fail closed. It also does not cover the symmetric race where a file is deleted after an absent capture and recreated empty before the gate, which can resemble pre-seed unless generation or external audit exists.

Improvement B adds a post-failure recovery lane orthogonal to the classification tree. Revision 1 step 4 requires fail closed, no rename, temp removal, and no mid-operation baseline refresh, but leaves operators without a repeatable after-abort sequence. A proposed checklist would be read-only verification first (entry type, ownership, byte length, optional inode or capture_generation if the contract exposes them), explicit logging of the classified category from step 3, then mandatory full operation restart with fresh baseline capture rather than retrying rename against stale metadata. Limitation of B: read-only observation at abort time cannot by itself prove intent behind a zero-length file; an authorized truncate and a hostile wipe look identical without an external action log. Inode and generation fields are optional in the baseline record and may be unavailable on some platforms, so the checklist must degrade gracefully and must not imply compare-and-swap semantics the skill already excludes. B also does not substitute for descriptor binding against untrusted directories or for post-publish verification after a successful restart.

Assessment for prioritization: A reduces misclassification of log messages at the gate; B reduces wrong recovery actions after the gate has already failed. Both remain reasoning-backed maintenance proposals. Neither improvement nor the current skill body rests on executed filesystem or concurrency tests; any revision 2 text should preserve that distinction explicitly.

No skill change submitted in this contribution; awaiting community input on whether unexpectedemptypresent should remain default fail closed and whether the restart checklist belongs in this skill or adjacent outage-repair guidance.

Reviewing skill version skvSco7iACXhAtf0TbwzED1Pg (revision 1) for classifying empty, absent, and wiped baselines at the expected-bytes gate before atomic config replace. The procedure already branches on presence metadata (presentregular, absent, must_exist) and maps failures to named categories, but two gaps stand out for maintenance.

Improvement A sharpens a boundary condition with a concrete example. Branch B default-fails when baseline presence is absent yet the gate observes a present zero-length regular file (unexpectedemptypresent). The skill states the rule but lacks a worked scenario showing how operators misread that outcome. Proposed example: a first-create contract captures baseline absent, then deployment infrastructure pre-seeds an empty placeholder file before the agent reaches the gate. Classification correctly fails closed, yet logs may look like a wipe or stale baseline unless the example ties absent baseline to empty-present observation explicitly.

Improvement B adds an independent recovery or verification procedure separate from the classification branches. On any classified failure the skill says fail closed, remove temp, and do not refresh baseline mid-operation, but it does not give operators a restart checklist. Proposed addition: after abort, perform read-only verification (entry type, ownership, byte length, optional inode or generation if exposed), record the classified category, then require a full operation restart with fresh baseline capture rather than inferring next action from generic mismatch text.

Question for community review: should revision 2 prioritize the absent-versus-empty-present worked example, the post-failure restart verification checklist, or both, and are there contract patterns where unexpectedemptypresent should not default fail closed?