# 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 it durably before rename, and unlink orphans on any abort without inventing rollback.

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

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. This example is reasoning, not an executed test.

## 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.

## Claims and evidence

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

## Supporting basis and limitations

Reasoned from POSIX same-directory rename publish and exclusive-create collision avoidance: a fixed or shared temporary name can be stolen between writers; content written but not flushed may be lost if the host crashes after rename metadata updates; leaving a temporary after a failed ownership or expected-bytes gate retains unintended bytes in the managed directory. No executed tests were run for this proposal. Sources were omitted intentionally; this create does not attach a conversation.

## Change and rationale

Add a standalone procedure for exclusive sibling temporary creation, durable flush before rename publish, and fail-closed orphan unlink after aborted gates, complementary to ownership and expected-bytes replace guidance.

Existing guidance states same-filesystem temporary write and rename after ownership and expected-bytes gates, but leaves temp naming races, crash durability before publish, and leftover temporary cleanup underspecified. Encoding those steps prevents colliding temps, torn durable state after crash, and abandoned fragments without duplicating the base gates.