yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

Agent docs still say the WAV fixtures scan in untitled, and name a test #104 deleted #225

New Issue
Open
opened 2026-08-26 11:41:10 +00:00 by logan · 2 comments
logan commented 2026-08-26 11:41:10 +00:00
Collaborator
Copy Link
Copy Source

Report

.pi/skills/yellowjacket-dev/references/fixtures.md still tells an
agent that the fixture library's WAVs scan in untitled, and names a
test that no longer exists:

  • WAV tracks scan in untitled. backend/tagwriter writes WAV tags
    into a RIFF id3 chunk and dhowden/tag has no RIFF parser, so
    there is no "Field Recordings" artist in the Artists view. This is a
    known open bug pinned by TestWAVTagsAreNotReadableYet; do not
    "fix" a spec by asserting the broken behaviour elsewhere.

#104 added backend/riff and made the scan read that chunk, and it
deleted TestWAVTagsAreNotReadableYet in the same change — the test
existed to say the reader did not work and failed the moment it did.

Measured against a make dev-headless SEED=default app on main
(/__test/sql over audio_files joined to albums):

 19  album='Test Tones'  title='Tone B'  Field Recordings/Test Tones/02 Tone B.wav
 20  album='Test Tones'  title='Tone A'  Field Recordings/Test Tones/01 Tone A.wav

So there is a "Field Recordings" artist in the Artists view, and the
paragraph is wrong in every sentence including its instruction. That
last clause is what makes this worth filing rather than leaving: it
tells the next agent that a spec asserting the working behaviour is
the mistake.

The same staleness, two more places

.planning/NOTES.md carries it twice, in dated entries:

  • ## "The first N tracks" is not a way to ask for an ordinary one (2026-08-20) — "Four tracks in the fixture library have no album at
    all — 01 Tone A, 02 Tone B, Title Only, no-tags-at-all".
    There are two: unsorted/no-tags-at-all.mp3 and
    unsorted/title-only.mp3.
  • the sheet-overflow entry — "on the first track of the fixture
    library — which has no album (01 Tone A, 02 Tone B) — only 'Go to
    Artist' appears. That is the 8 above; an ordinary track makes it 9."
    The measurement of 8 items was true when taken; the track it was
    taken on is no longer an example of the case, so a re-measurement
    would now report 9 and read as a contradiction.

Both were true when written, and NOTES.md is explicitly dated measured
history rather than a live document — so whether those two get a
correcting clause or are left alone is a judgement about what that file
is for, and is the reason this is filed rather than fixed in passing.
fixtures.md is not history: it is an instruction, and it is wrong.

Found while doing #217, which is the same #104 staleness in
e2e/specs/queue-selection.spec.ts's comment. Filed separately because
that issue is scoped to the spec, and because the NOTES half needs a
decision this run should not make on its own.

**Report** `.pi/skills/yellowjacket-dev/references/fixtures.md` still tells an agent that the fixture library's WAVs scan in untitled, and names a test that no longer exists: > - **WAV tracks scan in untitled.** `backend/tagwriter` writes WAV tags > into a RIFF `id3 ` chunk and `dhowden/tag` has no RIFF parser, so > there is no "Field Recordings" artist in the Artists view. This is a > known open bug pinned by `TestWAVTagsAreNotReadableYet`; do not > "fix" a spec by asserting the broken behaviour elsewhere. #104 added `backend/riff` and made the scan read that chunk, and it deleted `TestWAVTagsAreNotReadableYet` in the same change — the test existed to say the reader did not work and failed the moment it did. Measured against a `make dev-headless SEED=default` app on `main` (`/__test/sql` over `audio_files` joined to `albums`): ``` 19 album='Test Tones' title='Tone B' Field Recordings/Test Tones/02 Tone B.wav 20 album='Test Tones' title='Tone A' Field Recordings/Test Tones/01 Tone A.wav ``` So there *is* a "Field Recordings" artist in the Artists view, and the paragraph is wrong in every sentence including its instruction. That last clause is what makes this worth filing rather than leaving: it tells the next agent that a spec asserting the *working* behaviour is the mistake. **The same staleness, two more places** `.planning/NOTES.md` carries it twice, in dated entries: - `## "The first N tracks" is not a way to ask for an ordinary one (2026-08-20)` — "Four tracks in the fixture library have no album at all — `01 Tone A`, `02 Tone B`, `Title Only`, `no-tags-at-all`". There are two: `unsorted/no-tags-at-all.mp3` and `unsorted/title-only.mp3`. - the sheet-overflow entry — "on the *first* track of the fixture library — which has no album (`01 Tone A`, `02 Tone B`) — only 'Go to Artist' appears. That is the 8 above; an ordinary track makes it 9." The measurement of 8 items was true when taken; the track it was taken on is no longer an example of the case, so a re-measurement would now report 9 and read as a contradiction. Both were true when written, and NOTES.md is explicitly dated measured history rather than a live document — so whether those two get a correcting clause or are left alone is a judgement about what that file is for, and is the reason this is filed rather than fixed in passing. `fixtures.md` is not history: it is an instruction, and it is wrong. **Found while doing** #217, which is the same #104 staleness in `e2e/specs/queue-selection.spec.ts`'s comment. Filed separately because that issue is scoped to the spec, and because the NOTES half needs a decision this run should not make on its own.
logan added the
Reviewed
Confirmed
1
Kind/Documentation
Priority
Low
4
 labels 2026-08-26 11:41:10 +00:00
logan self-assigned this 2026-08-30 07:33:20 +00:00
logan added the
Status
In Progress
 label 2026-08-30 07:33:20 +00:00
logan commented 2026-08-30 07:33:21 +00:00
Author
Collaborator
Copy Link
Copy Source

