Automate HyperFrames with OpenClaw: Pin the Render Before the Agent Runs It

HyperFrames render-admission memo · v0.7.68 release delta · 47-case local rerun · no render executed

Automate HyperFrames with OpenClaw as a build pipeline, not as a chat session that happens to end in an MP4. HyperFrames turns HTML, CSS, media, and seekable animation into video by capturing deterministic frames in Chrome and encoding them with FFmpeg. That is a useful agent surface because the inputs are inspectable. It is also a wide execution surface: a composition can load remote assets, scripts can change between preview and render, tool versions can move, and a retry can produce a second expensive job after the first response disappears.

The narrow question is not whether an agent can type hyperframes render. It can. The question is which exact render it is allowed to start, how that decision survives a restart, and what evidence proves the output came from the reviewed inputs.

The release pin moved overnight

The HyperFrames README presents a friendly loop: initialize a project, preview it, then render. That is appropriate at a workstation. An unattended agent needs one extra layer because npx, skill installation, and a mutable branch can resolve different code on different days.

The first production review pinned v0.7.67. Before this rerun, v0.7.68 shipped with two bug fixes and one feature reversion that touch rendered behavior. The fixture therefore admits 0.7.68 and rejects 0.7.67. Nothing is wrong with the older release; it simply is not the executable described by the new evidence packet.

The tagged package metadata still requires Node.js 22 or newer. The CLI also depends on Chrome and FFmpeg, and its doctor command checks the environment. Record those facts before planning the render. In a controlled runner, the useful pin is stronger than a semver string: use a lockfile or container digest, retain hyperframes info, and bind the resolved executable to the job record.

Version drift is the first refusal, not a warning to acknowledge after encoding begins.

Failure modes in the forty-seven-case gate

The fixture used one approved packet for a 24-second, 1920×1080 MP4 at 30 fps. It assumed HyperFrames 0.7.68, Node 22, Chrome, FFmpeg, Docker, a fixed project root, one composition digest, one local audio digest, strict linting, a passing full check, five retained snapshots, and a final output below the project’s renders/ directory.

Each case changed one boundary and asked a deterministic decision function for an outcome. The point was not to imitate the renderer. It was to test the admission logic that sits in front of the renderer.

All 47 cases matched. Three packets were render-ready: one final render, one draft preview, and one deliberately non-strict final render whose warning policy was part of the approved bytes. One packet waited for review, one returned a cached receipt, and 42 were blocked or held. The count is evidence about this local contract, not a benchmark of HyperFrames itself.

The v0.7.68 delta belongs in the packet

The first fix changes how the producer evaluates a short looping video inside a longer slot. A three-second source looped across ten seconds should be credited for delivering all of its source frames once; the previous coverage calculation could abort it at 30 percent. That is a renderer fix, but it also changes what a preflight failure means. Keep the release tag beside the retained check output so an operator can tell whether an old coverage refusal is reproducible or already obsolete.

The second fix preserves nested selectors when composition CSS uses native CSS Nesting. A preview reviewed under one scoping implementation is not interchangeable with a render under another. The release also reverts RenderStretch. For this packet, that makes feature presence part of source identity: the agent may not infer that a capability mentioned in v0.7.67 remains available after the pin changes.

None of those deltas requires a larger prompt. They require a smaller claim: the packet names the release, the review names the packet digest, and a changed release forces new evidence.

A render packet should be boring to read

The canonical packet needs no cinematic prose. It should name a project root, a composition, every local media artifact, the intended output, the exact settings that affect frames, the evidence gates, and the review and replay records. A human-facing summary can be pleasant; the machine object should be stable.

{
  "contractVersion": "hyperframes-render-v1",
  "cli": { "version": "0.7.68", "releaseTag": "v0.7.68" },
  "project": {
    "root": "/srv/render/project",
    "composition": "index.html",
    "compositionDigest": "sha256:…",
    "localOnly": true
  },
  "media": [{ "path": "media/voice.wav", "digest": "sha256:…" }],
  "render": {
    "format": "mp4", "output": "renders/final.mp4",
    "fps": 30, "width": 1920, "height": 1080,
    "durationSeconds": 24, "workers": 2, "strict": true
  },
  "idempotencyKey": "project:composition:revision"
}

Do not hand this packet to a generic shell tool. Wrap the CLI behind a typed adapter such as hyperframes.render.approved. The adapter validates paths, versions, ranges, allowed flags, and digests before it constructs an argument array. It should never accept a free-form command suffix. OpenClaw tool policy can then expose the adapter while keeping broad host exec and arbitrary network tools out of the render agent’s route.

That separation is important. A skill describes how to create a good composition. It does not turn prose into a runtime sandbox. The adapter owns executable arguments, directories, credentials, resource ceilings, and retained receipts.

Freeze media before Chrome seeks a frame

A preview that loads a remote font, image, map, or video is not a sealed preview. The resource may change between approval and render, return a different variant, negotiate a new codec, or disappear. Even when the content stays stable, network timing can change readiness at capture time.

Copy allowed media into the project, normalize filenames, reject path traversal, and hash each file. Generate a manifest in stable order. For URLs that must be sourced externally, use a separate acquisition step: download under an allowlist and size limit, verify the media type, store the immutable blob, then end network access before composition validation begins.

