Resolve a conflict

The whole-package rule

Each package includes the last observed version of every path it changes. Current checks the entire package in one transaction. If any precondition fails, none of its changes become current.

For example, Alice publishes a new scene.js. Bob then submits both scene.js and model.glb from the older base. Bob’s entire package is rejected, including the model change. Both paths are blocked from automatic resubmission.

“First” means the first valid package accepted by current after its required chunks arrive. Client clocks are not used to pick the winner. Separate packages changing disjoint paths can both succeed.

Inspect the conflict

cor status
cor conflicts
cor conflicts --json

The readable conflicts.laplace.json report contains package reasons, every affected path, base/local/current manifests, and paths to preserved copies under .laplace/conflicts/. Deletions have a null file manifest.

Keep your repaired work

1. Stop this workspace’s cor work with Ctrl+C.
2. Inspect all active conflict packages, including files that did not directly collide.
3. Compare preserved versions and repair your working files in your usual tools.
4. Submit the repaired working tree as a new package:

cor resolve --take local
cor status
cor work

Both resolution commands act on all active conflict packages. They are not per-file commands. Local resolution forms a new package against the latest observed versions; another writer may win again. Recheck the result instead of retrying blindly.

Keep current instead

If the server versions are the result you want, stop the worker and run:

cor resolve --take current
cor status
cor work

Current’s known versions are installed, with preserved conflict and recovery copies retained. Inspect the full conflict scope before making this choice.

Try a deliberate conflict

In the tutorial playground, first let Alice and Bob catch up. Then:

1. Stop Bob’s worker with Ctrl+C.
2. Edit Alice’s src/game.js, save, and wait for Alice to report the completed exchange.
3. In Bob’s folder, edit src/game.js differently and create model-notes.txt.
4. Run cor sync from Bob’s stopped workspace.

Bob’s package is rejected as a whole. Inspect cor conflicts: both src/game.js and model-notes.txt belong to the rejected package. The notes have not been published on their own.

Repair Bob’s files and use cor resolve --take local, or accept current with --take current. Restart Bob’s worker after checking the result.

Monitoring and incoming changes

cor conflicts --watch --json

This emits the initial state and subsequent changes. cor conflicts --check exits with code 2 if any conflicts need attention.

An incoming package that overlaps local work is also blocked as an entire visible package. An edit made during installation produces a recovery conflict rather than silently overwriting unexpected content. Unrelated, unblocked paths can continue syncing.