Salvor in team conditions: merges, Windows and the fine print

Parallel pull requests: 9 conflicts down to 2

Salvor asks every pull request to add a line to the changelog, a row to the version history, a line to L1 and an entry to L2. Every pull request adds them in the same places, so any two open pull requests conflict.

I stacked four of my open pull requests onto the development branch to measure it. As the repository is today, that gave 9 file conflicts across 3 merges. Then I added three lines to .gitattributes:

CHANGELOG.md                     merge=union
VERSION.md                       merge=union
.salvor/active_state_verbose.md  merge=union

With those, the same merges gave 2 conflicts, both in L1. That is the right place for them: Salvor's rule is that L1 is never merged line by line but rewritten from scratch, and a conflict is what forces that. The merged changelog had no duplicate headings, and every version row and L2 entry was kept.

A clean merge that left memory wrong

The opposite case is harder to see. On my static site I merged a feature branch, and git merged L1 with no conflict. But the merged L1 said "local branch, not deployed", which was false on the branch it had just landed on. It stayed wrong for two commits, until the next deploy record overwrote it. Nothing conflicted, so nothing prompted a rewrite.

Windows

I installed the Claude Code plugin on Windows 10 and ran it on a fresh clone of one of my repositories, where git had converted every file to Windows line endings.

• A real task worked cleanly. I asked whether a memory audit was due and to run it. It took 137 seconds and 21 turns and cost $0.53. The audit was correct, L1 and L2 were updated, and the Windows line endings were kept on every line it touched: 8 of 8 in one file and 34 of 34 in the other. It didn't commit and asked me instead, as the rules say.
• The health check didn't run headless at first. Run from a script, it ended with 0 turns and an empty result, 6 times out of 6. Another contributor proposed a fix (pull request #30, still open). I tested it on the same Windows setup: 36 turns, 116 seconds and a full report. The status command worked in both cases.
• A code-intelligence server wrote into my repository. One of the optional helper servers created its own config and memory folder inside the repository without asking. Nothing broke, but check git status after the first run.

Reading the protocol closely

Testing the behavior only tells you so much, so I also read the rules line by line. Two examples:

• Delete or never delete? One rule says to delete a deferred finding once it's fixed. Another says an ID must never be deleted so references don't break. A commit that says "closes deferred:x" is exactly such a reference. I reported it and proposed closing entries instead of deleting them.
• The docs. Four read-only agents each audited one area of the repository: docs, the plugin, the protocol text and the benchmark code. I checked the key claims myself. All relative links and anchors worked, with 0 broken. The small things they found, like the contributing guide not naming the development branch, became pull requests.

My pull requests and issues

Everything below came out of the tests in this series. All the pull requests are open and waiting for review.

Pull requests:

• #25: name dev as the pull request target, and install Chromium before running the unit tests.
• #26: one plain-language line per option before an approval question, so a long review doesn't turn into a formality.
• #27: guidance for repositories that are served by a web server, from the setup notes.
• #28: how to remove Salvor without losing the knowledge in it.
• #33: optional hooks that refresh the state note at the start of a session.
• #34: pin the code-intelligence server version and bind it to the working directory.
• #35: close deferred findings instead of deleting them.

Issues:

• #32: the deferred-finding rules contradict each other.
• #36: the headless health check hits permission prompts on every run.
• #37: the blind question test, and stale memory as the gap to close.
• #40: what an agent may change in an existing learned failure.