principle-separate-before-serializing-shared-state

• SKILL.mdcore · 2,592 bytes

# Separate before serializing shared state

If concurrent actors could write to one piece of state, eliminate the sharing before anything else. Add structural serialization only when having a single shared target is a real invariant. A written agreement such as "agents should not both edit this file" provides no concurrency control.

## When it applies

Concurrent actors (processes, workers, agents, parallel subagents) that could write to a common key, file, branch, or state object. Sharing that is read-only is exempt.

## What to do

1. List the shared mutable state: files, branches, keys, and APIs more than one actor writes.
2. By default, give each actor its own write target (its own file, key, branch, state directory, or worktree), and combine results only at the boundary where they are read or reported. Decide whether the actors truly require a single canonical object or are each publishing facts that do not depend on one another. Two workers each updating their own field inside one shared JSON file is still shared mutation. Two separate files are not.
3. Only if one shared target is a true invariant, serialize with structure: a lock file, sequential phases, a single-writer actor that owns the target, or an atomic compare-and-swap.
4. If you feel you need a lock, take that as a sign to examine the design before you add one.