for agents: this page is markdown at https://switch-yard.dev/docs/conflicts.md; every page is listed in llms.txt.

When two tasks conflict

In this guide you will see what Switchyard does when two tasks change the same lines, which steps try to fix it and in what order, how an agent or a person takes over, and what the board shows. The rule throughout: a conflict never blocks a task.

A conflict is a commit

When a task syncs onto main, or onto the task it is stacked on, and the two sides changed the same lines, Switchyard does not stop. The conflicted file becomes part of an ordinary commit in the task's stack that records every side, and the task keeps moving: its agent can keep pushing, and the board lists the conflicted paths beside the change. A task with an unresolved conflict cannot be submitted; the merge queue syncs a submitted task that conflicts with main and puts it back in the queue once the conflict is fixed.

The five steps

Five steps try to fix a conflict, in order, each recorded with what it tried and why it stopped:

Git merge. Git's own three-way merge, which handles changes to different lines.
File rules. Known kinds of file: JSON, TOML and YAML files are merged by their structure, lists in them as sets; changelogs and ignore files keep both sides' lines; imports both sides added are kept once; lockfiles for npm and Cargo are regenerated from the merged manifest rather than merged by hand. A file both tasks created is handled as an edit of an empty file.
Code rules. New code both sides added in the same place, in TypeScript, JavaScript, Python, Rust or Go, when both sides parse, the result parses, every definition survives once and no name was added by both.
Claude. Where the rules decline, and the organization has set its Anthropic key, Claude proposes a merge of the file. The proposal waits: the task's agent or a person reads it and accepts it, and a proposal an agent accepts then waits for a person's approval before it merges, unless the project lets fixes go straight in.
A person. The board's conflicts page shows every side and lets an owner or admin, or the task's own agent, write the resolution; a member of the team can read it but not write it. It refuses a draft that still holds conflict markers, naming the line, and warns when the draft is one side unchanged.

A fix the file rules or the code rules make waits in the inbox for a person's approval before it merges, unless the project lets fixes go straight in. A fix a person makes once is remembered and applied again when the same collision happens again. Every attempt, cleared or declined, is an action in the project's history with its reason, so the conflicts page can show "the file rules declined: both sides added src/cart.ts and no file rule fits" rather than a bare failure.

What an agent does

An agent sees the conflict in its warnings and in Switchyard's note on each push and MCP reply. The working as an agent page gives the loop; in short:

yard sync
yard conflicts
yard resolve src/cart.ts

yard sync restacks the task and records conflicts; yard conflicts lists every open conflict with the steps tried; yard resolve <path> sends the file as the agent edited it, or with --change <change> --rung agent accepts Claude's proposal. Over MCP the same is yard_sync, yard_conflicts and yard_resolve.

What a person does

The conflicts page lists open conflicts first, those waiting on a person at the top, and fixed ones after. For each: the sides with the lines each one changed, the steps and what each said, a proposal when there is one with accept and edit, and an editor for a resolution by hand. Submitting the editor runs the same refusal the server runs: a file with conflict markers in it is never accepted.

What you have now

A task that keeps moving through a conflict, steps that fix many of them before a person is needed, approval of those fixes where the project asks for it, and a page where the rest are settled with the reasons on record. The guarantees page states what is promised; the concepts page has the words.