Adversarial review, Medium: the "Problems" filter over-promised. The badge is
honestly named ("No playout"), but the filter claimed a taxonomy that does not
exist — decisions.md enumerates three fault classes this deliberately does NOT
compute (empty schedule behind a playout, broken source, origin). A user whose
Classic schedule is empty would read "Problems 0" as "lineup healthy" and ship
a dead channel. A false all-clear is worse than no affordance.
Renamed the filter to "No playout" so badge and filter both name exactly the
one fault the API can prove, leaving "Problems" free for when the taxonomy
behind it actually exists. Rationale recorded at the predicate so the next
person doesn't "improve" the label back.
Also from the review:
- The zero-playout test's comment claimed include coverage it does not provide
(it passes with or without the include — 0 == 0). Re-stated as what it is: a
mapper boundary check. Its two siblings are the include coverage.
- UpdateChannelHandler:179 is a fourth call site the "shared by all three"
framing excluded. Harmless (the controller discards the view model and
re-projects through GetChannelByIdForApi), but a trap: its query lacks the
MirrorSourceChannel include, so swapping in the shared helper would report 0
for a working mirror. Documented that the fix there is a QUERY change.
- Mirrored the rename into the design-system prototype.
The rename collided the badge and filter labels, so the screen tests now scope
the badge assertion to the table (spa-conventions §6). This also fixed a real
weakness: the mirror test's unscoped queryByText would have matched the filter
button and asserted nothing.
Review note: the reviewer's strongest hypothesis — that PUT and GET could
disagree on a mirror channel's count — was investigated and does NOT hold.
Refs #72
The channels API could not answer "will this channel play?", which #72 needs
to flag a broken channel in the lineup at a glance.
Two defects, one root cause each:
1. `ChannelRepository.GetChannel` never included `Playouts`. The read is
AsNoTracking with no lazy-loading proxies, so the navigation came back
empty and `GetChannelByIdForApiHandler`'s `channel.Playouts?.Count ?? 0`
could only ever evaluate to 0 — `GET /api/v1/channels/{id}` reported
`playoutCount: 0` for every channel on the system. That silently disabled
the channel editor's playout-source guard (ChannelEditScreen:820, gated on
`playoutCount > 0`), so the "Cannot be changed once a generated channel has
a playout" control was always live. The server still enforces the invariant
(UpdateChannelHandler coerces Mirror back to Generated), so nothing was
corrupted — but the user's change was silently discarded. That silent
coercion is filed separately as #401.
2. The detail path counted only the channel's own playouts, never the mirror
source's, so a working Mirror channel would read as "no playout" even once
the include landed.
Both call sites now share `Mapper.GetPlayoutsCount` (previously private to
GetAllChannelsHandler), which handles the Mirror case. `ChannelResponseModel`
gains `PlayoutCount` so the list — #72's actual surface — can render it; the
count is free there, since `GetAll` already includes `Playouts` and
`MirrorSourceChannel.Playouts` and simply discarded them.
Tests run the real repository against a real context on purpose: a handler
test with a substituted IChannelRepository populates `Playouts` itself, so it
passes whether or not the query includes them. Proven non-vacuous — removing
the include again turns the 2-playout and mirror cases red (0 CS errors, so
no stale-dll false pass).
Refs #72
timothy