docs(skill): the WAV fixtures scan tagged, and have since #104 #230

2026-08-30T07:37:25Z

logan commented

2026-08-30 07:37:25 +00:00

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

## 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

logan added 1 commit 2026-08-30 07:37:25 +00:00

docs(skill): the WAV fixtures scan tagged, and have since #104

CI / check (push) Skipped

CI / e2e (push) Skipped

CI / check (pull_request) Successful in 2m45s

Details

CI / e2e (pull_request) Successful in 10m12s

Details

dfb338fc37

`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.

logan commented

2026-08-30 07:50:51 +00:00

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.

**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.

logan referenced this pull request

2026-08-30 07:51:06 +00:00

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

All checks were successful

CI / check (push) Skipped

Required

CI / e2e (push) Skipped

Required

CI / check (pull_request) Successful in 2m45s

Required

Details

CI / e2e (pull_request) Successful in 10m12s

Required

Details

You are not authorized to merge this pull request.

This pull request can be merged automatically.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin docs/225-fixtures-wav-tags:docs/225-fixtures-wav-tags

git checkout docs/225-fixtures-wav-tags

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#230