Merge remote-tracking branch 'origin/main' into docs/225-fixtures-wav-tags

default

.pi/skills/yellowjacket-dev/references/fixtures.md

@@ -42,11 +42,16 @@ strings and identical specs produce different bytes on different builds.
   playback and then clicks pause races the track ending and fails
   against a correct UI. Use `LONG_TRACK` (90 s, `edge-lengths`) exported
   from `e2e/support/fixtures.ts`.
-- **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.
+- **WAV tracks scan like every other format.** #104 added
+  `backend/riff`, so the scan reads the `id3 ` chunk `backend/tagwriter`
+  writes and both WAVs come in fully tagged: "Field Recordings" is an
+  ordinary artist in the Artists view, with a "Test Tones" album and a
+  cover. They are therefore not an example of an untitled or albumless
+  track — the only two tracks with no album are
+  `unsorted/no-tags-at-all.mp3` and `unsorted/title-only.mp3`. Prose
+  written before #104 says the opposite and names
+  `TestWAVTagsAreNotReadableYet`, a test that change deleted; that is
+  dated history rather than a description of the app.
 
 ## Seeds
 

.pi/skills/yj-loop/SKILL.md

@@ -163,7 +163,22 @@ Merge when, and only when, **all** hold:
 - the protection contexts `CI / check` and `CI / e2e` are green on the
   PR's head, read from the API, not from the PR page's badge;
 - the PR reports mergeable;
-- the critique leg ran and no open blocker stands.
+- the critique leg ran and no open blocker stands;
+- the branch is **not behind `origin/main`** — the protection's
+  `block_on_outdated_branch: true` refuses it anyway; never
+  `force_manually_merged` around it.
+
+**Refresh before every merge.** In the loop worktree: fetch, then
+`git merge origin/main` on the PR branch, push. A textual conflict
+stops the leg there — as diff text, not as a failed merge click: hunks
+the loop authored are resolved by the loop; anything else is left with
+`⟦loop⟧` comment for a human, never forced. After any refresh push,
+re-poll the PR's own required contexts on the **new head** before
+merging.
+
+**Merges happen one at a time**, each re-reading state — the previous
+merge moved `main`, and the next PR's mergeability is recomputed at
+its own turn.
 
 ```
 curl -sS -X POST -H "Authorization: token $GITEA_TOKEN" \
@@ -172,12 +187,20 @@ curl -sS -X POST -H "Authorization: token $GITEA_TOKEN" \
   -d '{"Do":"merge","merge_message_field":"default","force_manually_merged":false}'
 ```
 
-Afterwards: `scripts/issue.sh list --state open` and check the footer
-took. Close stragglers with `issue.sh close`, naming the merge commit.
-`unclaim.yml` handles the label; it is not instant; reopening does not
-restore it. Merging fans out to nothing (releases are the manual
-`release.yml`, which the loop never runs) — the criticism stands before
-the merge because nothing stands after it.
+**Afterwards watch the `push` run on `main`** — the CI the merge
+started. A red main after a loop merge is a **halt**: comment what is
+known on the offending PR, mark the state file, stop taking new issues.
+That run is the only thing between a clean textual merge of
+independently-written PRs and a self-contradicting main; no
+mergeability check sees it. Only a green main lets the tick proceed (to
+footer verification, below).
+
+Footer verification: `scripts/issue.sh list --state open` and check
+the footer took. Close stragglers with `issue.sh close`, naming the
+merge commit. `unclaim.yml` handles the label; it is not instant;
+reopening does not restore it. Merging fans out to nothing (releases
+are the manual `release.yml`, which the loop never runs) — the
+criticism stands before the merge because nothing stands after it.
 
 ## Rails — the loop's absolute rules
 

.planning/plans/active/020-autonomous-backlog-loop.md

@@ -140,6 +140,20 @@ from a concurrent session is caught before the first edit.
 
 - **Only PRs the loop opened.** A collaborator's PR is never merged, never
   commented on for pressure, never touched.
+- **Every branch is refreshed against main before its merge**, in the
+  loop worktree — the refresh is where a textual conflict surfaces, as
+  diff text: hunks the loop authored are resolved there, anything else
+  is left to a human with a `⟦loop⟧` comment. The protection's
+  `block_on_outdated_branch` makes the refresh mandatory for adopted
+  (pre-loop) branches: behind `main`, a PR cannot merge at all.
+  Required contexts are re-polled on the refreshed head.
+- **Merges are one at a time**, each re-reading state — the previous
+  merge moved `main`, and the next PR's mergeability is recomputed at
+  its own turn.
+- **Post-merge, the `push` run on `main` is watched.** A red main after
+  a loop merge halts the loop. That run is the only guard against the
+  class no mergeability check sees: two PRs touching the same file,
+  merging cleanly, contradicting each other.
 - The gate is the protection rule itself, read from the API: contexts
   `CI / check*` and `CI / e2e*` green, PR mergeable. (Required approvals
   is 0 today; if a second person changes protection rules, the merge