check (StaticGuard): false "uses data-end without data-duration" on <audio> that already has data-duration and no data-end

[carlosmirandalevy]

Environment

• Hyperframes CLI: 0.7.64 (invoked via npx hyperframes check)
• Node: 22.x
• OS: reproduced on Linux (WSL2) and confirmed by a second project on the same CLI version

Summary

npx hyperframes check emits a StaticGuard finding for <audio> elements:

<audio id="nar-01"> uses data-end without data-duration. Use data-duration in source HTML.

…but the flagged <audio> element has data-duration (and/or data-start) and contains no data-end attribute at all. The whole composition has zero occurrences of data-end. The finding is a false positive, and its remediation text ("Use data-duration") names the attribute that is already present.

Because data-end was renamed to data-duration in the current attribute contract, the rule referencing data-end at all looks like a stale code path in StaticGuard.

Steps to reproduce

1. npx hyperframes init repro && cd repro
2. Add a per-scene audio element to the composition, using the current framework-owned playback contract — data-start, data-duration, no data-end:

   <audio id="nar-01" src="assets/narration.wav" data-start="0.5" data-duration="4" preload="auto"></audio>

3. npx hyperframes check

Expected

No finding for <audio id="nar-01">. The element complies with the current attribute contract (data-start + data-duration, no deprecated data-end).

Actual

StaticGuard reports, for every such <audio>:

<audio id="nar-01"> uses data-end without data-duration. Use data-duration in source HTML.

Impact

• False findings on clean compositions — the "require 0 findings" gate can't be met by compositions that are actually correct, which forces teams to either whitelist the rule or ignore check output (both bad).
• Misleading remediation — the message tells the author to add data-duration, which is already there; there is no data-end to remove.
• Noise scales with the number of <audio> elements (one false finding per scene in a per-scene-audio composition).

Hypothesis (for triage — not verified against source)

The message template appears inverted or stale: it fires when an <audio> has data-duration without data-end, but reports it as "uses data-end without data-duration." Given data-end is the deprecated name for data-duration, the guard may still be pattern-matching the old attribute name. Either the condition or the message string (or both) needs to track the current data-start/data-duration contract for media elements.

Suggested fix

StaticGuard should treat <audio data-start data-duration> (no data-end) as valid and emit no finding. If a data-end→data-duration deprecation warning is still desired, it should fire only when data-end is actually present in the source.

[jrusso1020]

Thanks for the detailed repro. This was already fixed on 2026-07-20 by ac9f46310 (fix(lint): recognize compiler-derived data-end as legitimate) and shipped in v0.7.65 (current release is v0.7.67).

Reproduced locally to confirm:

• npx hyperframes@0.7.64 check on your exact <audio id="nar-01" src="…" data-start="0.5" data-duration="4"> — fires the false positive: [StaticGuard] <audio id="nar-01"> uses data-end without data-duration.
• npx hyperframes@0.7.67 check on the same input — clean (0 lint errors related to data-end).

Root cause matched your hypothesis exactly: bundleToSingleHtml compiles data-duration into data-end (in compileTimingAttrs), then validates the compiled HTML. The linter's deprecated_data_end rule fired on the compiler's own consistent output. Fix: diagnoseDerivedEnd now stays silent when the paired data-end matches data-start + data-duration (within 1ns epsilon for float residuals).

Please upgrade — npx hyperframes@latest --version should show 0.7.67 and the finding will be gone. Closing this out; reopen if it recurs on ≥0.7.65.

— Rames Jusso

[phucsd1]

Additional cross-check from a real render pipeline, reduced to the canonical <video> shape:

<video
  id="video-clip"
  class="clip"
  src="fixture.mp4"
  muted
  playsinline
  data-start="67.07"
  data-duration="6.8"
  data-media-start="0"
  data-track-index="5">
</video>

A/B result at the same explicit seek time (68.409s):

• npx hyperframes@0.7.64 check . --snapshots --at 68.409 --json
  • emits [StaticGuard] Invalid HyperFrame contract: <video id="video-clip"> uses data-end without data-duration
  • the generated snapshot is fully black, even though the source has data-duration and no authored data-end
• The same command and composition on 0.7.65, 0.7.66, 0.7.67, and 0.7.68
  • emits no StaticGuard warning
  • seeks and displays the MP4 correctly in the snapshot

So the fix in ac9f46310 covers <video> as well as the reported <audio> case. The additional observable impact on 0.7.64 is that this can make check --snapshots look like a media/render failure, not just lint noise.

This is confirmed fixed on >=0.7.65; I am not requesting that the issue be reopened. A small video snapshot/seek regression test may still be useful if that end-to-end behavior is not already covered.

[phucsd1]

I opened draft PR #2747 with the minimal <video> regression coverage described above. It is test-only and includes the v0.7.64 RED / current-main GREEN evidence.