An orchestrator runs 3 parallel feature-development agents, each working on a separate Git branch. Agent 1 modifies utils/validation.py, Agent 2 modifies utils/validation.py and models/user.py, and Agent 3 modifies models/user.py. When their branches are ready to be merged, the orchestrator needs to detect potential merge conflicts before attempting the merge. Which approach BEST enables proactive conflict detection in this scenario?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Waiting until you try to merge to discover conflicts is like finding out two contractors renovated the same bathroom only when you see them both invoicing for the same wall. The fix is to compare work orders before anyone picks up a hammer. File-level change manifest comparison is the equivalent of the project manager checking blueprints before work begins — cheap, fast, and prevents expensive rework.
Full explanation below image
![2048x1536 landscape infographic titled 'Proactive Conflict Detection: File-Level Change Manifest Comparison' showing three agent boxes at the top, each with a 'Change Manifest' list. Agent 1: [utils/validation.py]. Agent 2: [utils/validation.py, models/user.py]. Agent 3: [models/user.py]. Below, an orchestrator 'Manifest Comparison Engine' overlays the three lists, highlighting overlaps with orange circles: utils/validation.py (Agents 1+2) and models/user.py (Agents 2+3). Two alert boxes flag these files for 'Human Review Required' before merge. A sequential timeline at the bottom shows the proactive check happening before any git merge command is issued. Dark background, color-coded agent lanes, orange for conflict flags, green for non-conflicting files.](/media/github/gh-600/GH-600-e6-q039-infographic.webp)
Full Explanation
Proactive conflict detection operates before the merge attempt, using the information that is already available: which files each agent modified. This is more efficient than reactive conflict handling (attempting merges and handling failures) because:
1. Cheap to compute: Each agent can output a change manifest (list of modified files) as part of its completion artifact. The orchestrator compares these manifests in memory — no git operations required. 2. Early warning: Files modified by multiple agents are flagged before any merge is attempted, allowing the orchestrator to route those files to human review or invoke conflict resolution logic. 3. Triage by severity: Not all overlapping files are equal — a change to a test fixture and a change to core validation logic both trigger the flag, but the severity and resolution approach differ. The proactive approach creates an opportunity to assess severity before acting.
In this scenario, the comparison would immediately identify: - utils/validation.py → modified by both Agent 1 and Agent 2 → flag - models/user.py → modified by both Agent 2 and Agent 3 → flag
These two files require conflict resolution before any merge proceeds.
Option A (reactive: attempt merges and handle conflicts) is not proactive — it discovers conflicts at merge time, which is later in the process and potentially more disruptive. If conflicts require significant manual resolution, the orchestrator has already committed to the merge path. Option C (separate directories) eliminates conflicts by design but at the cost of codebase modularity — it prevents agents from refactoring shared utilities, which is a significant constraint on what agents can do. Option D (sequential execution) eliminates conflicts but eliminates parallelism entirely, sacrificing the throughput benefit of multi-agent orchestration. The exam principle is that conflict detection should be proactive and lightweight, not a side effect of the merge operation.