fix(design-ledger-gate): fail on unresolved merge conflict markers - #1203
Merged
trunk-io[bot] merged 2 commits intoSep 13, 2026
Conversation
The gate parsed a governed file with conflict markers in it and reported OK with rc=0: markers sit between rows, so id uniqueness, status grammar and link resolution all still pass. Verified before the fix on a marker-bearing DECISIONS.md. That matters because the ledger is one append-only file every lane appends to, so conflicts are the steady state rather than an incident, and the pre-enqueue merge-result check runs the gate over an extracted tree. git merge-tree exits non-zero on a conflict but still prints a tree OID, so a recipe that skips the exit code extracts a marker-bearing file and the gate blessed it. Both git and jj marker styles are matched, across the ledger and every record. Refs RIG-3520 Co-authored-by: Matt Wilkinson <matt@rigel.build>
|
😎 Merged successfully - details. |
|
Compass engineering docs preview: https://compass-server-rig-3520-gate.compass-eng-docs.pages.dev Deployed from |
Review found the exact-7 match was a silent false negative. git and jj both widen every conflict marker past 7 when the conflicting hunk itself holds a marker-like run, so an 11-char marker slipped through the check entirely — reintroducing the defect this gate change exists to close. Verified: the shipped regex returns false for the 11-char forms. The opener, closer and both jj markers now match 7-or-more, which is false-positive-free across docs/designs. `=` deliberately stays exact: six 14-char `=` setext underlines live in the manager-prompt record, so widening it would break the gate for every lane. Also skips fenced blocks, matching how the rest of this module reads records, so a record documenting a marker as example text stays green. Refs RIG-3520 Co-authored-by: Matt Wilkinson <matt@rigel.build>
mattwilkinsonn
approved these changes
Sep 13, 2026
trunk-io
Bot
deleted the
compass-server/rig-3520-gate-conflict-markers
branch
September 13, 2026 20:27
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The gate parsed a governed file with conflict markers in it and reported OK
with rc=0: markers sit between rows, so id uniqueness, status grammar and link
resolution all still pass. Verified before the fix on a marker-bearing
DECISIONS.md.
That matters because the ledger is one append-only file every lane appends to,
so conflicts are the steady state rather than an incident, and the pre-enqueue
merge-result check runs the gate over an extracted tree. git merge-tree exits
non-zero on a conflict but still prints a tree OID, so a recipe that skips the
exit code extracts a marker-bearing file and the gate blessed it.
Both git and jj marker styles are matched, across the ledger and every record.
rumdl is not a second net
A future reader will otherwise assume the markdown gate would have caught this.
It does not. On a marker-bearing DECISIONS.md,
rumdl checkreports a singleMD058 "missing blank line after table" — a blank-line nit, auto-fixable — and
rumdl fmtthen formats around the markers: it reportsFixed 1/1 issues,leaves all three markers in the file, and
rumdl checkafterwards reportsSuccess: No issues found. So the one incidental signal is consumed by aformatter that launders the corruption into a clean-looking diff. Verified this
session.
Marker width
The first commit matched runs of exactly 7, which was itself a silent false
negative: git and jj both widen every marker past 7 when the conflicting hunk
holds a marker-like run, and an 11-char marker was not matched at all. The
opener, closer and both jj markers now match 7-or-more (zero false positives
across docs/designs, grep-verified).
=deliberately stays exact — six 14-char=setext underlines live in the manager-prompt record, so widening it wouldbreak the gate for every lane.
Found by compass-ux and compass-managed while flagging a DL-364 collision on
#1169; compass-managed identified the merge-tree exit-code behaviour.
Refs RIG-3520