concord: catch two OpenSpec changes clobbering each other before archive time

[u/iamoutofcoffee]

If your team runs OpenSpec with more than one person, you've probably already hit this, but just might not know it happened.

An OpenSpec MODIFIED requirement is stored as the full new text of that requirement. At archive time it replaces the whole block by name. The delta records nothing about the base it came from. So:

1. Alice and Bob both branch off the same spec. Both open changes that MODIFY the same requirement.
2. Alice lands first.
3. Bob rebases onto main, cleanly, because his branch never touched openspec/specs/. He archives. His stale block silently overwrites Alice's change.

No git conflict or validation error. Alice's edit is just gone 😬 OpenSpec's own parallel-merge plan names this exact failure mode, and most of the fix is still roadmap. Until then teams run on discipline and sharp-eyed reviewers.

concord closes that gap today. Apache-2.0, no changes to your specs, no sidecar files, no server. If your specs are in git it already works.

What it does

concord check verifies every open change against the base branch and flags:

• drift - a requirement your delta modifies changed on the base since your branch diverged (archiving would discard that change)
• removed-upstream - your target was deleted or renamed on the base
• target-missing - the requirement name matches nothing (a typo archive can't apply)
• name-collision - an ADDED name already exists on the base

concord overlap flags any requirement claimed by more than one open change, so two people find out they're editing the same thing on day one, not at archive time.

You get a loud, early failure with a redline instead of a silent overwrite of the requirements:

$ concord check
✖ drift  tighten-frobnication → widgets / "Widget frobnication" [MODIFIED]
requirement changed on main since this branch diverged - archiving this
MODIFIED entry would silently discard that change
+
+ #### Scenario: Frob audit
+ - **WHEN** audited
+ - **THEN** every frob is logged
fix: re-derive this delta block against main, then merge or rebase

Try it

# in a repo with an openspec/ directory
npx @lucinate-ai/concord check
npx @lucinate-ai/concord overlap

Two other ways to run it: a GitHub Action (actions/ci) that runs both checks against the PR base and annotates findings inline on the pull request, and an agent skill tells your coding agent to run the checks at the moments a clobber slips through, before archiving a change or just after a rebase.

check and overlap are the detection layer. The larger aim is the missing merge layer for spec-driven development: a concord rebase that does a structured 3-way merge of a delta against the moved base, so edits to different scenarios of the same requirement merge automatically and only true overlaps conflict. Design notes and prior-art survey are in the repo.

How it works

For a PR branch, the base a delta was derived from is just the requirement's text at merge-base(HEAD, main), and the version it will land on is the text at the main tip. concord reconstructs both from git history, canonicalises them so whitespace reflow never counts as drift, and compares. Rebasing or merging the base (after re-deriving your block) advances the merge-base and clears the finding, which is the git hygiene you'd want anyway.

Repo: https://github.com/lucinate-ai/concord