Repository navigation
Description
Context: I've been using HyperFrames every day for the past two weeks to make Korean Shorts and long-form videos, and it's been great to work with. This is one of a batch of things I ran into along the way (most came as small PRs from me today) — sorry for the pile-up, and thanks for your patience.
Describe the bug
On a long-form film built from many sub-composition scene files, text_below_floor reports the same style problem once for every file. A 500 s documentary with 76 scene files, each with a location label (#V01-l, #V02-l, …) that shares one CSS class rendering at 27 px, got:
hyperframes check --no-cache --json (0.9.43)
craft: 74 findings, all text_below_floor, 74 different sourceFile values, every one at 27 px
19× "인천 앞바다 · 1950.9" 11× "상륙 직전, 인천 앞바다 · 1950.9" 7× "인천 · 1950.9" …
Each message is the full sentence (Type floor is 28 px (2.6% of the 1080 px short side …) and "…" renders at 27 px for 1.67 s: set reading text to at least 28 px, or put data-layout-ignore …). One CSS change fixes all 74. Meanwhile the craft list for this film holds nothing else, and on films that also have real line_unread or dead_stretch findings those end up buried under the repeats. The earlier version of the same film showed the same pattern with a 17 px source credit ("영상 · 미국 국립문서기록관리청(NARA) 111-ADC-8438" at 17 px), repeated per scene.
Where
packages/cli/src/utils/craftAudit.ts: detectTextBelowFloor → groupBySourceFile gives "one finding per file (a scene, with sub-compositions), anchored on its smallest text". This is documented (docs/packages/cli.mdx craft table: "One finding per file lists every such element"), so I'm raising it as an issue rather than changing it.
--max-issues (default 80) only caps how many are printed, and --collapse-static covers layout findings, not craft.
Expected behavior
One finding per style problem: elements that render at the same size and come from the same rule (same class, or the same computed font size and family) across files are reported once. That finding would list the files and elements (elements[] already carries selector, text, size and time), for example:
Type floor is 28 px … and 74 text elements in 74 files stay under it, all at 27 px (e.g. "인천 앞바다 · 1950.9" in compositions/V01.html) …
Possible directions
- Group
SmallTextentries by roundedfontPx(plus the element's class list, or font family) before grouping by file. KeepsourceFileon each entry inelements[], so an agent can still edit each file. - Or keep one finding per file but add a summary finding when the same size repeats in N or more files, so the human output stays short.
Environment
hyperframes 0.9.43 (affa03b6), macOS arm64.
Activity