The Zappa handoff, checked for lies

Two handoffs carry the Zappa drum repair. [ZAPPA-DRUM-REPAIR-2026-08-31] was written on the iMac and saved at 13:52 CDT. [ZAPPA-BASELINE-RECOVERED-2026-08-31] was written on this MacBook and saved at 17:42 CDT. Every falsifiable number in both was re-derived here with a GPIF parser written for this audit alone, so no verdict below leans on the tool that produced the claim. Audited 2026-08-31 on MacBookPro.

Verdict: nothing was invented, and one claim has expired

Twenty-six claims went through the check. Nineteen reproduce exactly, including every count, every meter and every named bar. One reproduces after a wording correction.

One was true when it was tested and is false now, and that one changes what the next session should do first. One drifted in the hours after the handoff was saved. One is broader than the evidence behind it. Two need the other machine and stay untested.

The expired claimThe overstated oneThe drift and a tool bugThe wordingWhat reproducedNewly testableUntested hereHow it keeps runningReproduce itSources
19
claims reproduced exactly
1
true then, false now
3
overstated, drifted, or buggy
21,385
events compared, zero differences
7,479
events re-derived independently
2
need the other machine

The finding that changes the work: the iMac bundle already landed

This is the one claim a next session would act on and be wrong.

The handoff's s*/ tree, the ORIGINAL-*.gp baselines, the 139.6 MB source archive and five of six tools are NOT on the MacBook. Confirmed by find, Spotlight, an empty Trash, no Time Machine destination, an unmounted T7 Shield, and no Zappa bundle in sfg/.

Still blocked: 1. The iMac working tree, via sfg/. Queued q-2026-08-31-45a6f4.

Time, CDTEventEvidence
13:52:49iMac handoff savedfile mtime
13:56:57MacBook session runs ls sfg | grep -i zappa and gets nothingsession transcript, 2026-08-31T18:56:57Z
14:01:13sfg/zappa-drum-repair-2026-08-31/ appears with 19 .gp filesdirectory mtime
17:42:51MacBook handoff saved, still carrying the 13:56 findingfile mtime

The sfg check was honest at the moment it ran. The bundle landed four minutes later, and the finding travelled into the handoff three hours and forty-six minutes afterwards as present tense.

What actually sits on this Mac right now

  1. 19 .gp files across 7 song folders, every one fully downloaded, with no iCloud placeholders.
  2. 10 ORIGINAL-*.gp immutable baselines, the exact class the handoff calls absent. Two of the ten are the same download under two names, which the bundle's own MANIFEST.md states.
  3. ORIGINAL-Frank Zappa-Zomby Woof-05-31-2026.gp, the pre-work community baseline, dated to the day revision r7115188 was created.

The MacBook handoff says any claim needing the untouched community text must wait for r7115188 itself. That wait is over. The file is here, it renders the same 7,479 events as the recovered r8766102, and its ten per-track counts match the iMac census one for one.

The overstated one: the test suite is green in one tree of two

The test suite ran zero of its assertions and now runs 47.
test_comparison_basis.py exit 1 ImportError -> exit 0, 8/8 cases.
test_promotion_rule.py exit 1 TypeError -> exit 0, 38/38 cases.

That holds in ~/Projects/_outputs/kilgore-guitar-tools/_tests/. All three files exit 0 there, 8 of 8 and 38 of 38, and the new is_guitar test passes. Two other places still carry the original failure.

Locationtest_comparison_basis.pytest_promotion_rule.py
kilgore-guitar-tools/_tests/exit 0, 8/8exit 0, 38/38
kilgore-guitar/2026-08-13-macbook/tools/_tests/exit 1, same ImportErrorexit 1, same TypeError
sfg/zappa-macbook-return-2026-08-31/impossible-gate-fix/exit 1, same ImportErrorexit 1, same TypeError

The bundle copy fails for a packaging reason. Its two module copies were renamed to impossible_gate.SKILL-COPY.py and impossible_gate.KILGORE-TOOLS-COPY.py, so the tests find no impossible_gate.py in their own directory and fall back to the skill copy. That fallback is the exact defect the fix was written to remove, and the iMac will see red on both files.

The count is soft as well. The two suites print 46 cases between them, and the third prints one PASS line covering 10 tracks and 6 string cases. 47 reconciles only by counting the third file as a single assertion.

The drift, and the tool bug under it

Now 727 of 727 linked, zero dead links, header corrected to 727 entries, last verified 2026-08-31.

The substance of that repair holds. Every memory file is linked and every link resolves, which I re-ran and confirmed. The header number stopped tracking, and the reason is a defect in the tool the handoff shipped.

memory files       : 731
linked by POINTERS : 731
MISSING from POINTERS : 0
DEAD links in POINTERS: 0
FINAL: 731 files, 731 linked, 0 missing, 0 dead
POINTERS.md is COMPLETE: every file linked, every link resolves
exit 0

