Repository navigation
feat(cli): check --no-craft skips the craft pass for a render preflight - #7400
miguel-heygen wants to merge 1 commit into
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
jerrai-bot-heygen
left a comment
jerrai-bot-heygen
left a comment
There was a problem hiding this comment.
Approved exact e6582828 for check --no-craft. The CLI parser defaults craft to true and passes false only for the negated flag; direct pipeline callers with no craft keep the old options.craft !== false behavior. craftEnabled is the common gate for craft-frame collection and analysis; --range remains an independent disable, and the disabled report retains craft.enabled:false / human “Craft ◇ skipped” rather than claiming a full craft pass. Tests check both CLI option values and a real pipeline driver receiving zero craft-frame calls. The CLI reference documents the new switch. I did not run a local suite; hosted checks had no red result at stamp time and remaining jobs were pending.
Non-blocking: the agent-facing CLI skill still lists --no-contrast without --no-craft; add it as a docs follow-up. If combined with #7398's cache PR, craft is included in its options key, so a skipped-craft result is not replayed as a full check; the PRs may need a trivial CheckOptions merge resolution. No merge/enqueue by me. — Jerrai
![heygengenesis[bot]](https://avatars.githubusercontent.com/in/2913576?s=60&v=4){kind=small}
There was a problem hiding this comment.
Approve at e6582828. I found no blockers.
- Wiring:
craftEnabledis the only gate for craft. It covers both the overlap-pass sampling (collectMotionOverlapSamples) andauditCraft, so--no-craftdrops both, and the result falls back todisabledCraft(). The human report already printsCraft ◇ skippedwhen!section.enabled, and--jsonreportscraft.enabled: false. Whencraftis left undefined (forDEFAULT_CHECK_OPTIONSor any programmatic caller), the pass stays on, so the default behavior doesn't change. - Tests, run locally: I removed
options.craft !== false &&fromcraftEnabled. The pipeline test "--no-craft never samples the craft frames…" then fails, and it passes with the change restored, which matches the claim in the body. The whole ofcheck.test.tspasses (168/168). - CI on this head: all workflows passed.
- This is a feature PR, so the "fails without the fix" rule doesn't apply.
Non-blocking, for #7398 (unchanged-project cache): whichever PR lands second should make craft part of the cache key. Otherwise a cached --no-craft pass could be returned for a full check, or the other way round.
|
Folded into #7398 (the 100-line floor refused it alone). |
What
hyperframes check --no-craftskips the craft pass (dead stretches, unread lines, silent films). The report shows Craft as skipped, and the pass is on by default.Why
On a 78 s film the craft pass is about half of a full check (599 of its 600 samples). A render preflight that only needs layout, motion and contrast has no way to leave it out, so each preflight pays for it.
Related work
Refs the request to make the craft pass switchable. The unchanged-project cache is a separate PR.
How
craft, read bycraftEnabled, the single place that decides whether craft frames are sampled in both the overlap pass and the analysis.--rangealready turned it off through the same line.--no-craft; the human report printsCraft ◇ skippedand--jsonreportscraft.enabled: false.git grep -n -i "craft" packages/cli/src/commands/check.ts): none, only the hard-coded sample cap and time budget incheckPipeline.ts.Test plan
craft: falseno craft frame is sampled and the report says the pass is off;--no-craftreaches the pipeline ascraft: falseand the pass is on without it. The first fails when theoptions.craftcheck is removed.--no-craft: 4310, 4117, 4315, 4280, 4498 ms--no-craftin the CLI reference)Size
40 changed lines. It is a separate switch from the unchanged-project cache (#7398), so each can be reviewed and reverted alone.