Finish the same editable project through your agent, the browser editor, or the command line. The route can change; the quality gate does not.

​
1. Approve the project, not one good frame

Watch the complete preview from the beginning. Check the message and sequence before spending time on small visual details.
  • Does the opening make the subject clear soon enough?
  • Does every scene add something?
  • Can text, captions, and product screens be read at delivery size?
  • Do narration, visuals, music, and sound effects arrive together?
  • Does the ending finish cleanly and make the next action clear?

​
2. Run the project checks

Run the checks in the browser editor, ask your agent to run them, or use:
lint catches composition-structure mistakes. check runs lint plus browser, runtime, layout, motion, and WCAG contrast verification. Checks cannot judge the story for you. Fix technical failures, then watch the project again if a fix changed what the viewer sees.

​
3. Render from where you are working

All three paths render the same source.

​
Ask the agent

Use the agent when a failed check may require a source change or when you want one person to manage the complete finish. The /hyperframes skill waits for render approval after the final preview.

​
Use the browser editor

Open Export, choose the destination’s format and size, and start the render. The Renders panel shows progress and keeps completed files available to download.

The browser editor checking and rendering the same project shown in its editor.

​
Use the CLI

Use the CLI for a direct local render, a script, CI, or a repeatable batch. The installed version remains authoritative: run npx hyperframes render --help for every available option.

​
4. Choose what the destination needs

MP4 at the project’s authored size is the normal delivery choice. Ask for another format or resolution only when the next tool or platform requires it. Higher output resolution does not add detail to low-resolution media. A higher frame rate creates more frames; it does not improve motion authored for a lower cadence. Use export in the browser editor for its visible controls or the rendering reference for formats, Docker, batch output, and advanced CLI behavior.

​
5. Watch the rendered file

Open the output itself instead of relying on the preview.
  • Watch the first and final seconds.
  • Check captions, cuts, and the most complex transition.
  • Listen for clipped narration, late sound effects, or an abrupt music ending.
  • Confirm duration, dimensions, format, and audio.
  • Use a filename that identifies the project and version.
The preview proves the project can play. The exported file proves the delivery is correct.

​
6. Share the right form

Publish the project when a browser link is more useful than a file:
The command uploads the project and returns a stable URL. An anonymous first publish creates a claimable link. Sign in when the CLI should own the project immediately, update an existing link, or publish into a shared space. A local video poster referenced with a relative path, such as ../shared/poster.png, is copied into the published project even when it lives outside the project directory. Percent-encoded paths work too, such as ../shared/poster%20art.svg for poster art.svg or ../shared/%E5%B0%81%E9%9D%A2.svg for 封面.svg. Local images outside the project referenced by an <img> or <source> element’s srcset are included too. Their size or pixel-density descriptors are preserved, and your source files stay unchanged. Before sharing source, remove secrets and confirm that every included media file can be shared. Tell a reviewer whether you need feedback on story, visuals, timing, facts, or final approval.

​
If the finish fails

Keep the first exact error and run:
Use Troubleshooting for project and render failures, or Browser editor troubleshooting when the problem is in the editor or its render queue.

​
Share from the local Studio preview

Open a project with hyperframes preview, then choose Share beside Export. Choose Sign in if prompted. You can also run hyperframes auth login in your terminal, then return to Studio. Sharing reconnects automatically after browser sign-in or when you return to the panel. Credentials stay in the local CLI process. If you switch accounts in the terminal, reload Studio or sign in from the panel before retrying. Choose the workspace and who can access the project, then choose Create share link. Studio finishes saving pending edits before it renders and uploads the project. The five free shared-project allowance is the same allowance used by Desktop and the CLI. The workspace meter comes from the server; retries of an existing registration do not need an extra slot. Project files are included when available for the workspace. The panel reports whether the last Studio upload included files or was video only. If attaching files fails, retry the upload or explicitly choose Retry with video only. When the video is ready, choose Copy link. Local edits do not automatically replace the shared video: Update shared version uploads the saved project to the same review page. Changes to access use a separate Save access action. Turn link off keeps the project and comments; updating the video keeps an off link off. Turning the link off does not free a shared-project slot. You can close the Share panel while sharing continues, but keep the local Studio server running. Reopen the panel to recover progress, or use Refresh after a connection problem. Manage sharing opens the web page for invites and owner settings. Existing published project URLs continue to open separately. The local sharing bridge is available only from the same-origin loopback Studio page. It does not expose CLI credentials or accept a different project path. As with local preview, open projects whose scripts you trust.