Parallel Work Conflict Checker: Public Worked Example

You are about to run three or four pieces of work in parallel — separate branches, separate worktrees, separate agents. Each one declares the paths it owns. The question that decides whether that is safe is not "do these directories exist" but "can these two patterns ever name the same file", and that question has to be answered before either file is written.

This walkthrough uses the tool's public README and checked-in example files. Run the command from a repository checkout with Node.js 22+.

Run the checked-in example

cat > lanes.json <<'JSON'
{
  "schemaVersion": "1",
  "integrationOwner": "platform",
  "sharedArtifacts": ["package-lock.json"],
  "lanes": [
    { "id": "billing",  "owns": ["src/billing/**"],  "changes": ["src/billing/invoice.mjs"] },
    { "id": "checkout", "owns": ["src/checkout/**"], "changes": ["src/checkout/cart.mjs"] },
    { "id": "platform", "owns": ["src/platform/**", "package-lock.json"], "dependsOn": [] }
  ]
}
JSON

node bin/parallel-work-conflict-checker.mjs --lanes lanes.json
node bin/parallel-work-conflict-checker.mjs --lanes lanes.json --json

Read the result

A consumer that pipes stdout must handle an empty stdout on exit 2. That is documented rather than papered over: emitting a fake report for a run that never started would be worse.

Scope

Every limit is enforced and every one has a CLI flag. Reaching one produces an incomplete report naming the limit — never a silent truncation and never a pass.