[writ] Collaboration safety model: protect WIP without blocking normal integration #22

Goal

Define the small safety kernel that lets parallel coding agents collaborate without corrupting repository state or destroying another worker's work.

This issue supersedes the older enforcement-first threat model. Writ is not a universal merge-permission engine and is not responsible for policing every shell spelling. GitHub repository rules, permissions, reviews, and required checks remain the authority for protected-branch/remote merge policy.

Protect against

• editing or publishing from the wrong repository / branch / registered checkout;
• two live writers unknowingly owning the same task or overlapping write scope;
• destructive cleanup that deletes or resets another worker's work;
• bare force-push or equivalent history destruction on shared/protected branches;
• stale/crashed ownership being reclaimed without checking whether the worker is still live;
• partial state updates that create two owners after a crash;
• path/ref confusion, malformed machine requests, and lossy worktree registration;
• process timeout/cancellation that leaves an untracked child mutating state.

Explicitly allow

• harness-created worktrees and isolated clones;
• normal in-scope local merge, rebase, and cherry-pick on assigned feature/integration branches;
• negotiated scope expansion and handoff without a human approval ceremony for every change;
• peers exchanging commit SHAs, patches, findings, and conflict-resolution intent;
• advisory analyzer findings that do not represent a real data-integrity or repository-safety failure.

Out of scope

• re-implementing GitHub branch protection or remote merge authorization;
• a perfect classifier for arbitrary shell syntax;
• defending against a deliberately malicious same-user process with full filesystem access;
• writ-owned worktree creation/removal lifecycle;
• a second task tracker, Python orchestrator, or generic agent framework.

Rust-owned invariants

• repository/workspace identity is explicit and verifiable;
• ownership/lease transitions are atomic enough to prevent two live writers after crash/recovery;
• worktree/checkout registration is non-destructive and does not require writ to own the path;
• destructive Git operations are bounded to the assigned branch/scope;
• cleanup never deletes ambiguous or foreign WIP;
• process supervision is bounded and returns residual evidence;
• failures are observable rather than silently converted into success.

Acceptance criteria

• Safety documentation distinguishes data-loss/integrity invariants from ordinary collaboration policy.
• Normal assigned-branch local integration is not rejected merely because the command is git merge, rebase, or cherry-pick.
• A duplicate task/overlapping writer is surfaced with the current owner and a handoff path.
• Crash/stale recovery cannot create two live owners or erase uncertain work.
• Harness-owned checkout registration leaves branch/files/WIP unchanged.
• Existing completed regression coverage (including NUL-safe registration, ambiguous refs, fork-head verification, and irreversible-operation tests) is retained where it still protects these invariants.
• No new universal hook/command-classification bureaucracy is introduced solely to preserve the old enforcement-first model.

Parent: #1
Related: #136 (shared state/recovery), RM-170 (Rust command/state contract), RM-1711 / PR #199 (harness-owned checkouts), RM-145 / PR #197 (local integration).