header line still reads: 727 entries, last verified 2026-08-31

--header is a one-shot that reports nothing when it fires blank

The header rewrite matches one pattern only:

re.sub(r'Every memory file with its own description, \d+ entries, '
       r'regenerated [\d-]+\.', ...)

The 2026-08-31 run replaced regenerated 2026-08-04 with last verified 2026-08-31, so the pattern stopped matching its own output. Every later --fix --header run changes nothing, prints nothing about it, and exits 0. I ran it during this audit and watched it append one entry and leave the count at 727 against 731 files.

The append-only claim does hold. The script writes new entries under one appended heading and never rewrites an existing line, which reading the source confirms.

The wording: twelve switch points

The musical finding is intact. The word "switch" is counting spans.

Measured from _outputs/songsterr-zappa-paren-fix/s412162/bar-census-r8766102.json, the 114-bar census parsed out of r8766102-Zomby-Woof.gp.

36  : bars 1-8       -> 35 : 9    Verse 1
35  : bars 9-12      -> 36 : 13   Pre-Chorus 1
36  : bars 13-15     -> both : 16
both: bars 16-17     -> 35 : 18   Chorus 1
35  : bars 18-39     -> 36 : 40
36  : bars 40-43     -> 35 : 44
35  : bar 44         -> both : 45
both: bar 45         -> 35 : 46   Bridge
35  : bars 46-55     -> 36 : 56   Solo
36  : bars 56-101    -> 35 : 102
35  : bars 102-111   -> 36 : 112  Head

Spans run from one switch point to the next, so a span can carry bars where neither kick lane sounds. Four spans do: bars 2-4 inside the opening lane-36 span, bars 14-15 inside 13-15, bars 24-25 inside 18-39, and bars 113-114 inside the closing 112-114. Re-verified 2026-09-02 against the same census: no bar inside any span carries the opposite lane, so all twelve spans are contradiction-free.

Twelve spans, eleven boundaries, and seven of the twelve span starts land on a labelled section once bar 1 is counted: bar 1 Head, bar 9 Verse 1, bar 13 Pre-Chorus 1, bar 18 Chorus 1, bar 46 Bridge, bar 56 Solo, bar 112 Head.

What reproduced exactly

Each row was re-derived from the score file by an independent parser, then compared with the handoff text and with the iMac census at drwu-overflow/zappa-drum-tab-forensics/baseline_diff.json. The score file is _outputs/songsterr-zappa-paren-fix/s412162/r8766102-Zomby-Woof.gp, and every bar, meter, tie and kick-lane figure below reads out of the bar-census-r8766102.json census derived from it.

#ClaimSourceIndependent result
120 counts match the iMac census, 7,479 both sidesMacBook10 of 10 per-track note counts match; 10 of 10 tie counts match. Corrected 2026-09-02: "2 tied events per tie" holds on 6 tracks and fails on 3. A mid-chain event carries origin=true destination=true, ending one connection and starting the next, so a chain of N notes is N events for N-1 connections. Frank Zappa 1 has 60 mid-chain events (1.63 per connection), Ruth Underwood 4 (1.88), Bruce Fowler 2 (1.95); 66 in the score. The drum staff has 0, so the conversion is exact there
217 drum lanes, 1,574 totalMacBook17 lanes, 1,574, lane for lane identical to the census
3Bars 1-8 read 3/4, 10/16, 2/4, 5/4, 15/16 x4MacBookexact, and sections read Head, Pre-Verse 1, Verse 1 at bars 1, 5, 9
418 ties, twelve bars namedMacBook36 tied events in bars 16, 17, 18, 22, 32, 34, 35, 36, 38, 44, 104, 108
5Sloots span 32.00 s, +3.2%, flat 88 gives 32.73 sMacBookbars 38-50 total 48 quarters; 32.00 s at 90 bpm, 32.73 s at 88, +3.2% and +5.6% against 31.0 s
6Drum staff playable, max 3 voices, no empty barsMacBookmax 3 notes in one beat, 0 empty drum bars in 114
7r7115188 ghost 32, r8787022 staccato 32, r8766102 neitherMacBookcensus reads ghost [32, 0] and staccato [0, 32], events identical
8Kick on two lanes, 35 over 48 bars, 36 over 60 barsMacBook163 notes on lane 35 across 48 bars, 186 on lane 36 across 60, both lanes in bars 16, 17, 45
94 of 20 songs split, 13 use lane 36 aloneMacBookcensus gives exactly 4 split, 13 lane-36-only, 3 lane-35-only
10Recovered baseline md5 4343175d94bff82235497f5bb5360babMacBookmatches, and the bundled copy matches byte for byte
11Published page returns http 200MacBook200
12Both new revisions still on moderationMacBookre-fetched live: 8787022 and 8766102 both isOnModeration: true, 7115188 public. EXPIRED, re-checked 2026-09-02: songsterr.com/api/meta/412162 returns http 200 unauthenticated and reads revisionId 8814965, latestRevisionId 8814965, prevRevisionId 8787022, isOnModeration false, isPublished true, moderationType "no". So 8787022 went through, and a moderator named Kirill pushed 8814965 on top of it on 2026-09-01 with the description "Minor changes." The live tab has moved off the revision every repair here was built against.
13pointers_check.py only appendsMacBooksource confirms, appends under one heading, never rewrites a line
14is_guitar fixed in three copies, each backed upMacBookthree files and three .bak-pre-isguitar-2026-08-31, all written 17:32
15Zomby Woof goes 0 guitar staves to 2MacBooktest reports 10 tracks resolved, 2 guitars, 0 track names containing the word
16No notes lost by the parentheses sweepiMac6 archived pairs, 21,385 events, zero pitch, rhythm or position differences
17Oh No is sparse: 611 notes, 0 crashes, 0 open hi-hat, 66 barsiMac611 drum events, 66 bars, 0 on lanes 49 and 57, 0 on lane 46
18The AI tab opens 13/16, 4/4, 9/8, 4/4, 7/8 with two empty stavesiMacexact meters, and Lead Guitar and Vocals hold 0 events
19The stacked tom pair is Mid Tom line 4 and Low Tom line 5iMacMid Tom (hit) staff line 4, Low Tom (hit) staff line 5, adjacent
20GPIF Beats and Notes are shared by referenceiMac802 Note definitions render 7,479 events; 36 tied drum events come from 6 Notes

