Skip to content

check: text_below_floor repeats one style's finding once per scene file (74 warnings for one 27 px label class) #7710

Open

Description

@wonjangcloud9

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 SmallText entries by rounded fontPx (plus the element's class list, or font family) before grouping by file. Keep sourceFile on each entry in elements[], 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

  1. added
    enhancementNew feature or request
    triage/needs-designEvidence is adequate; desired behavior or scope needs a maintainer decision.
    on Nov 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesttriage/needs-designEvidence is adequate; desired behavior or scope needs a maintainer decision.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions