# Exclusive sibling temp, durable flush, and abort unlink for fragment publish

When publishing a gated application-owned configuration fragment, create an exclusive same-directory temporary, flush before and after rename for entry durability, and unlink orphans on abort without inventing rollback.

Exact reference: {"kind":"skill_version","skill_id":"skl_kTVhrLbYFdAkKSvhvoZK3g","version_id":"skv_LL1bOCjMZPkJQg9rXiQA7w"}

Applicability: [{"constraint":"same-directory exclusive temporary and rename publish","technology":"POSIX filesystem","version_scheme":"unknown"},{"constraint":"ownership and expected-bytes gates already decided before publish","technology":"application-managed configuration fragments","version_scheme":"unknown"}]

# Exclusive sibling temp, durable flush, and abort unlink for fragment publish

## When to use

Use after ownership, expected-bytes, size, and type gates have already decided that an application-owned configuration fragment may be replaced. This procedure covers only the temporary-file publish path: how to create it, make it durable, publish it, and clean it up on abort.

Do not use this as a substitute for those gates, for writer compare-and-swap, or for hard-link semantics. Ordinary rename still only replaces one directory entry.

## Exclusive sibling temporary

1. Create the temporary in the same directory as the target so rename stays on one filesystem and one directory inode.
2. Use an exclusive create (create-new, fail if the name exists). Do not open-truncate a fixed well-known temporary name shared across writers or retries.
3. Prefer an unpredictable suffix per attempt so a concurrent writer cannot predict and occupy the name you intend to use.
4. If exclusive create fails because the name exists, choose a new name and retry create; do not fall back to truncating the colliding path.

Reasoned example: two writers both prepare publish against the same managed fragment and both open a temp named fragment.tmp for truncate-write. Either may clobber the other's bytes before rename. Exclusive create-new on distinct names avoids that collision class. This example is reasoning, not an executed test.

## Ownership and mode on the temporary

Apply the application contract owner and mode to the temporary after write and before publish, matching the target contract used by the earlier ownership gate. If those metadata updates fail, abort and unlink the temporary; do not rename a file that violates the contract.

## Durable flush before rename

1. After writing the full replacement bytes, flush the temporary file data to stable storage (file sync or equivalent required by the platform).
2. Where the platform documents it, also flush the parent directory so the directory entry for the temporary is durable before rename.
3. Only then rename the temporary over the target path.

Reasoned example: a writer renames immediately after write returns, then the host loses power. Readers may later observe a zero-length or partially persisted fragment at the published name even though the rename appeared to succeed. Flushing before rename narrows that crash window for the temporary's bytes. This example is reasoning, not an executed test.

## Boundary: pre-rename flush is not entry durability

Pre-rename file and directory flush makes the temporary's bytes and its temporary directory entry more durable. It does **not** by itself make the replacement directory entry crash-durable after rename returns.

After a successful rename, flush the parent directory again (where the platform documents directory sync) so the published name durably points at the new inode.

Concrete reasoned case: the writer flushes the temporary, renames over the live fragment name, then the host crashes before a post-rename parent-directory flush. On recovery the directory may still name the prior inode, so readers reopen the old fragment while the new bytes exist only on an unlinked inode. Treat pre-rename flush alone as insufficient for that entry-durability goal. This case is reasoning, not an executed test.

Non-goals for this boundary: post-rename directory flush does not prove durability on every filesystem, does not serialize competing writers, and does not replace ownership or expected-bytes gates.

## Abort unlink and failure policy

- If any gate fails after the temporary exists, or if metadata, flush, or rename fails, unlink the temporary you created. Do not leave orphan temps in the managed directory.
- Do not invent rollback of an already-successful rename by guessing prior bytes. If post-publish verification is used and the published digest is unexpected, treat that as concurrent publish or wrong target, stop further writes, and report; recovering prior content requires a separately retained baseline, not an orphan temporary that was already renamed away.
- Do not partially rewrite the live target in place as a recovery shortcut.
- Do not claim exclusive temporary create serializes competing renames; it only protects the temporary name itself.
- Do not claim pre-rename flush already covered replacement directory-entry durability.

## Claims and evidence

The exclusive-create, same-directory rename, durable-flush-before-publish, post-rename parent-directory flush boundary, and abort-unlink steps follow from standard concurrent-file-update and crash-durability reasoning, including maintenance conversation evidence on this skill. No executed tests were run for this update.

## Supporting basis and limitations

Maintenance conversation thr_eiljqVNN0jEYEQAvPvP5Kg message msg_GlbSVEzN6r_5Jqxw0L18nA (sequence 1) poses direction A: pre-rename flush does not make the replacement directory entry crash-durable, and a post-rename crash can leave the directory naming the prior inode while new bytes sit unlinked. Message msg__0Yg9F9qS4SH9OWTCLW9bg (sequence 2) restates that concrete case, requires stating pre-rename flush alone is insufficient for entry durability, and limits A so it does not claim universal filesystem proof or writer serialization. This update encodes that A boundary into the skill while preserving exclusive sibling create, ownership and mode on the temporary, pre-rename flush, and abort-unlink policy from base skv_x1wdYuF1C5z5yd2JsOr8HA. Claims remain reasoning-backed; no executed tests were run for this proposal.

## Change and rationale

Clarify that pre-rename file and directory flush does not make the replacement directory entry crash-durable; require a parent-directory flush after rename and add a concrete post-rename crash example while preserving exclusive temp, abort unlink, and pre-rename flush guidance.

The base skill correctly flushes before rename but leaves agents free to treat that as sufficient crash durability for the published directory entry. Spelling out that rename return still requires a parent-directory flush afterward, with a concrete old-inode-versus-unlinked-new-bytes crash case, closes that boundary without dropping exclusive temp create or abort unlink.