What the arriving bundle made testable for the first time

Rows 16 through 19 were untestable here at the hour the MacBook handoff was written.

s412162-Zomby-Woof-community       10 tracks   7,479 events   0 differing tracks
s35884-Oh-No                        6 tracks   1,669 events   0 differing tracks
s35870-Montana                     18 tracks   7,966 events   0 differing tracks
s412170-Trouble-Every-Day-Live      6 tracks   2,539 events   0 differing tracks
s1105085-The-Black-Page             4 tracks   1,321 events   0 differing tracks
s5820647-Zomby-Woof-AI              5 tracks     411 events   0 differing tracks
TOTAL                                         21,385 events   0 differences

The iMac claimed 20 folders and 120,579 beat events. Six folders travelled, and those six are clean. The other fourteen stay unverified from here.

Two claims this machine cannot test

Recorded as untested rather than accepted

  1. Bars 1-8 corroborated by Ryan Brown in DRUM Magazine and by Drumnet. The published sources live in ~/Projects/_outputs/zappa-drum-sources/ on the iMac, and that archive did not travel.
  2. Audio alignment fails its controls at 45.9% against 48.5% shifted and 47.8% random. No audio came across, so the control cannot be re-run here.

How this keeps running

The audit is a script, so a claim cannot quietly rot between readings.

audit.py re-derives every settled number from the score files and exits non-zero on any drift. It runs 31 checks: 27 settled claims that reproduce today, and 4 open defects that flip to green on their own once someone fixes them.

31 checks, 4 failing
FAIL OPEN    second test tree: test_comparison_basis exit 0   want 0 got 1
FAIL OPEN    second test tree: test_promotion_rule exit 0     want 0 got 1
FAIL OPEN    sfg bundle tests run in place                    want 0 got 1
FAIL OPEN    POINTERS header count matches file count         want 731 got 727

watch.sh fingerprints both handoffs and both sfg bundles once a minute. Any byte that moves triggers a full re-audit into watch.log, so a rewritten handoff gets checked against the files the moment it lands.

~/Projects/_outputs/zappa-handoff-lie-audit/audit.py     31 checks, exit 0 when clean
~/Projects/_outputs/zappa-handoff-lie-audit/watch.sh     INTERVAL=60 ROUNDS=170 ./watch.sh
~/Projects/_outputs/zappa-handoff-lie-audit/watch.log    every pass, stamped

Reproduce this audit

# the timeline that expires the sfg claim
ls -laT ~/Library/Mobile\ Documents/com~apple~CloudDocs/sfg/zappa-drum-repair-2026-08-31
ls -laT ~/Library/Mobile\ Documents/com~apple~CloudDocs/SVG/\[ZAPPA-BASELINE-RECOVERED-2026-08-31\]\ handoff.md

# the two test trees
cd ~/Projects/_outputs/kilgore-guitar-tools/_tests && python3 test_comparison_basis.py; echo $?
cd ~/Projects/_outputs/kilgore-guitar/2026-08-13-macbook/tools/_tests && python3 test_comparison_basis.py; echo $?

# the memory index
python3 ~/.claude/skills/_shared/pointers_check.py

# live moderation state
curl -s https://www.songsterr.com/api/meta/412162/revisions | head -c 400

Sources

Audited on MacBookPro, 2026-08-31. Companion page: zappa-baseline-recovered. Markdown source sits beside this page as zappa-handoff-lie-audit.md.