mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-03 12:54:29 +00:00
Code review caught a false positive in the rule added an hour ago, at severity
error, on the studio's own output. `lintHyperframeHtml` sees ONE file, but
`timelineAudioGroupCreate` deliberately writes the bus into the active
composition and patches `data-audio-group` into each member's own file
("Written to the active composition file rather than beside the members"). So a
bus in index.html with members in compositions/voices.html was reported as
"an audio group no clip belongs to" plus the flatly wrong "No clip carries
`data-audio-group` at all" — about clips in a file the rule cannot see.
Reproduced end to end, then fixed.
The rule now returns early when the file declares no membership at all: absence
of THIS bus's id is only evidence when some other id is present. That keeps the
case it was written for — a typo on a member sitting beside its bus, which is
both the single-file hand-authored shape and what the studio writes when
everything lives in one composition — and the message says "Clips in this file"
so its scope is on the label.
Verified after: the sub-comp shape is silent, the typo shape still errors, and
audio-playground's genuinely orphaned `#narration` bus still reports. lint: 14
files, 536 tests.
The other two claims against these rules I checked and did not act on:
- matching only `audio[data-audio-group]` agrees with core, whose
`resolveAudioGroups` queries exactly that and documents "a `data-audio-group`
on a `<video>` is ignored". A video carrying it has no effective membership,
so the bus really is empty. That the studio timeline nests such a child anyway
is a studio/core disagreement, not this rule's error.
- `audio_carve_ungrouped_sources` treating an element-less group as a clip id is
real but pre-existing on this branch, not from these rules.