Merge

Draxl merge analysis compares patch streams against a shared source file. The merge layer works with structured operations, so it can reason about node ids, slots, ranks, anchors, and scalar paths directly.

Merge Model

Merge analysis answers three questions in order:

1. Can the patch streams replay together deterministically?
2. Does the merged result validate and pass project checks?
3. Do the combined edits preserve coherent meaning?

The first question belongs to Draxl hard-conflict analysis. The second belongs to validation, lowering, compiler, and CI checks. The third belongs to semantic conflict analysis.

Replay And Convergence

Replay checks apply the patch streams in different orders and compare canonical results. Matching output means the edit set converges to the same Draxl source.

This is the structural base for automatic merge:

left then right -> canonical Draxl source
right then left -> canonical Draxl source

If both paths produce the same tree, the streams are structurally compatible.

Concurrent Insert Example

Starting body:

@s1[a] @e1 fetch();
@s2[am] @e2 log();
@s3[b] @e3 validate();

One agent inserts tracing after fetch:

insert @f1.body[ah]: @s4 @e4 trace();

Another agent changes the logging call:

replace @e2: @e2 audit()

Merged result:

@s1[a] @e1 fetch();
@s4[ah] @e4 trace();
@s2[am] @e2 audit();
@s3[b] @e3 validate();

The insertion targets a ranked slot. The replacement targets expression @e2. The two operations touch different semantic regions.

Conflict Checks

Use the CLI to compare two patch streams:

cargo run -p draxl-cli -- conflicts \
  examples/01_add.rs.dx \
  /tmp/left.dxpatch \
  /tmp/right.dxpatch

The command emits JSON with one top-level conflicts array:

{
  "conflicts": []
}

Conflict entries include class, code, owner, touched regions, and operation evidence. Agents can route on those fields and ask for targeted resolution.

Hard Conflicts

Hard conflicts stop deterministic merge. Common examples:

• both sides write the same node, scalar path, or single-child slot
• both sides insert at the same ranked position
• one side removes a subtree that the other side edits inside
• replay succeeds in one order and fails in the other
• both replay orders succeed and produce different final trees

Hard conflicts are structural. They use the patch model and schema rules.

Semantic Conflicts

Semantic conflicts are structurally mergeable edits that still require review. The current Rust rules cover cases such as:

• one side renames a let binding while the other side changes its initializer
• one side changes a parameter type contract while the other side changes body logic that interprets the parameter

Read Conflicts for report shape and examples.