Skip to content

docs(changelog): weekly digest 2026-08-17–2026-08-24 - #3462

Merged
jrusso1020 merged 1 commit into
mainfrom
changelog-weekly-2026-08-24
Aug 24, 2026
Merged

docs(changelog): weekly digest 2026-08-17–2026-08-24#3462
jrusso1020 merged 1 commit into
mainfrom
changelog-weekly-2026-08-24

Conversation

@jrusso1020

Copy link
Copy Markdown
Collaborator

Description

Weekly digest for August 17 to August 24, 2026, covering 126 non-merge commits and 15 releases (v0.7.110 through v0.8.12).

Generated with bun run changelog:weekly, then rewritten for publication. The generator surfaced 10 bullets from 126 commits and weighted them toward whatever landed last, so this is a rewrite from the commit index rather than a polish of its draft.

The headline is grouped audio. A voiceover, a music bed and a sound effect can live in named groups, each with its own volume, effects chain and mute. The rollout finished by deleting the three canaries (audio-fx-rack, audio-track-mute, audio-groups) rather than raising their percentages, so the rack, group rows and mute are on for everyone.

Two things the version numbers would have told you wrong, both checked at HEAD rather than inferred:

Group volume does survive, as data-volume on the group element, and mute works by dropping the member from the mix rather than writing volume 0.

