heygen-com/hyperframes

Describe the bug hyperframes docs examples prints packages/cli/src/docs/examples.md, which lists three templates for init --example: blank, title-card and video-edit. title-card and video-edit don't exist. init resolves examples from registry/examples/, which has decision-tree, kinetic-type, nyt-graph, play-mode, product-promo, swiss-grid, vignelli and warm-grain, plus the built-in blank. Steps to reproduce npx hyperframes docs examples npx hyperframes init demo --example title-card --non-interactive Expected behavior The topic lists the examples init --example actually accepts. Actual behavior It lists two that don't exist and none of the eight that do. Suggested fix Update packages/cli/src/docs/examples.md to list blank and the examples in registry/examples/, with a one-line description each (the descriptions are in each example's registry-item.json). Better still, add a test that fails when the topic and registry/examples/ disagree, so this can't drift again.

Problem Almost every lint finding carries a fixHint telling the user what to change. Three don't: invalid_composition_variables_declaration, both branches in packages/lint/src/rules/composition.ts (around lines 462 and 477): an entry that isn't an object, and an entry missing id, type, label or default. css_parse_error in packages/lint/src/rules/core.ts (around line 726). Without a hint, lint and check show only the message, while every other finding also tells you how to fix it. Proposed solution Add a fixHint to each of these findings, written like the hints on neighbouring rules: short and concrete. For example, show the shape of a valid variables entry ({ "id": "title", "type": "string", "label": "Title", "default": "Hello" }), and for a CSS parse error, point at the reported line and the usual causes (an unclosed brace or quote). Acceptance criteria All three findings include a fixHint. The existing tests that cover these codes assert the hint is present. bun run --cwd packages

Problem These lint rules have no test that mentions their code, so a change that breaks them would go unnoticed: Code Severity Defined at slideshow_unresolved_ref error packages/lint/src/rules/slideshow.ts:75 subcomposition_root_styled_by_class error packages/lint/src/rules/composition.ts:1274 Tests go in packages/lint/src/rules/slideshow.test.ts and packages/lint/src/rules/composition.test.ts. Proposed solution Add tests to the matching *.test.ts file next to each rule, following the style of the other tests in that file. For each rule, add at least: one composition that triggers the finding, asserting the code and severity, and one similar composition that should not trigger it. Read the rule's code first: the condition it checks tells you what the minimal triggering composition looks like. Acceptance criteria Each code above is asserted by at least one positive and one negative test. bun run --cwd packages/lint test passes. No rule behaviour changes. If writing a test

Problem These lint rules have no test that mentions their code, so a change that breaks them would go unnoticed: Code Severity Defined at audio_reactive_single_tween_per_group warning packages/lint/src/rules/gsap.ts:1526 gsap_group_selector_keyframes warning packages/lint/src/rules/gsap.ts:2241 Tests go in packages/lint/src/rules/gsap.test.ts. Proposed solution Add tests to the matching *.test.ts file next to each rule, following the style of the other tests in that file. For each rule, add at least: one composition that triggers the finding, asserting the code and severity, and one similar composition that should not trigger it. Read the rule's code first: the condition it checks tells you what the minimal triggering composition looks like. Acceptance criteria Each code above is asserted by at least one positive and one negative test. bun run --cwd packages/lint test passes. No rule behaviour changes. If writing a test shows a rule misbehaving, note it in the PR or open

Problem These lint rules have no test that mentions their code, so a change that breaks them would go unnoticed: Code Severity Defined at duplicate_media_discovery_risk warning packages/lint/src/rules/media.ts:466 self_closing_media_tag error packages/lint/src/rules/media.ts:636 placeholder_media_url error packages/lint/src/rules/media.ts:662 Tests go in packages/lint/src/rules/media.test.ts. Proposed solution Add tests to the matching *.test.ts file next to each rule, following the style of the other tests in that file. For each rule, add at least: one composition that triggers the finding, asserting the code and severity, and one similar composition that should not trigger it. Read the rule's code first: the condition it checks tells you what the minimal triggering composition looks like. Acceptance criteria Each code above is asserted by at least one positive and one negative test. bun run --cwd packages/lint test passes. No rule behaviour changes. If writing a test