Six sessions, one Songsterr tab

What today's chats were doing to each other, and the lock that stops it

16 August 2026 · measured from six session transcripts and the live revision backup

Six Claude sessions worked The Ship guitar tabs today. Three were parked holding a finished file, waiting for a human to upload it. Two were driving the same browser tab, flipping it between songs under each other. One had halted on a belief that turned out to be wrong.

What each session was actually doing

Which revision is new, and what is in it

This was the actual complaint. Songsterr records the author of every revision as one account, Brandon's, because six sessions and his own hand-uploads all sign in as him. So when a session uploads, and Brandon uploads, and a third session uploads over both, the tab attributes all three to the same person. Two sessions today held opposite beliefs about who made r8516072.

Settled from timestamps: the revision was submitted at 21:11:57Z, and Brandon's message "uploaded latest and hit submit" arrived at 21:14:03Z. It is his, by hand. Here is what it changed, counted per part from the live backup:

His edit is a dedup of the two guitar staves and nothing else. That is his own correction, "02 Flake, duplicated lead notes", which he applied by hand because the pipeline did not. Both parked sessions hold builds that predate it. Importing either one as-is puts all 303 duplicate notes back.

The vocal track a name check misses

"Make sure each is doing it with a file with vocal drum etc" has a trap on this exact tab. The fifth part carries the vocal line. Measured on s5823892:

• the track has no name at all, an empty string
• the instrument is Tenor Sax, General MIDI program 66
• the lyrics array is empty, zero entries
• it holds 310 notes across 69 bars

The pipeline writes vocals onto a Tenor Sax patch, and the upload gate knows to classify by name rather than by program for that reason. On a tab that has been round-tripped through Songsterr the name is gone entirely, so the classifier returns other:tenor sax:

# measured, not asserted
part4 name      : ''
part4 instrument: Tenor Sax / id 66
newLyrics       : list, len 0
notes           : 310 across 69 bars

role_of('Tenor Sax')             -> 'other:tenor sax'
role_of('Tenor Sax', program=66) -> 'other:tenor sax'

VERDICT: a name-based full-band check reports NO VOCAL
         on a tab that has 310 notes of vocal line.

A gate reading that as a missing vocal would either block a good upload or wave through a file that really did drop the part. Full band gets verified by per-part note content, and not from what the track is called. That is now written into the skill.

The lock

importRevisionInput replaces the entire tab. Two overlapping imports do not merge. The second one wins outright and the first session's work is gone with no error raised anywhere, which is how a five-track tab became a one-track tab on a previous occasion.

The deploy pipeline already solved this shape for Vercel: one door, a flock, concurrent ships wait their turn. A flock is no use here, because an upload spans many tool calls across many turns and a flock dies with the process holding it. So the new tool takes a lease: a file that records the holder, with an expiry, taken before the browser is touched and released once the upload finishes.

# before touching the browser
upload_lease.py acquire --session "Theship tabs delivery handoff" \
    --song "02 Flake" --tab s5823892

# after the upload finishes
upload_lease.py record  --session "Theship tabs delivery handoff" \
    --song "02 Flake" --tab s5823892 --rev r8516072 \
    --tracks 5 --roles vocal,drums,bass,guitar,guitar
upload_lease.py release --session "Theship tabs delivery handoff"

upload_lease.py status              # who holds it right now
upload_lease.py latest --tab s5823892   # which revision is new, and whose

The lease self-expires after twenty minutes, so a session that dies mid-upload cannot deadlock the others. That is deliberate. A stuck lock is worse than a race, because a race at least gets noticed.

Tested before any session was told to rely on it

12 sessions raced for the lease at once
  winners: [2]
  refused: 11
  VERDICT: PASS, exactly one winner

peer acquire, lease held      -> exit 1, refused
peer release of another lease -> exit 1, refused
acquire after 2s expiry       -> exit 0, granted
record without vocal + drums  -> WARNING, flagged in the ledger

It closed the loop within eight minutes

The sessions were messaged at 21:22Z. Confirmed independently from Songsterr's own revision API for song 5823892, rather than from the ledger. Checking that API also corrected two things I had assumed:

A session took the lease, made its revision, recorded it and released, with no human asked to submit anything. Every revision on this tab carries all five tracks. No import has dropped a part. The parked session that had renamed itself and stopped is running again, and the ledger now answers the original question in one command:

upload_lease.py latest --tab s5823892

  02 Flake   s5823892   rev r8516250   5 tracks   2026-08-16T21:29:00Z
      by Resume goal completion shipping  via session

What changed, so this does not need watching again

• Every session was messaged with the rule, the lease commands, and the specific finding it needed. The two parked ones got the note diff so they rebase rather than overwrite.
• The rule now lives in the skill itself. songsterr-upload/SKILL.md now opens with it, so a session that never sees this page still gets it.
• The ledger answers the original question. Every upload appends the song, the tab, the revision, the track roles it carried, and who did it. Brandon's hand-uploads are recorded too, marked --source brandon. Both Flake revisions are already seeded from the live backup.
• A recorded upload missing vocal, drums, bass or guitar gets flagged in the ledger at write time, so a thin file leaves a trace rather than passing quietly.