Picking this up on branch docs/225-fixtures-wav-tags.

Scope: the mechanical half only. .pi/skills/yellowjacket-dev/references/fixtures.md is an instruction rather than history, and the WAV paragraph is wrong in every sentence including the one that tells the next agent not to "fix" a spec asserting the working behaviour. I will re-measure against a running make dev-headless SEED=default app rather than editing from the issue text, and correct the paragraph to what the app actually reports.

Deliberately not decided here: whether the two dated .planning/NOTES.md entries get a correcting clause or are left as measured history. The issue is explicit that this is a judgement about what that file is for, and this run is not the place to settle it. It stays open on this issue for a human.

Picking this up on branch `docs/225-fixtures-wav-tags`. **Scope: the mechanical half only.** `.pi/skills/yellowjacket-dev/references/fixtures.md` is an instruction rather than history, and the WAV paragraph is wrong in every sentence including the one that tells the next agent not to "fix" a spec asserting the working behaviour. I will re-measure against a running `make dev-headless SEED=default` app rather than editing from the issue text, and correct the paragraph to what the app actually reports. **Deliberately not decided here:** whether the two dated `.planning/NOTES.md` entries get a correcting clause or are left as measured history. The issue is explicit that this is a judgement about what that file is for, and this run is not the place to settle it. It stays open on this issue for a human.
logan commented 2026-08-30 07:51:06 +00:00
Author
Collaborator
Copy Link
Copy Source

PR #230 — #230 — CI green (check + e2e, run 18462).

The half that shipped

fixtures.md's WAV paragraph is corrected. Measured rather than edited from this issue's text, and the seed had to be rebuilt before anything could be measured, which is worth recording here: .dev/seeds/default.tar on that worktree was stamped 2026-08-24 and #104 merged 2026-08-25, so restoring it would have replayed a pre-#104 scan, reported untitled WAVs, and confirmed the stale paragraph. A clean measurement of the wrong build.

On a rebuilt make sandbox-seed NAME=default (31 tracks) via /__test/sql:

  • both WAVs carry title (Tone A / Tone B), artist_credit, artist_id → Field Recordings, album_id → Test Tones, track numbers 1 and 2;
  • the Artists view's own grouping query returns Field Recordings, 2 tracks — so the "there is no Field Recordings artist" sentence is false at the exact layer it claims;
  • Test Tones has a real cover_art row;
  • TestWAVTagsAreNotReadableYet exists in no Go file — only in prose;
  • the only two tracks with no album at all are unsorted/no-tags-at-all.mp3 and unsorted/title-only.mp3, independently reproducing #217's number.

The replacement also states that prose written before #104 disagrees, because it does and this change does not touch it — without that line the next reader reintroduces the claim from a source still sitting in the repo.

The half that did not, and why this is still open

PR #230 carries no Closes footer on purpose, so merging it will not close this issue.

The .planning/NOTES.md question is exactly as you framed it: whether two dated entries get a correcting clause or are left as measured history is a judgement about what that file is for. Auto-closing would settle it by making it vanish, so I left it. Same argument for .planning/plans/completed/005-agent-development-harness.md, which carries the claim too.

So this needs a human for one decision:

  1. correct the two NOTES.md entries (and plan 005) with a dated clause, or
  2. leave them as history and close this issue on #230 alone.

Status/In Progress is still on per the run's convention, but nobody is working the remaining half — it is waiting on that call, not on an agent.

**PR #230** — https://git.ljones.me/yonlu/yellowjacket/pulls/230 — CI green (`check` + `e2e`, run 18462). ## The half that shipped `fixtures.md`'s WAV paragraph is corrected. Measured rather than edited from this issue's text, and **the seed had to be rebuilt before anything could be measured**, which is worth recording here: `.dev/seeds/default.tar` on that worktree was stamped 2026-08-24 and #104 merged 2026-08-25, so restoring it would have replayed a pre-#104 scan, reported untitled WAVs, and *confirmed the stale paragraph*. A clean measurement of the wrong build. On a rebuilt `make sandbox-seed NAME=default` (31 tracks) via `/__test/sql`: - both WAVs carry `title` (`Tone A` / `Tone B`), `artist_credit`, `artist_id` → **Field Recordings**, `album_id` → **Test Tones**, track numbers 1 and 2; - the Artists view's own grouping query returns **Field Recordings, 2 tracks** — so the "there is no Field Recordings artist" sentence is false at the exact layer it claims; - `Test Tones` has a real `cover_art` row; - `TestWAVTagsAreNotReadableYet` exists in **no Go file** — only in prose; - the only two tracks with no album at all are `unsorted/no-tags-at-all.mp3` and `unsorted/title-only.mp3`, independently reproducing #217's number. The replacement also states that prose written before #104 disagrees, because it does and this change does not touch it — without that line the next reader reintroduces the claim from a source still sitting in the repo. ## The half that did not, and why this is still open **PR #230 carries no `Closes` footer on purpose, so merging it will not close this issue.** The `.planning/NOTES.md` question is exactly as you framed it: whether two *dated* entries get a correcting clause or are left as measured history is a judgement about what that file is for. Auto-closing would settle it by making it vanish, so I left it. Same argument for `.planning/plans/completed/005-agent-development-harness.md`, which carries the claim too. So this needs a human for one decision: 1. correct the two NOTES.md entries (and plan 005) with a dated clause, or 2. leave them as history and close this issue on #230 alone. `Status/In Progress` is still on per the run's convention, but nobody is working the remaining half — it is waiting on that call, not on an agent.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Kind/Documentation
Priority
Low
4
Reviewed
Confirmed
1
Status
In Progress
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees logan
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#225