chore(comments): drop epic, sprint and review-round ids from the code

The code cited its plan instead of saying why: `E28 review J4`, `(R6 S3b)`, `S1 justified…`,
`deep-review round 5`. That plan lives in the private ops repo, so for every reader of this one the
citation was noise, and a sentence whose subject was the plan step ("round 2 showed…") hid its
lesson behind an id. Each one is gone and the "why" kept: a bare citation is deleted, a sentence
carrying a lesson is reworded around it ("a later attempt showed…").

Measured (`scripts/audit_metrics.py`, product code): 652 lines in 270 files carried an epic code by
the definition the next commit holds (507 / 241 by the old, two-digit-only one) -> 0. Across all
code, tests, scripts and configs: ~1100 epic-code lines plus ~320 sprint/round ids.

Behaviour unchanged, checked mechanically: every changed .py file has the same AST once docstrings
are blanked; css/sh/toml/yml/json files are identical once comments are stripped; the only
non-comment changes in TS/JS are test titles, one description string in a contract table, and five
ESLint messages, whose text is all the gates snapshot diff holds. Not touched: Markdown (docs and
the changelog keep their history), Alembic migrations, TV episode notation (`S2 · E5`), DESIGN.md
ids (`C1`, `B4`, `S3h`), tracker ids (`SEC-16`, `DX-17`).

One stale claim fixed on the way: test_hls_reaper's docstring said the player checkpoints "every
10 s whether or not it is playing", which plex/stream.py calls wrong; it now says what the code does.
This commit is contained in:
2026-10-05 00:19:39 +02:00
parent c73d8be094
commit 4aaaaa7860
669 changed files with 1831 additions and 1904 deletions
+14 -14
View File
@@ -68,11 +68,11 @@ import { HiddenFilterCue } from "./ui/HiddenFilterCue";
import { PageHeading } from "./ui/Headings";
import { useCopyItems } from "./copyItems";
// The playlist detail is a HYBRID table (E4 S4): real sortable/filterable column headers over a
// The playlist detail is a HYBRID table: real sortable/filterable column headers over a
// body that is still a drag-reorderable @dnd-kit list.
//
// The distinction that shapes the whole module: **the column sort and the filters are a VIEW**,
// while the playlist's own order is stored data. Before S4 the sort control wrote straight through
// while the playlist's own order is stored data. At first the sort control wrote straight through
// to the server, so picking "sort by title" silently rewrote the playlist and marked a
// YouTube-linked mirror dirty. Now nothing is written until the user presses "Save this order",
// which still goes through the undoable path — the capability is intact, it just stopped being a
@@ -186,7 +186,7 @@ export default function Playlists() {
// `restoreFromCache` rolls back to, and until this refetch landed it still held the order
// from before this reorder — so a SECOND reorder failing in that window rolled the rows
// back to an order the server does not have, permanently (the membership guard cannot
// correct an order). One accepted write, one cache entry that matches it (round 5).
// correct an order). One accepted write, one cache entry that matches it.
qc.setQueryData<PlaylistDetail>(qk.playlist(listId), (old) =>
old ? { ...old, items: next } : old,
);
@@ -220,8 +220,8 @@ export default function Playlists() {
// Put the rows back to what the CACHED detail says — the server's list as last fetched. A failed
// reorder or move must not wait for the resync to do it: the server's list is unchanged, so the
// refetch comes back deep-equal, react-query keeps the same `data` object, and the effect below
// (keyed on it) never runs. The moved row stayed gone and the rejected order stayed on screen
// (deep-review round 4). Only for the list on screen: the selection may have moved meanwhile.
// (keyed on it) never runs. The moved row stayed gone and the rejected order stayed on screen.
// Only for the list on screen: the selection may have moved meanwhile.
function restoreFromCache(listId: number) {
if (listId !== selectedRef.current) return;
const cur = qc.getQueryData<PlaylistDetail>(qk.playlist(listId));
@@ -257,7 +257,7 @@ export default function Playlists() {
// ONE context menu for the whole table, not one popover per <tr> (see ui/ContextMenu): the row it
// belongs to is `rowMenu.target`, and the panel anchors to the pointer.
const rowMenu = useContextMenu<Video>();
// The comfort-shelf pin composes into the row's existing menu (E24 S3) rather than mounting a
// The comfort-shelf pin composes into the row's existing menu rather than mounting a
// second one on the same <tr>.
const comfortPin = useComfortPin(rowMenu.open);
const copy = useCopyItems();
@@ -370,7 +370,7 @@ export default function Playlists() {
[items],
);
// The row's "…" opens the row menu under itself (E28 C1). Which row's menu is open is part of the
// The row's "…" opens the row menu under itself. Which row's menu is open is part of the
// cell (aria-expanded), so the columns rebuild when it changes — a cheap array of closures.
const { buttonProps: rowMenuButton, open: rowMenuOpen, target: rowMenuTarget } = rowMenu;
const columns = useMemo(
@@ -451,8 +451,8 @@ export default function Playlists() {
order.set(arrayMove(items, oldIndex, newIndex)); // onApply persists
}
/** Takes a row out at once and says so in a toast whose Undo puts it back where it was (E28 C1:
* the X column became the Delete key + this toast; no confirm, because nothing is lost).
/** Takes a row out at once and says so in a toast whose Undo puts it back where it was (the
* X column became the Delete key + this toast; no confirm, because nothing is lost).
* @returns whether the item was actually removed — the player needs to know, because it must
* step to the next item (or close) only when the removal really happened. */
async function removeItem(video: Video, listIdArg?: number | null): Promise<boolean> {
@@ -558,9 +558,9 @@ export default function Playlists() {
// NOT a silent revert. `req` deliberately leaves 401/403/404 to the caller as control flow, and
// every move failure a user can actually reach is a 404 (the 400 `same_playlist` case is already
// impossible — the submenu never offers the current list). So the row used to snap back with no
// explanation and the shipped moveErrors strings were unreachable (E10 review round 1).
// explanation and the shipped moveErrors strings were unreachable.
// A fault `req` already put in its error dialog is not toasted again — `notifyActionError`
// checks (E10 review round 2 found it reported twice).
// checks (a review found it reported twice).
notifyActionError(e, t("playlists.moveFailed"));
restoreFromCache(selectedId); // the row is still in this list
}
@@ -600,7 +600,7 @@ export default function Playlists() {
qc.invalidateQueries({ queryKey: qk.playlist() });
qc.invalidateQueries({ queryKey: qk.feed() });
})
// No catch used to mean an unhandled rejection and nothing said (E11 S2b).
// No catch used to mean an unhandled rejection and nothing said.
.catch((e: unknown) => notifyActionError(e, t("errors.writeFailed.videoState")));
}
@@ -896,7 +896,7 @@ export default function Playlists() {
{t("playlists.playAll")}
</Button>
{/* Rename, the pin, YouTube (open / push / revert) and Delete: the list's ONE
menu (E28 C1), the same the rail row opens — the header keeps Play all. */}
menu, the same the rail row opens — the header keeps Play all. */}
<MoreButton
ref={renameTarget}
variant="outline"
@@ -1016,7 +1016,7 @@ export default function Playlists() {
dnd-kit has handled). */}
<NavGrid
as="tbody"
// Delete on a walked row = the menu's Remove (E28 C1), with the same undo toast.
// Delete on a walked row = the menu's Remove, with the same undo toast.
onDelete={
canEdit
? (i) => {