[WaterrrForever]

What

Re-pins all five style-sampling template packs in templates.ts (new sha256 and bytes) to bundles that carry the fixes from the v0.9.16 release check.

Upload done (2026-11-06). The five bundles are in the private bucket at desktop-moments/bundles/<id>/<sha256>/bundle.tar.gz (application/gzip, SSE AES256). The keys are new, so the bundles main pins today are untouched.

Why

The five 4-minute release-check films found the following problems:

Pack	What the new bundle fixes
animated-science-explainer (M9003)	The end card was hidden in every film. Each section's scene z-index painted over it, because nothing made a stacking context. assemble.py now gives every mounted clip isolation: isolate, and the section and shot templates isolate their stage too.
collage (M9001), 3d-brand (M9004), 3d-true-crime (M9005)	add_sound.py crashed with AttributeError: 'NoneType' object has no attribute 'group' on ffmpeg 4.2, because adelay … all=1 needs 4.3 or later. It now uses `adelay=30
all five, including finance (M9002)	The REMIX, kit README and voice-tool text said media-use voices lists "the clones on the HyperFrames account making the film", and the science pack said "One clone: use it". The list is the whole workspace's, so they now say: use the clone the person names as theirs, and never pick from the list by count, language or name. This goes with #7261.
animated-science-explainer	The README says narration.py and mixcheck.py need ffmpeg 4.4 or later (amix normalize).
animated-science-explainer (M9003), re-pinned after review	Desktop's [voice: your HeyGen voice <name> (<id>)] tag was taken as settled. Desktop's own-voice picker lists every clone the workspace can use, so the tag only records a pick. A picked, named or id-given clone is now used only when the person says it is theirs or that its owner agreed; otherwise the agent asks once.

How

• Build: each bundle is git ls-files | tar --format=gnu --owner=0 --group=0 --numeric-owner --mtime='2026-11-05 00:00Z' -cf - -T - | gzip -9 -n, the same recipe as the current packs.
• Recipe check: I rebuilt the unchanged finance pack with the old mtime, and it reproduced the pinned 52be6585… byte for byte.

id	sha256	bytes
M9001	bb9f71ee3b27cc046e161e53d9c6c7bd7ce9a6d6b6f41acc01da4eb455a63230	36702348
M9002	e8ace0e0e4fe8219010ce01e7ca1eae6ab03741d6eb60140e0b2a4ff9628dd30	140485130
M9003	205011f9ed345db786a611bfff43036e6c971368420c87120ff376a7797a26ee	25535379
M9004	33bbabcf94db88bedf0f2ef97331a7a34dff4ba6d5b09846ec759600b99d15ae	20126308
M9005	2c27e08dd83984c0470f3c4f9f0c94f2b4528bbc27160312bbda580e89a43d63	6544517

Test plan

• End card, before: snapshot of the release-check science film with its sections' own fix removed. At 247 s and 251.5 s the end card is hidden behind the last section's street scene.
• End card, after: the same film reassembled with the new assemble.py and the section files untouched. The end card shows at 247 s and 251.5 s, and the frames at 60 s and 150 s are unchanged.
• add_sound.py, ffmpeg 4.2.7: the old script raises AttributeError. The new one files the SFX with the same gain as ffmpeg 7.0.2, +1.4 dB on the test file.
• add_sound.py, bad input: it exits 1 with ffmpeg's error.
• Python 3.8: every changed .py compiles.
• templates.test.ts: 16 passed.
• templates pull of each pack: run from this branch's CLI source, signed in. All five fetched through /v1/hyperframes/moments/<id>/bundle, passed the CLI's size and sha256 check, and unpacked byte-identical to their archives (M9001 244 files, M9002 593, M9003 125, M9004 372, M9005 139).

🤖 Generated with Claude Code

https://claude.ai/code/session_01HebQXPiLcYKQfvPWB3Fgxy

[jerrai-bot-heygen]

Code review at 3af1637a1491fd2c261c1984379696c86bebd05d: the sole diff changes five template pack SHA-256/byte pins; each ID and pin matches the PR's table, and templates pull requests the pinned SHA then refuses a byte/hash mismatch before unpacking. I found no code defect in the pin update itself. Not an approval or merge-ready verdict: this PR is deliberately draft and the five private bundles are not uploaded. I could not inspect the bundles to verify the advertised end-card, ffmpeg-4.2 and consent-copy fixes, nor run templates pull against them; until upload the new pins yield 404. Keep the draft/merge hold, then verify every pinned bundle's bytes/hash and a successful pull before requesting a fresh stamp. CI status does not establish the unpublished bundle contents. No merge/enqueue/upload by me. — Jerrai

[jrusso1020]

Reviewed at 3af1637a1491fd2c261c1984379696c86bebd05d.

Need: yes, after bundle publication · Size: ok · Reuse: existing immutable pack pins and integrity-checked pull · Simpler: already minimal · Structure: fine
Risk: medium — all five downloadable template versions change together.

Code-only review; retain the draft/merge hold. The entire patch changes only the five sha256/bytes pairs in templates.ts; IDs/slugs and pull logic are unchanged. All five entries match the PR's table. Existing pull requests the pinned hash, verifies both byte count and SHA-256 before unpacking, and preserves an already-pulled folder rather than overwriting it.

The archive contents are not in this PR, so I have not independently verified the science end-card fix, ffmpeg compatibility, ownership wording, or that the listed digests describe those fixes. Do not merge until all five exact bundles are uploaded and each authenticated templates pull succeeds with these pins. No bundle upload, download, live authenticated pull, or rendering was exercised. The existing templates suite did not collect with the borrowed dependency setup; this is a source/pin review only.

Verdict: COMMENT
Reasoning: No defect found in the pin edit, but the unpublished artifacts remain a release hold and their contents need verification after upload.

— Rames (hf-review)

[WaterrrForever]

Upload hold lifted: all five bundles pinned at 3af1637 are in the private bucket at desktop-moments/bundles/<id>/<sha256>/bundle.tar.gz (application/gzip, SSE AES256). templates pull <slug> from this branch's CLI source fetched all five, each passed the CLI's size and sha256 check, and each unpacked byte-identical to its archive (M9001 244 files, M9002 593, M9003 125, M9004 372, M9005 139). The keys were new, so the bundles main pins today are untouched.

[jrusso1020]

Reviewed at 3af1637a1491fd2c261c1984379696c86bebd05d.

Need: yes · Size: ok · Reuse: existing immutable bundle pins and integrity-checked pull · Simpler: already minimal · Structure: fine
Risk: medium — five downloadable template versions change together.

No code blocker. This is the same one-file, five sha256/byte-pair update covered by my prior code review. I re-read the full templates.ts: IDs/slugs and request/download/unpack behavior are unchanged; requests include the pinned hash and both byte count and SHA-256 are checked before unpacking. All five pins still match the PR's table.

The publication hold is addressed by Miao's new upload and authenticated-pull receipt: all five exact versions are reported uploaded, successfully pulled through the API and extracted with contents matching the local archives. I am relying on the author's verification for publication and artifact contents, not claiming an independent download. My direct S3 HeadObject check was denied (403); I did not retrieve the archives, rerun authenticated pulls, exercise the end-card/ffmpeg fixes, or rerun the template suite. The previous borrowed-dependency collection limitation remains disclosed in my earlier review.

The PR is still draft; the author will mark it ready. Draft status is separate from this code verdict.

Verdict: APPROVE
Reasoning: The pin update has no identified defect, and the author has supplied the previously missing publication/pull verification. The source head is unchanged.

— Rames (hf-review)

[jerrai-bot-heygen]

Re-reviewed the unchanged pin head 3af1637a1491fd2c261c1984379696c86bebd05d after the upload/pull report. Request changes on the science pack's voice-consent instruction before stamping these artifacts. Miao’s quoted M9003 REMIX step 1 treats a Desktop-generated [voice: your HeyGen voice <name> (<id>)] tag as settled, with no ownership question. The current Desktop source does not establish ownership: OwnVoices.tsx:27 lists type: "private" voices available to the workspace, and OwnVoices.tsx:129–130 labels any selected row pickedVoice(voice, true); setupAsks.ts:420 turns that own marker into the your HeyGen voice tag. The list has no creator/owner field. A person can therefore pick a teammate’s clone in that UI, and M9003 would treat the generated tag as ownership/permission even though it records only selection. The template’s instructions take precedence over the shared style-sampling guide, so #7261’s new consent question does not necessarily save this path.

Please change M9003 to treat this Desktop tag as a selection, not ownership attestation: ask whether it is the person’s clone or its owner agreed to this film before synthesis, unless a separate trusted ownership signal can be shown. Repack, upload at a new immutable hash, and re-pin/test the science bundle. The three other narrated packs’ quoted passages require the person to name the clone as theirs, so this finding is scoped to M9003; the full archive contents remain uninspected by me. The five current pins and the author’s authenticated-pull receipt establish availability/integrity, not consent semantics. I did not download private archives or run a paid generation. The PR is still draft; no merge/enqueue by me. — Jerrai

[jrusso1020]

Reviewed at d405fe6a685c589a06d11777263a3a01db5a8211.

Need: yes · Size: ok · Reuse: existing permission question and immutable bundle pull · Simpler: already minimal · Structure: fine
Risk: medium — an artifact instruction controls workspace-clone use.

The supplied M9003 replacement passage addresses Jerrai's selection-versus-ownership finding: a Desktop voice tag explicitly identifies a pick, not whose voice it is. Under that wording, picked, named and ID-supplied clones all require the person to say it is theirs or that its owner agreed to this film; otherwise the agent asks before using it. My earlier pin-only approval did not inspect the old archive instruction and therefore did not establish that semantic guarantee.

Independent source verification: the API compare from 3af1637a contains only M9003's hash and byte count. A source assertion confirms the other four pins and all runtime code are identical. All five source entries match the updated PR table; M9003 is 205011f9ed345db786a611bfff43036e6c971368420c87120ff376a7797a26ee, 25,535,379 bytes. The unchanged pull verifies bytes/hash before unpacking.

Artifact evidence is author-reported: Miao supplied the replacement passage, reports an all-five-source search finding this tag path only in M9003, and reports a reproducible rebuild, immutable upload and successful integrity-checked pull of the new 125-file bundle. I reviewed that quoted wording; I have not independently downloaded the new archive or confirmed its internal diff. My earlier direct bucket access was denied. I did not rerun the 16-test suite, rendering, ffmpeg checks or paid generation. These limits also apply to the unchanged four bundles.

Verdict: APPROVE
Reasoning: The reported replacement closes the specific consent-inference path, and the verified source delta pins precisely the replacement artifact. This relies on the author's artifact-content and pull verification, not an independent archive audit.

— Rames (hf-review)

[jerrai-bot-heygen]

Re-reviewed ready-for-review #7263 at d405fe6a685c589a06d11777263a3a01db5a8211. The sole successor commit changes only M9003's immutable hash/byte pair in packages/cli/src/commands/templates.ts; the other four pack pins and the CLI’s hash/size-before-unpack path remain unchanged. The new science passage supplied by Miao explicitly treats Desktop’s [voice: your HeyGen voice …] tag as a selection, not proof of ownership, and requires the person to say a picked, named or ID-supplied clone is theirs or that its owner agreed to this film before synthesis. That addresses my prior finding: current Desktop source lists workspace-private voices and labels a chosen row own, without owner provenance. Rames independently approved this exact head.

Evidence boundary: the new M9003 archive is private and not included in the PR. I verified the source pin delta and reviewed Miao’s quoted replacement text and authenticated-pull/reproducible-build receipt; I did not download the archive, inspect its full contents, execute its ffmpeg/end-card fix, or run a live generation. This approval relies on the author’s artifact-content and pull verification, not an independent archive audit. Hosted new-head tests were still running at stamp time, an independent merge gate. No merge, enqueue, upload or paid vendor call by me. — Jerrai