HyperFrames expects seekable animation because the renderer captures exact times rather than watching a page play in real time. The project contract should ban wall-clock reads, random values without a fixed seed, mutable remote data, and animations that cannot be addressed at a requested timestamp. If a live map or similar viewport is required, capture it as an approved local artifact or treat the current release’s warning as a hard review stop.

Validation evidence from one sealed project

The current CLI exposes several useful gates. doctor checks the rendering environment. lint --json returns machine-readable errors, warnings, information findings, and scanned files. check --json runs lint, runtime, layout, motion, and WCAG contrast verification in one browser session. Its options can sample transitions, save five contrast snapshots, inspect a caption zone, and apply a frame check.

Run those commands against the same sealed project directory that will be rendered. Retain JSON output and snapshots by digest. Decide the warning policy before review: HyperFrames render supports --strict for lint errors and --strict-all for errors plus warnings. A final pipeline that says “strict” in its policy but quietly renders after warnings has two conflicting contracts.

Preview remains useful, but it is review evidence rather than permission. The preview URL, contact sheet, or sampled frames should be linked to the project and media digests. If a composition, variable file, asset, version, or render setting changes, discard the old approval and produce new evidence.

Spend limits belong outside the prompt

The render command supports formats beyond MP4, high frame rates, 4K supersampling, quality levels, multiple workers, Docker, GPU choices, variable files, batch rows, and cloud or Lambda routes. That flexibility is valuable for an operator and dangerous as an unconstrained model surface.

Give each workflow a small profile. A social preview might allow draft MP4 at 1280×720 and 30 fps. A reviewed final might allow 1920×1080 at 30 or 60 fps. Cap duration, workers, temporary storage, wall time, and output bytes. Exclude batch, cloud, Lambda, HDR, custom bitrate, arbitrary variable files, and alternate formats until a concrete job needs them.

Docker is a useful reproducibility option—the CLI itself labels render --docker as deterministic—but Docker does not seal the project or approve resource use. Pin the image, set memory and CPU limits, mount the project read-only, mount only the intended output directory for writes, disable networking, and record the image digest. Host rendering can follow the same contract if the environment is managed; it simply needs a different environment receipt.

Testing what a retry does to the receipt

Before final rendering, present the operator with the version, composition and media hashes, sampled frames, lint and check summary, duration, canvas, fps, quality, estimated resource ceiling, output path, and any warnings. Hash the canonical packet. Bind review to that digest, the reviewer, an expiry, and one idempotency key.

The ledger should move through states such as prepared, reviewed, in_progress, complete, failed, and uncertain. Acquire the job key before the adapter starts Chrome. When rendering succeeds, hash the output and store its byte size, media metadata, command version, input digest, timestamps, and final location in a receipt. A repeated completed key returns that receipt.

If the worker dies after encoding but before writing complete, do not blindly restart. Inspect the expected output and any producer state. If its digest and metadata can be reconciled with the job, complete the existing receipt. If not, retain the uncertain state for review. Duplicate video files may be merely expensive; duplicate publish or upload steps can be externally visible.

No receipt, no automatic retry.

A rollout that exposes mistakes cheaply

Start with a synthetic project and a disposable output directory. Keep network, cloud, publish, and upload capabilities absent. Pin the CLI release and runner image. Then exercise failure paths before giving the adapter a valuable composition.

• Run doctor --json; remove FFmpeg or Chrome and verify admission stops.
• Change one local media byte after preview and require a new manifest and review.
• Add a remote asset and prove acquisition is separated from the render runner.
• Introduce one lint error and one warning; verify the chosen strict policy exactly.
• Save check snapshots, then change a render-affecting variable and invalidate them.
• Try an output path outside renders/ and an unsupported high-cost profile.
• Kill the worker after output creation; reconcile the file instead of rendering again.
• Replay the completed idempotency key and return the original receipt.

Only after those paths are boring should OpenClaw assemble real media and final compositions. Keep publication as another separately approved tool. A render receipt proves which file was produced; it does not authorize uploading that file, replacing a public asset, or notifying a customer.

What the rerun can and cannot prove

This replacement does not claim that HyperFrames was installed, that a video was rendered, that Chrome or FFmpeg was invoked, or that OpenClaw improved production time. It makes no cost, setup-time, throughput, quality, or ROI promise. The retained exercise proves only that a deterministic local admission function returned the expected outcome for 47 synthetic packets.

That is still more useful than the legacy article’s broad automation recipe. The durable part of an agent video workflow is not the prompt that asks for a polished clip. It is the packet that identifies the source, the media, the checks, the operator decision, and the one result the system is willing to accept.

Primary evidence read on 23 July 2026

• HyperFrames README at v0.7.68: project model, agent workflow, seekable animation, frame capture, FFmpeg encoding, skills, and supported stack.
• HyperFrames CLI README at v0.7.68: requirements, init, preview, render, lint, doctor, info, and upgrade commands.
• HyperFrames CLI package metadata at v0.7.68: package version, dependencies, executable, and Node.js engine requirement.
• HyperFrames check command at v0.7.68: combined verification pass, JSON output, sampling, snapshots, contrast, caption-zone, and frame-check options.
• HyperFrames render command at v0.7.68: formats, deterministic Docker option, workers, variables, strict modes, and output controls.
• HyperFrames v0.7.68 release notes: the looping-video coverage fix, native CSS nesting fix, RenderStretch reversion, release date, and immutable change references.
• OpenClaw Tools overview: typed tools, tool policy, skills, plugins, and runtime capability boundaries.