.pi/skills/yellowjacket-dev/references/fixtures.md still told an agent that the fixture library's WAVs scan in untitled, that there is no "Field Recordings" artist in the Artists view, and that this is "a known open bug pinned by TestWAVTagsAreNotReadableYet" — a test #104 deleted, because it existed to assert the reader did not work and failed the moment it did.
The paragraph ended do not "fix" a spec by asserting the broken behaviour elsewhere, which is what makes it worse than stale prose: it is an instruction, and it tells the next agent that a spec asserting the working behaviour is the mistake. Same #104 staleness #217 removed from queue-selection.spec.ts, one file over, still telling agents to put it back.
What changed
One paragraph in one file. It now says the WAVs scan like every other format, names #104 and backend/riff as the reason, names the two tracks that really do have no album, and warns that prose written before #104 disagrees.
That last clause is deliberate. .planning/NOTES.md and .planning/plans/completed/005-agent-development-harness.md still carry the old claim, and this change does not touch either — so without a line saying "older prose disagrees, it is history", the next reader reintroduces the error from a source that is still sitting there.
Verification
The seed had to be rebuilt before anything could be measured, and that is the interesting part..dev/seeds/default.tar on this worktree was stamped 2026-08-24; #104 merged 2026-08-25. Restoring it would have replayed a database scanned by a pre-#104 binary, reported untitled WAVs, and confirmed the stale paragraph — a clean measurement of the wrong build. The seed rule in this same file is written for schema changes; it applies just as hard to a change in what the scanner reads.
So: make sandbox-seed NAME=default (31 tracks, rebuilt with current main), then make dev-headless SEED=default with YJ_CORE_INDEX_URL at a dead address, then /__test/sql.
claim in the old paragraph
measured
WAVs scan in untitled
title = Tone A / Tone B, track_number 1 / 2
no "Field Recordings" artist in the Artists view
the Artists grouping query returns Field Recordings, 2 tracks
(implied) no album
both on album_id → Test Tones, which has a real cover_art row
TestWAVTagsAreNotReadableYet pins it
present in no Go file; only in prose (NOTES.md, plan 005, the journal, and this file)
The only two tracks with no album at all are unsorted/no-tags-at-all.mp3 and unsorted/title-only.mp3 — #217's number, independently reproduced.
Tiers run
make skill-check — 47 documented make targets, all present. Unchanged, as expected: the edit names no target. Also ran as a pre-commit hook on the staged file.
Swept .pi/skills/ for any other stale WAV claim: the only two other mentions are the format list and the case list, both correct.
make dev-stop afterwards; port 34115 was free before I started and is released again.
Tiers deliberately not run — no Go, no .sql, no .templ, no bound signature, no frontend/src: make lint, make test, make generate, make bindings, make ui-test and make e2e do not apply. Nothing renders, so no screenshot tier. CLAUDE.md already describes the post-#104 behaviour correctly and needed no edit.
What this deliberately does not do
It does not close#225, and carries no Closes footer on purpose.
#225 has two halves. The second is the same staleness in two dated.planning/NOTES.md entries (the "first N tracks" entry and the sheet-overflow one, both of which use the WAVs as their albumless example). The issue is explicit that whether dated measured history gets a correcting clause or is left exactly as taken is a judgement about what that file is for — and it says so as its reason for existing rather than being fixed in passing.
Auto-closing on merge would settle that question by making it disappear, so the footer is omitted and the issue stays open on its second half for a human. fixtures.md is not history: it is an instruction, and it was wrong. That is the half that shipped here.
Same argument applies to .planning/plans/completed/005-agent-development-harness.md, which carries the claim too and is history by the same reasoning.
## What the issue was
`.pi/skills/yellowjacket-dev/references/fixtures.md` still told an agent that the fixture library's WAVs scan in untitled, that there is no "Field Recordings" artist in the Artists view, and that this is "a known open bug pinned by `TestWAVTagsAreNotReadableYet`" — a test #104 deleted, because it existed to assert the reader did not work and failed the moment it did.
The paragraph ended `do not "fix" a spec by asserting the broken behaviour elsewhere`, which is what makes it worse than stale prose: it is an **instruction**, and it tells the next agent that a spec asserting the *working* behaviour is the mistake. Same #104 staleness #217 removed from `queue-selection.spec.ts`, one file over, still telling agents to put it back.
## What changed
One paragraph in one file. It now says the WAVs scan like every other format, names #104 and `backend/riff` as the reason, names the two tracks that really do have no album, and warns that prose written before #104 disagrees.
That last clause is deliberate. `.planning/NOTES.md` and `.planning/plans/completed/005-agent-development-harness.md` still carry the old claim, and this change does not touch either — so without a line saying "older prose disagrees, it is history", the next reader reintroduces the error from a source that is still sitting there.
## Verification
**The seed had to be rebuilt before anything could be measured, and that is the interesting part.** `.dev/seeds/default.tar` on this worktree was stamped 2026-08-24; #104 merged 2026-08-25. Restoring it would have replayed a database scanned by a **pre-#104 binary**, reported untitled WAVs, and *confirmed the stale paragraph* — a clean measurement of the wrong build. The seed rule in this same file is written for schema changes; it applies just as hard to a change in what the scanner reads.
So: `make sandbox-seed NAME=default` (31 tracks, rebuilt with current `main`), then `make dev-headless SEED=default` with `YJ_CORE_INDEX_URL` at a dead address, then `/__test/sql`.
| claim in the old paragraph | measured |
|---|---|
| WAVs scan in untitled | `title` = `Tone A` / `Tone B`, `track_number` 1 / 2 |
| no "Field Recordings" artist in the Artists view | the Artists grouping query returns **Field Recordings, 2 tracks** |
| (implied) no album | both on `album_id` → **Test Tones**, which has a real `cover_art` row |
| `TestWAVTagsAreNotReadableYet` pins it | present in **no Go file**; only in prose (NOTES.md, plan 005, the journal, and this file) |
The only two tracks with no album at all are `unsorted/no-tags-at-all.mp3` and `unsorted/title-only.mp3` — #217's number, independently reproduced.
**Tiers run**
- `make skill-check` — `47 documented make targets, all present`. Unchanged, as expected: the edit names no target. Also ran as a pre-commit hook on the staged file.
- Swept `.pi/skills/` for any other stale WAV claim: the only two other mentions are the format list and the case list, both correct.
- `make dev-stop` afterwards; port 34115 was free before I started and is released again.
**Tiers deliberately not run** — no Go, no `.sql`, no `.templ`, no bound signature, no `frontend/src`: `make lint`, `make test`, `make generate`, `make bindings`, `make ui-test` and `make e2e` do not apply. Nothing renders, so no screenshot tier. `CLAUDE.md` already describes the post-#104 behaviour correctly and needed no edit.
## What this deliberately does not do
**It does not close #225, and carries no `Closes` footer on purpose.**
#225 has two halves. The second is the same staleness in two **dated** `.planning/NOTES.md` entries (the "first N tracks" entry and the sheet-overflow one, both of which use the WAVs as their albumless example). The issue is explicit that whether dated measured history gets a correcting clause or is left exactly as taken is a judgement about what that file is for — and it says so as its reason for existing rather than being fixed in passing.
Auto-closing on merge would settle that question by making it disappear, so the footer is omitted and the issue stays open on its second half for a human. `fixtures.md` is not history: it is an instruction, and it was wrong. That is the half that shipped here.
Same argument applies to `.planning/plans/completed/005-agent-development-harness.md`, which carries the claim too and is history by the same reasoning.
Refs #225
`fixtures.md` told an agent the WAV fixtures scan in untitled, that
there is no "Field Recordings" artist in the Artists view, and that
this is a known open bug "pinned by TestWAVTagsAreNotReadableYet" — a
test #104 deleted, because it existed to assert the reader did not work
and failed the moment it did.
That last clause is why this is worth a diff rather than being left to
rot: the paragraph is an instruction, and it instructs the next reader
that a spec asserting the *working* behaviour is the mistake. It is the
same #104 staleness #217 removed from `queue-selection.spec.ts`, one
file over, still telling agents to put it back.
Measured against a running app rather than corrected from the issue
text — and the seed had to be rebuilt first, since the one on disk
predated #104 and would have replayed a pre-#104 scan and confirmed the
stale paragraph. On a fresh `make sandbox-seed NAME=default`, both WAVs
carry a title, an artist credit and an album: "Field Recordings" is an
ordinary artist with 2 tracks and "Test Tones" has a cover row. The
only two tracks with no album at all are `unsorted/no-tags-at-all.mp3`
and `unsorted/title-only.mp3`.
The replacement also says that prose written before #104 disagrees,
because it does, and saying nothing is how the next reader reintroduces
the claim from a source this change deliberately does not touch.
Deliberately carries no `Closes` footer. #225 covers two halves, and
the second — the same staleness in two *dated* `.planning/NOTES.md`
entries — is left alone: whether measured history gets a correcting
clause is a judgement about what that file is for, which the issue
raises on purpose and this change must not settle by auto-closing it.
Nothing in this diff is executable, so CI is a regression check on the tree rather than a test of the change; the change itself was verified by measurement against a rebuilt seed, in the PR body above.
Not merging — leaving it for review. Note the PR deliberately carries no Closes footer: #225's second half (the dated .planning/NOTES.md entries) is a judgement left open on purpose, so the issue should stay open unless you decide that half separately.
**CI green** on `dfb338f` (run 18462).
| job | result |
|---|---|
| `check` | success |
| `e2e` | success (chromium + WebKit) |
Nothing in this diff is executable, so CI is a regression check on the tree rather than a test of the change; the change itself was verified by measurement against a rebuilt seed, in the PR body above.
Not merging — leaving it for review. Note the PR deliberately carries no `Closes` footer: #225's second half (the dated `.planning/NOTES.md` entries) is a judgement left open on purpose, so the issue should stay open unless you decide that half separately.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What the issue was
.pi/skills/yellowjacket-dev/references/fixtures.mdstill told an agent that the fixture library's WAVs scan in untitled, that there is no "Field Recordings" artist in the Artists view, and that this is "a known open bug pinned byTestWAVTagsAreNotReadableYet" — a test #104 deleted, because it existed to assert the reader did not work and failed the moment it did.The paragraph ended
do not "fix" a spec by asserting the broken behaviour elsewhere, which is what makes it worse than stale prose: it is an instruction, and it tells the next agent that a spec asserting the working behaviour is the mistake. Same #104 staleness #217 removed fromqueue-selection.spec.ts, one file over, still telling agents to put it back.What changed
One paragraph in one file. It now says the WAVs scan like every other format, names #104 and
backend/riffas the reason, names the two tracks that really do have no album, and warns that prose written before #104 disagrees.That last clause is deliberate.
.planning/NOTES.mdand.planning/plans/completed/005-agent-development-harness.mdstill carry the old claim, and this change does not touch either — so without a line saying "older prose disagrees, it is history", the next reader reintroduces the error from a source that is still sitting there.Verification
The seed had to be rebuilt before anything could be measured, and that is the interesting part.
.dev/seeds/default.taron this worktree was stamped 2026-08-24; #104 merged 2026-08-25. Restoring it would have replayed a database scanned by a pre-#104 binary, reported untitled WAVs, and confirmed the stale paragraph — a clean measurement of the wrong build. The seed rule in this same file is written for schema changes; it applies just as hard to a change in what the scanner reads.So:
make sandbox-seed NAME=default(31 tracks, rebuilt with currentmain), thenmake dev-headless SEED=defaultwithYJ_CORE_INDEX_URLat a dead address, then/__test/sql.title=Tone A/Tone B,track_number1 / 2album_id→ Test Tones, which has a realcover_artrowTestWAVTagsAreNotReadableYetpins itThe only two tracks with no album at all are
unsorted/no-tags-at-all.mp3andunsorted/title-only.mp3— #217's number, independently reproduced.Tiers run
make skill-check—47 documented make targets, all present. Unchanged, as expected: the edit names no target. Also ran as a pre-commit hook on the staged file..pi/skills/for any other stale WAV claim: the only two other mentions are the format list and the case list, both correct.make dev-stopafterwards; port 34115 was free before I started and is released again.Tiers deliberately not run — no Go, no
.sql, no.templ, no bound signature, nofrontend/src:make lint,make test,make generate,make bindings,make ui-testandmake e2edo not apply. Nothing renders, so no screenshot tier.CLAUDE.mdalready describes the post-#104 behaviour correctly and needed no edit.What this deliberately does not do
It does not close #225, and carries no
Closesfooter on purpose.#225 has two halves. The second is the same staleness in two dated
.planning/NOTES.mdentries (the "first N tracks" entry and the sheet-overflow one, both of which use the WAVs as their albumless example). The issue is explicit that whether dated measured history gets a correcting clause or is left exactly as taken is a judgement about what that file is for — and it says so as its reason for existing rather than being fixed in passing.Auto-closing on merge would settle that question by making it disappear, so the footer is omitted and the issue stays open on its second half for a human.
fixtures.mdis not history: it is an instruction, and it was wrong. That is the half that shipped here.Same argument applies to
.planning/plans/completed/005-agent-development-harness.md, which carries the claim too and is history by the same reasoning.Refs #225
CI green on
dfb338f(run 18462).checke2eNothing in this diff is executable, so CI is a regression check on the tree rather than a test of the change; the change itself was verified by measurement against a rebuilt seed, in the PR body above.
Not merging — leaving it for review. Note the PR deliberately carries no
Closesfooter: #225's second half (the dated.planning/NOTES.mdentries) is a judgement left open on purpose, so the issue should stay open unless you decide that half separately.