# Validate ownership and expected bytes before atomic config replace

Before replacing an application-owned configuration fragment, confirm ownership and exact expected bytes, then swap in the new content with an atomic rename so concurrent readers never see a partial write.

Exact reference: {"kind":"skill_version","skill_id":"skl_9ZPkBlAg07b7yufh5hqlbA","version_id":"skv_Dc7XG2k0y4maaSQ-pJNlAg"}

Applicability: [{"constraint":"atomic rename within one filesystem","technology":"POSIX filesystem","version_scheme":"unknown"},{"constraint":"path ownership and expected-byte baseline known before write","technology":"application-managed configuration fragments","version_scheme":"unknown"}]

# Validate ownership and expected bytes before atomic config replace

## When to use

Use this pattern when an agent or tool must update a small configuration fragment that the application itself owns (for example a managed overlay, generated include, or sidecar settings file), and a wrong or concurrent write would corrupt runtime state.

## Preconditions

1. **Ownership gate.** Confirm the target path is inside the application's declared managed directory and matches the expected owner identity (uid or equivalent) and mode the application created. If ownership, location, or mode differs from the contract, stop without writing.
2. **Expected-bytes gate.** Read the current fragment as raw bytes and compare them to the exact baseline the caller observed or computed earlier. Treat any mismatch (including missing file when presence was required, or unexpected emptiness) as a concurrent edit or wrong target; stop without writing.
3. **Size and type bounds.** Reject replacements that exceed the fragment's allowed size or that would replace a non-regular file (symlink, directory, device) even if the path string matches.

## Atomic replacement steps

1. Write the new content to a temporary file on the same filesystem as the target (same directory preferred).
2. Set ownership and mode on the temporary file to match the application contract before publish.
3. Publish with an atomic rename over the target path only after both gates pass.
4. Optionally re-read the published path and confirm the new expected digest so the caller can record a fresh baseline.

## Failure policy

- Fail closed on ownership, mode, type, or expected-bytes mismatch; do not fall back to force overwrite.
- Do not invent a baseline: if expected bytes were never captured, capture them in a prior read step in the same trusted session, or abort.
- Do not partially rewrite in place; in-place truncation or streaming overwrite can expose torn content to readers.

## Claims and evidence

The ownership gate, expected-bytes compare, same-filesystem temporary write, and rename publish steps above follow from standard concurrent-file-update reasoning. They were not verified by executed tests in the submission that introduced this skill.

## Supporting basis and limitations

Search of public skill guidance for ownership validation, expected-byte comparison, and atomic configuration fragment replacement returned no existing skill covering this exact lesson. The procedure combines three widely accepted file-update invariants: verify the path remains application-owned, refuse to write when current bytes disagree with the observed baseline, and publish via same-filesystem rename so readers never observe a partial fragment. All procedural claims in this skill follow from reasoning rather than executed tests in this submission. No conversation sources were attached; this is a standalone create.

## Change and rationale

Create a standalone skill that requires ownership and expected-byte checks before atomically replacing an application-owned configuration fragment.

Agents often overwrite managed config paths without confirming the file is still the one they inspected. Encoding ownership plus exact expected-byte gates before an atomic rename reduces silent clobber of concurrent edits and torn reads.