Testing

  • npx mint validate from docs/ passes (success build validation passed).
  • node scripts/check-docs-snippet-motion.mjs and node scripts/check-tracked-artifacts.mjs both exit 0.
  • Every sha in the digest was machine-verified before the file was written: resolves to 40 hex chars, prefix-matches its 9-char display form, is an ancestor of origin/main, and has a commit date inside 2026-08-17T00:00:00Z .. 2026-08-25T00:00:00Z. The same guard blocks em-dashes, en-dashes in prose, and any leftover TODO / style-bar marker. It was negative-tested on all three failure classes so a pass means something.
  • All 126 window commits carry a unique inline (#N), so PR mapping needed no merge-ancestry fallback.
  • Feature claims confirmed present at HEAD: audioGroups.ts (data-volume, mute-by-drop, resolveCarveSourceIds), audio/audioFxWorklets.ts, commands/normalize-audio.ts, previewLifecycle.ts + previewLifecycleOutput.ts, safePath used by htmlBundler. Confirmed absent: the three retired canaries (with canary.test.ts asserting no audio canary returns) and head_leaked_text.
  • Only docs/weekly-updates.mdx is committed. The generator also writes updates/weekly/ and updates/social/; both are left uncommitted.

The video embed points at weekly-changelog-aug17-24.mp4 following the convention of the last four entries. The file is not uploaded yet, so that URL 404s until the render lands; I will comment the CDN URL on this PR once it is up.

🤖 Generated with Claude Code

Grouped audio shipped and its three canaries were deleted rather than raised.
Solo and the group meter shipped and were removed in the same week, so the
digest says so. Notes that the v0.8.0 minor bump marks two catalog component
removals rather than the week's headline.

Generated with bun run changelog:weekly, then rewritten for publication.
Every sha was machine-verified: 40 chars, prefix-matched, an ancestor of main,
and inside the 2026-08-17..2026-08-25Z window. npx mint validate passes from docs/.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@mintlify

mintlify Bot commented Aug 24, 2026

Copy link
Copy Markdown

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
hyperframes 🟢 Ready View Preview Aug 24, 2026, 4:48 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

@jrusso1020

Copy link
Copy Markdown
Collaborator Author

Video is live, so the embed committed in this PR now resolves.

CDN: https://static.heygen.ai/hyperframes/changelog-videos/weekly-changelog-aug17-24.mp4

Verified rather than assumed:

local file 34,784,921 bytes
S3 object 34,784,921 bytes
CDN content-length 34,784,921 bytes
CDN HTTP/2 200, content-type: video/mp4, x-cache: Miss from cloudfront
duration 53.0s, 1080x1080, 1590 frames

x-cache: Miss rather than Hit is the part that matters, since a Hit would mean CloudFront served a stale object. Invalidation I7X1AD25LZ5Q7KMDFDHUEVRHQF.

Gates, all green at the rendered head:

  • hyperframes check (repo-local CLI, not npx): 0 errors, layout 0 issues, contrast 72/72 WCAG AA. Two warnings remain, composition_file_too_large and timeline_track_too_dense, both inherent to the single-doc master the build spec mandates.
  • Seam gate: 5/5 seams, 0 fail, 0 warn, all cut-the-curve LEFT with matched speeds.
  • Frames: captions confirmed on all six scene midpoints (rail max-luma 236-237 against a control band at 41-50 measured in the same pass), and all six green moments verified by a before/after differential across their trigger.

Two defects the automated gates could not see, both caught by reading frames:

  1. The Windows cards rendered off-canvas. I had positioned them at top: 640/660 inside a card that itself sits at top: 330, putting them at absolute y≈970 to 1088 on a 1080 canvas, clipped at the edge and colliding with the caption rail. hyperframes check reported Layout 0 issues throughout, because every theme slide carries data-layout-allow-overlap exactly as the build spec instructs, which disables collision detection on precisely the slides that hold the mocks. Fixed by moving both inside the terminal card's own box, then re-rendered.
  2. My own green-moment threshold was wrong, not the video. An absolute >= 250 pixel floor flagged three of six moments; small green type at 19-23px legitimately paints 60-240 pixels. The differential across each trigger (0 to 101, 0 to 237, 0 to 63) is the real measurement.

Every mock is built from verified source rather than invented: the terminal shows the real --json flag and the real PreviewLifecyclePayload keys (schemaVersion / operation / ok / result.state|mode|ready), and the lint scene names head_leaked_text, the one rule removal I could confirm by name. I deliberately did not invent seven rule names to fill the panel.

— Rames Jusso

@jrusso1020

Copy link
Copy Markdown
Collaborator Author

Correcting my own explanation above. I said data-layout-allow-overlap is why check missed the off-canvas cards. That was wrong, and the real mechanism is more useful to know. Verified against packages/cli/src/utils/layoutAudit.ts at main:

An off-canvas element raises canvas_overflow, which allow-overlap does not touch (that marker suppresses content_overlap). Three separate things kept it quiet, and the first is the one that actually did it:

  1. Sampling density. The layout audit took 9 samples across 53.0s, one every ~5.9s. The card was on screen for 2.86s (44.62 to 47.48), so the odds of any sample landing on it were about 49%. None did, which is why no row appeared at all, not even info.
  2. Persistence tier. applyPersistenceTier:273 caps any issue seen in occurrences <= 1 at info. Escalating needs 2 samples, i.e. roughly 11.8s of continuous visibility at this sample rate. A ~3s element mathematically cannot exceed info, at any breach size.
  3. Breach floor. Even with enough samples, isCanvasBreachHeldLarge:297 requires the breach to clear min(container.w, container.h) * 0.05, which is 54px on a 1080 canvas. Mine was 8px (the card ran 970 to 1088; the sibling console card breached 0px). And canvas_overflow tops out at warning, never error.

So check behaved exactly as designed. The generalization worth keeping: a geometry defect on an element visible for less than ~12s cannot exceed info severity regardless of how far off-canvas it is, so for anything short-lived the layout gate is not a weaker version of frame-reading, it is silent by construction. That is the argument for treating frames as a separate instrument rather than a redundant one.

Thanks to Home for catching that my allow-overlap reasoning was off; the floor figure in that hand-off was 27px, which is the shape of the rule but not this constant.

— Rames Jusso

@jrusso1020

Copy link
Copy Markdown
Collaborator Author

Correcting my correction. Home's original 27px was right, and I misattributed it.

I said the operative constant was min(w,h) * 0.05 = 54px and that sampling was the dominant cause. Both wrong for this defect. Verified in packages/cli/src/commands/layout-audit.browser.js at 95e1ac9f:

Line 1155 states the ownership split outright: "Painted panels breaching the canvas: text is canvas_overflow's, media is frame_out_of_frame's, panels were nobody's." My card was a .glass painted panel, so the code is panel_out_of_canvas, not canvas_overflow. Its tolerance is max(24, min(w,h) * 0.025) = 27px at 1080 (:1150-1151), and that floor is passed as the tolerance to overflowFor, so an 8px breach returns falsy and no issue is generated at any sample time.

So the causal chain is one step, not three:

code panel_out_of_canvas (painted panel, per the :1155 ownership comment)
tolerance 27px
my breach 8px → not detected, ever
had it been detected area 35,360px² vs hero floor 116,640px² → info

Sampling was never operative here, because the issue never existed to be sampled. That part of my previous comment overstated a real property into a cause it didn't have. The property itself is still true and still worth knowing: the layout audit places 9 midpoints across 53.0s and applyPersistenceTier:273 caps occurrences <= 1 at info, so a short-lived instance of any detected, persistence-tiered code cannot exceed info. panel_out_of_canvas is in that set (:203). It just wasn't what hid this one.

One more thing I got wrong in the original comment: the skip flag in this function is data-layout-allow-**overflow** (hasAllowOverflowFlag), which is a different marker from data-layout-allow-**overlap**. So neither marker was involved.

Three passes on one question, and the through-line is that I twice cited a real constant for the wrong code. The check that would have settled it the first time is the one-line ownership comment at :1155, not the arithmetic. The conclusion that survives all of it is unchanged and is the only part that matters operationally: an 8px breach on a painted panel is invisible to check by design, so frame-reading is a separate instrument, not a redundant one.

— Rames Jusso

@miguel-heygen miguel-heygen left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exact-head review at fb23d8d379849d78d8ec2d4e450b62d440589699.

Audited: the full 130-line weekly entry, every linked commit/PR pair, the release/window counts, current-main mergeability, and the attached/CDN video across the full timeline including the repaired scene 4. Nothing skipped.

Independent source checks: 83 commit links (82 unique) all prefix-match their 40-char SHA, are ancestors of the digest base, fall inside Aug 17–24 UTC, and carry the linked PR number. The base has exactly 126 non-merge window commits and 15 release tags, v0.7.110 through v0.8.12. v0.8.0 contains only the release commit plus #3317. Audio canaries/solo/meter absence and surviving group volume/mute/carve code reconcile with the prose. The one-file branch merges cleanly onto current main.

Video evidence: attached and CDN bytes have the same SHA-256 (0b19c14e…); CDN is HTTP 200 / video/mp4 / 34,784,921 bytes. ffprobe reports H.264 + AAC, 1080×1080, 30fps, 53.0s; audio is present (mean -18.8 dB, max -0.5 dB). I inspected a 9-frame full-film sheet, the outro, and four scene-4 frames: captions remain visible, the Windows cards stay inside their panel and above the caption rail, and the visual themes match the digest.

No blocking findings. Current-head docs validation, CodeQL, format, and path-relevant checks are green.

Verdict: APPROVE
Reasoning: The publication claims reconcile to immutable source, the embed resolves to the reviewed artifact, and the rendered video is visually and technically clean at the repaired head.

— Magi

@jrusso1020
jrusso1020 merged commit 21dc4ae into main Aug 24, 2026
46 checks passed
@jrusso1020
jrusso1020 deleted the changelog-weekly-2026-08-24 branch August 24, 2026 18:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants