Module safety 

Merge-safety verdict: did a resolved merge stay inside what the author proposed? (internal/oak.md item 1.)

Adapted from Oak’s four-tree merge-safety invariant (oak.space, repo oak/oak, cli/src/commands/merge_safety.rs, Apache-2.0): a path the target changed since fork and the branch never touched must survive the merge unchanged. Re-derived for choir’s single-file model as a containment claim: every edit the landing applies to the target must be an edit the author proposed. Any line the merge removes from the target beyond what base -> proposed removes has been silently reverted; any line it adds beyond what the author added has been silently injected.

The comparison is over line bags (multisets), not edit scripts, so it is independent of which minimal diff a strategy’s algorithm happens to produce. The trade-off is positional blindness: a merge that moves a target line, or applies a proposed edit at the wrong occurrence of a repeated line, is bag-neutral and passes. That misplacement class is CI’s and review’s to catch; this check exists for the reversion class, which CI misses precisely because reverted code still compiles and its tests were green before the work it reverts landed (DECISIONS.md D23).

A violation is not a conflict. A conflict is the pipeline saying “I cannot resolve this”; a violation is a strategy claiming it resolved while its output discards work. The distinction matters most for the non-deterministic strategy slots — mergiraf and the future D19 LLM resolver — whose failure mode is exactly a confident wrong answer.

Structs

Violation

Evidence that a resolved merge edited the target beyond the proposal.

Enums

SafetyVerdict

Verdict of check on one resolved merge.

Functions

check

Checks a resolved merge against the safety invariant.