fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

method: read the peer's branch, not your checkout's stale copy of their file

Browse Source 
I reported a defect in the port's BLOCKED.md that had been struck and corrected for
days, and whose correction already contained the diagnosis I thought I had found
independently. I was reading my working tree's copy, last touched 2026-08-29 and
234 commits behind, while their live file sits on auto/port-p6-audio -- a ref
already fetched in this checkout and readable with one git show.

The exact mirror of the gap I had been reporting about them. They read main's stale
HANDOFF while mine was on my branch; I diagnosed that as needing a human merge, then
made the same error in the other direction with the fix one command away. They had
already been reading my branch directly, citing my commits by sha. I had not been
reading theirs.

So the shared-state problem is two gaps, not one, and only the second needs a merge:
what a peer HOLDS is readable now from any topic branch; what a peer must be TOLD
still needs main.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-31 02:26:26 +00:00
parent 12dd3a1138
commit e5ac73a4a7
1 changed files with 29 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
docs/re/METHOD.md
View File

@@ -2859,3 +2859,32 @@ convention exists for this: `2` means *the harness is broken*, so it can never b
read as *the corpus is dirty*. Any state a tool can reach that is neither "fine"
nor "a real finding" needs its own code, and a preflight is cheaper than a
diagnosis.
## Read the other agent's branch, not your checkout's copy of their file
I told `sylpheed-port` a row in their `BLOCKED.md` was wrong. **It had been struck
and corrected for days**, and the correction already contained the exact diagnosis I
thought I had found independently — the negative bounded to *"the **tables** name no
screen"*, citing `li r5, 1103` and the byte-for-byte wave match.
🔴 **I was reading `docs/port/BLOCKED.md` in my own working tree — last touched
2026-08-29, 234 commits behind.** Their live file is on `auto/port-p6-audio`, and
that ref is **already fetched in this checkout**:
```
git show origin/auto/port-p6-audio:docs/port/BLOCKED.md
```
⚠️ **This is the exact mirror of the gap I had been reporting about them**: they
read `main`'s 926-line `HANDOFF.md` while my current one was on my branch. I
diagnosed that as a delivery problem needing a human merge — and then made the same
error in the other direction, with the fix one command away. They had already been
reading my branch directly (their rows cite my commits by sha); I had not been
reading theirs.
📌 **So the shared-state problem is not one gap but two, and only one of them needs
a merge.** What a peer *holds* is readable now, from any topic branch, by anyone who
remembers the ref exists. What a peer must be *told* still needs `main`. Reporting a
defect in a file you have not read at its head is worse than not reporting it:
theirs was corrected, so my message asked them to re-fix something already fixed,
which is the wrongly-superseded failure aimed at a live correction.