lint regex gsap_infinite_repeat false-positives on JS comments containing the literal "repeat:-1" (HF 0.4.41)

[sidorovanthon]

Summary

In HF 0.4.41, the gsap_infinite_repeat lint rule fires on the literal substring repeat:-1 inside JavaScript line comments — i.e., text that is not executable code. Even a comment whose intent is to forbid infinite repeats triggers a hard lint error.

Bare repro

npx hyperframes init into a fresh dir, then add this <script> block to index.html:

<script>
  window.__timelines = window.__timelines || {};
  const tl = gsap.timeline({ paused: true });
  // intentional comment for repro:
  // avoid repeat:-1 anywhere in user code
  window.__timelines["main"] = tl;
</script>

Run npx hyperframes lint. Output:

✗ [index.html] gsap_infinite_repeat: GSAP tween uses `repeat: -1` (infinite). Infinite repeats break the deterministic capture engine which seeks to exact frame times. ...
◇  1 error(s), 3 warning(s)

Expected vs actual

• Expected: no error. The substring repeat:-1 is inside a JS line comment; it is not a tween argument and cannot influence the deterministic capture engine.
• Actual: hard error. The regex evidently matches against the raw HTML/JS source without first stripping JS comments.

Suggested fix direction

Either (a) strip JS line and block comments from <script> contents before applying the regex, or (b) scope the regex to actual call-expression / property-assignment syntax (e.g. require it to appear inside an object literal or argument position rather than anywhere in raw text). Option (a) is the simpler fix.

Why it bites

The lint message names the exact pattern (repeat: -1) the rule rejects. Authors who write defensive comments warning against infinite repeats — including AI agents producing pedagogical scaffolds — get hard-failed by the lint rule that is supposed to enforce that very norm.