chore: pull in main after #3191's squash merge

# Conflicts:
#	packages/core/src/audio/audioFxGraph.ts
#	packages/studio/src/components/editor/propertyPanelAudioFxGroup.tsx
#	packages/studio/src/components/editor/propertyPanelFxNodeRow.tsx
#	packages/studio/src/components/editor/propertyPanelFxPresetMenu.tsx
#	packages/studio/src/components/editor/propertyPanelFxSection.tsx
#	packages/studio/src/player/components/TimelineTrackRow.tsx
#	plans/audio-automation-lanes/SPEC.md
#	plans/audio-fx-presets.md
#	plans/audio-fx-ux/README.md
#	skills-manifest.json
#	skills/hyperframes-audio/SKILL.md

Author: vanceingalls

packages/cli/src/commands/render.test.ts

@@ -193,6 +193,17 @@ vi.mock("../browser/preflight.js", () => ({
   runEnvironmentChecks: vi.fn(async () => preflightState.result),
 }));
 
+// The "render command explicit composition" test below drives the real
+// `render.js` command handler, which takes the plan-based `execute.ts` path
+// (not the `renderLocal` unit under test above) — that path calls
+// `ensureBrowser` directly instead of going through the mocked preflight.
+// Unmocked, it performs a real network download of chrome-headless-shell into
+// the shared `~/.cache/hyperframes/chrome`, racing other packages' browser
+// tests in CI.
+vi.mock("../browser/manager.js", () => ({
+  ensureBrowser: vi.fn(async () => ({ executablePath: "/mock/chrome", source: "cache" })),
+}));
+
 vi.mock("../utils/orphanCleanup.js", () => ({
   killOrphanedProcesses: vi.fn(() => {
     orphanCleanupState.calls += 1;

packages/core/src/audio/audioFxGraph.ts

@@ -691,7 +691,6 @@ export function buildFxChain(
   for (const p of presets) {
     (presetTargets[p.id] ??= []).push(...mixTargets(p.wet.gain, p.dry.gain));
   }
-
   return {
     input,
     output,

packages/studio/src/player/components/TimelineTrackRow.tsx

@@ -7,9 +7,12 @@ interface TimelineTrackRowProps {
   rowKey: number;
   logicalRow: TimelineLogicalRow;
   propertyRows: readonly TimelineLogicalRow[];
-  /** Ids the visible canvas property-lanes container (`<TimelinePropertyLanes id={lanesId}>`). */
+  /** Names the canvas-side content cell — the active clip's own property lanes,
+   *  minted with this single id in TimelinePropertyLanes. */
   lanesId: string;
-  /** Ids the visible header lane row — a distinct DOM node, so a distinct id. */
+  /** Names the header cell. Space-separated because the caret it lives under
+   *  expands two disjoint subtrees (the clip's keyframe lanes AND the track's
+   *  automation lanes) — see TimelineTrackHeader for why they cannot share one id. */
   headerLanesId: string;
   top: number;
   height: number;

plans/audio-automation-lanes/SPEC.md

@@ -111,44 +111,6 @@ valid — they just can't be automation targets until the panel touches them.
 
 **Normalization** (`normalizeAutomation`, mirrors `normalizeAudioFxParams`):
 
-- points sorted by `t`; duplicate `t` keeps the later point
-- `v` clamped to the target's registry range; non-finite → point dropped
-- lanes targeting a node id that no longer exists in the chain are **dropped**
-  (the author deleted the device; its automation dies with it — panel also
-  removes them eagerly on node delete)
-- 1-point lane = constant; empty lanes array = attribute removed
-
-**Precedence for volume** (documented + linted):
-`data-automation` volume lane → GSAP volume tween → `data-volume`.
-New lint rule `audio_volume_double_automation` (warning) when an element has
-both a volume lane and a GSAP tween on `volume`.
-
-## 5. Interpolation semantics
-
-- Between points: linear in the parameter's **working domain**. Params with
-  registry `scale: "log"` (frequency, some times) interpolate in log domain —
-  a 200 Hz → 8 kHz sweep is perceptually linear, matching what a DAW does.
-- `curve` bends the segment: `f(x) = x^(2^(k·s))` shaping applied in the
-  working domain (s = curve, k ≈ 2). Exact constant chosen to visually match
-  Ableton's feel; pinned by unit tests once chosen.
-- Before the first point: hold first value. After the last: hold last value.
-- One shared implementation `sampleAutomationLane(lane, t)` in core — used by
-  the lane renderer (drawing), the scheduler (curve sampling), and the render
-  path. One interpolator, three consumers, or preview and picture drift.
-
-## 6. Preview architecture
-
-Scheduling hooks into `schedulePlayback` (transport), which already runs on
-play / seek / rate change with the clip's `elapsed` offset:
-
-- **Volume lane** → scheduled on the source's existing `gainNode.gain`
-  (post-FX, i.e. fader semantics — matches Ableton, matches the render order
-  where FX runs before the volume bake).
-- **FX param lanes** → scheduled on AudioParams exposed by the graph builders
-  (§8) of the chain instance spliced for this source.
-
-Mechanics per lane, at schedule time:
-
 1. Convert clip-local envelope → context-time segments starting at
    `scheduledAt`, offset by `elapsed`, scaled by playback rate.
 2. Linear segments → `setValueAtTime` + `linearRampToValueAtTime` (log-domain

plans/audio-fx-presets.md

@@ -133,13 +133,13 @@ The carve pattern: read the decoded samples, measure something, emit a chain
 and/or automation lanes. **The machinery for this is already built and shipped**
 — what carve does with a voice against a bed generalises:
 
-| Script                                        | Reuses                                             | Emits                         |
-| --------------------------------------------- | -------------------------------------------------- | ----------------------------- |
-| Voice carve _(shipped)_                       | `analyseCarveBands`                                | peaking cuts + per-band lanes |
-| Auto-duck _(shipped, inside carve)_           | `analyseCarveDuck`                                 | one volume lane               |
-| Leveller _(**shipped** — `audioLeveller.ts`)_ | windowed RMS                                       | lane on a `gain` node         |
-| De-esser                                      | `analyseCarveDynamics`, re-parameterised (see §5e) | lane on a peaking cut         |
-| Tone match                                    | `powerSpectrum` vs a target curve                  | 3–5 peaking nodes             |
+| Script                              | Reuses                                             | Emits                         |
+| ----------------------------------- | -------------------------------------------------- | ----------------------------- |
+| Voice carve _(shipped)_             | `analyseCarveBands`                                | peaking cuts + per-band lanes |
+| Auto-duck _(shipped, inside carve)_ | `analyseCarveDuck`                                 | one volume lane               |
+| De-esser                            | `analyseCarveDynamics`, re-parameterised (see §5e) | lane on a peaking cut         |
+| Leveller                            | `windowDb` walk                                    | lane on a `gain` node         |
+| Tone match                          | `powerSpectrum` vs a target curve                  | 3–5 peaking nodes             |
 
 This is the strongest argument in the doc: **none of them needs new DSP** —
 only a different question asked of code that already runs. One (de-ess) needs
@@ -431,61 +431,6 @@ Four notes:
 
 ---
 
-## 6b. What shipped
-
-| Commit      | What                                                                 |
-| ----------- | -------------------------------------------------------------------- |
-| `a533d1677` | the preset catalogue in core — 18 presets over four shelves          |
-| `de2b78047` | applying presets from the rack                                       |
-| `29f53f935` | `label` on a node, so a chain reads as jobs rather than filter types |
-| `e984a9e62` | the multi-band EQ in core, as a composite over shipping filters      |
-| `2eaa71cac` | the Tone module — faders in the rack                                 |
-| `e723216a1` | the levelling script                                                 |
-
-Three things worth carrying forward:
-
-**`parseAudioFxChain` silently dropped `fromPreset`** until `29f53f935`. The
-round-trip test compared only node _types_, so it passed while the tag that
-lets a preset find its own nodes was being lost on every reload. Any new tag on
-a node (`fromEq`, `fromLeveller`, `label`) must be added to BOTH the parser and
-the serializer, and the round-trip test must compare it.
-
-**The single-knob rule broke on `peaking`** and it took someone asking to see
-it. "How much" cannot be the one knob when the range is the first decision. The
-answer was to make the range the module — the add menu offers _jobs_ — which
-also dissolved the duplicate-name problem at the root.
-
-**The levelling target must be a level the track already reaches.** Anchoring
-it to an absolute figure turns levelling into a volume change. The 80th
-percentile of the track's own speaking windows is the figure that works.
-
-## 6c. The two scripts NOT built, and why
-
-**De-esser — deferred, not abandoned.** The leveller is its structural template:
-analysis → profile → result → remove → summary, with a mutation pass over each.
-Two constraints have to be designed for before it is written, and neither is
-visible until you try:
-
-1. `analyseCarveDynamics` cannot be reused unchanged. Its hop is
-   `max(FRAME, length / POINT_BUDGET)` — 85 ms at best, ~150 ms on a
-   real-length track — while sibilants are 50–150 ms events. At that resolution
-   the envelope cannot land on them, and its `ATTACK_S`/`RELEASE_S` are tuned
-   for musical ducking besides. Same machinery, re-parameterised for a
-   sibilance timescale.
-2. **`MAX_AUTOMATION_POINTS` is 512.** A dip needs three or four points, and a
-   long voiceover holds hundreds of sibilant events, so a naive lane blows the
-   cap and the scheduler truncates it — silently, leaving an envelope that
-   stops partway through the clip. Budget it up front: strongest-N events, or
-   merge adjacent dips.
-
-**Tone match — superseded for v1.** It existed to give a casual author a way to
-fix the tone of a track without understanding frequencies. The Tone EQ now does
-that with a control they already know, and it does it _predictably_, which
-matching against a reference clip does not. What remains is genuinely advanced
-— matching one track to another — and it carries real unknowns: which reference,
-how much correction, what to do when the two sources have different content.
-Not worth building before anyone has asked for it.
-
 ## 7. What to build first
 
 1. **Character presets** (§5c) — highest ratio of delight to risk. Pure

plans/audio-fx-ux/README.md

@@ -5,16 +5,14 @@ routing, what is driven versus set. But information a casual author cannot read
 is decoration, and the rack speaks entirely in Hz, dB and ratios. So the drawing
 stays and the **language changes**.
 
-The plain-language layer over every effect in the registry ships as
-`packages/core/src/audioFxCopy.ts`, and the coverage that used to gate a review
-page — every effect, parameter and preset must have copy — is now
-`audioFxCopy.test.ts`, so it runs on every commit rather than when somebody
-remembers to regenerate a page.
+`copy.mts` is the design work: a plain-language layer over every effect in the
+registry. `build-preview.mts` renders the review page from it **plus the real
+registry and preset catalogue**, and **fails** if any effect, parameter or
+preset lacks copy — so the page cannot quietly omit something that ships.
 
-This document is the design record. What it describes is built: read it against
-the FX rack in the studio, or against `audioFxCopy.ts`, `audioFxJobs.ts`,
-`audioFxProfiles.ts` and the panel components under
-`packages/studio/src/components/editor/propertyPanelFx*`.
+```bash
+bun plans/audio-fx-ux/build-preview.mts /tmp/rack-ux.html
+```
 
 ## The three rules
 
@@ -130,9 +128,7 @@ the frequency under **Details**, for the author who wants to.
 This changes the catalogue, not just the copy: the presets should reference
 named jobs, and `EFFECT_COPY.peaking` stops being one entry.
 
-## Shipped: a multi-band EQ ("Tone")
-
-_Built in `e984a9e62` / `2eaa71cac`. The design below is what was built._
+## Proposed: a multi-band EQ ("Tone")
 
 The clearest failure this exercise surfaced is a rack holding two _Shape One
 Range_ modules doing different jobs. A multi-band EQ is the answer, and it is a
@@ -161,97 +157,24 @@ detent is what an equaliser looks like to everyone who has met one. Collapsed,
 it reads like every other module: "Bass +3, Middle −2, Treble +2", or "Flat"
 when nothing has been touched.
 
-## Decided (2026-08-10)
-
-All three were open until now, and the first was blocking the wiring.
-
-**The plain name replaces the DSP name; the DSP name lives under Details.**
-The rack reads plain top to bottom — `Remove Rumble`, not `highpass` — and the
-header stays narrow, which matters because it already carries a summary, a
-bypass, two arrows and a delete. Nothing is lost: opening a module shows the
-DSP name beside its real parameters, so the author who wants the mapping finds
-it exactly where the mechanism is, and the author who does not never meets it.
+## What still needs deciding
 
-**Presets sort by complaint; the effect list stays in signal order.**
-The two menus stop competing to be the same thing. Presets are the casual
-author's door and `PRESET_PROBLEM` already carries the line for all 18 of them,
-so this costs no new writing. The effect list stays Filters / Dynamics /
-Non-linear / Time — it is the expert's tool, and that grouping teaches the
-signal path the rack itself is ordered by.
-
-**Everything auditions on hover, with a spinner for the ones that measure.**
-Static presets apply to the playing audio and revert on leave, which the graph
-rebuild path already supports. A carve or an Even Out Levels analyses first and
-says so while it does — the same spinner the carve module already shows. This
-is the expensive answer of the three: analysis is seconds, and a hover that
-takes seconds is one the author has often already left, so whatever gets built
-needs a cancel on leave and must not apply a result that arrives late.
+- Does the plain name **replace** the DSP name or sit beside it? Replacing is
+  friendlier but strands what the author learns.
+- Should the **menus** be organised by complaint ("my voice sounds boomy")
+  rather than by effect family? The rack itself must stay in signal order,
+  because order is audible — but the menus have no such constraint, and the
+  preset section of the preview is written that way to show the difference.
+- How much should **hover audition**? Hearing a preset before committing is the
+  single strongest affordance here. Cheap for static presets; a measuring script
+  has to analyse first and cannot preview instantly.
 
 ## Status
 
-The EQ, the named jobs and the levelling script are **built**, and the copy
-layer has now landed as `packages/core/src/audioFxCopy.ts` — `EFFECT_COPY`,
-`BANDS`, `PRESET_PROBLEM` and `SUMMARY`, with the completeness check as a test
-beside it rather than a build step.
-
-**It is wired.** `propertyPanelFxNodeRow.tsx` takes the name from `EFFECT_COPY`,
-the sentence under it from `SUMMARY`, and every knob's name from the same place
-via `plainDef` — which writes the words over the registry's def and leaves range,
-step, unit and automatability alone. The DSP name sits above the knobs as
-`Details — High-pass`. The preset shelf leads with `PRESET_PROBLEM` and follows
-with the preset's own name. Hover and focus both audition, through the same
-preview channel a slider drag uses; the leveller measures first, says
-"measuring…" while it does, caches the decode per `src`, and drops a result that
-arrives after the pointer has gone.
-
-Three things that took a second pass, all worth knowing before touching this
-again. An audition has to survive the panel re-rendering under it — the group
-re-renders every playhead tick, so anything keyed on its inline callbacks tears
-down thirty times a second. Applying must NOT revert, since the audition _was_
-the thing applied. And moving between two entries in a shelf is not leaving it,
-so each entry has to call its neighbours' auditions off itself.
-
-**The three rules are built too**, and so is the visual direction:
-
-- _Two faces._ A module opens on its name, what it is for, and the one control
-  that carries it — `EFFECT_COPY.primary`, with `primaryEnds` saying what its
-  two ends sound like. Everything else is behind a Details disclosure, which is
-  also where the DSP name lives. Ten of fifteen effects; the five whose primary
-  is "strength" open on all their controls until `PROFILES` ships, which is
-  honest — inventing one knob for them now would be a knob that lies.
-- _One knob that matters._ `packages/core/src/audioFxProfiles.ts`. Five effects
-  get a derived control over several parameters, continuous rather than the
-  three-point tables proposed here. **Three of the five figures were wrong** and
-  only rendering showed it — the write-up is `~/audio-fx-profiles-ab/README.md`.
-- _Name the outcome._ Modules, knobs, the add menu and the preset shelf.
-
-- **The range IS the module.** The add menu offers five named jobs — Tame
-  Boominess, Reduce Mud, Reduce Boxiness, Add Clarity, Soften Harshness — and
-  `peaking` is not offered as itself. `packages/core/src/audioFxJobs.ts`. Every
-  one is a job the preset catalogue already ships, at the settings it ships it
-  with, so the list names the vocabulary the presets were written in rather than
-  inventing a second one.
-- **The shared ruler.** Every spectral module shows where it acts across the
-  seven named ranges, log-spaced, with the range it is in named underneath.
-- **Family lettering and the tint step.** Four families told apart by the sans,
-  the serif spent on non-linear, monospace for the measuring modules, and a
-  lightness step per module derived from registry position.
-- **The schematic**, translated to one column: IN and OUT terminals, every step
-  numbered over what the rack shows, and a preset's consecutive nodes bracketed
-  as the one thing that was added.
-
-Everything in this document is now built.
-
-It has no entry for Tone or for the levelling module, because both carry their
-own copy in core (`audioEqSummary`, `levellingSummary`). That is the right home
-for it: a summary that has to read the chain belongs beside the code that
-writes it.
-
-The `PROFILES` figures — what one knob derives at gentle/middle/strong — have
-**shipped and been corrected**. They are `HF_AUDIO_FX_PROFILES` in
-`packages/core/src/audioFxProfiles.ts`, continuous rather than three-point, and
-three of the five were wrong as proposed: the compressor's make-up left the
-track quieter at full evenness, saturation's trim went the wrong way and made
-"Warmth" mean "much quieter", and the gate did essentially nothing because
-`release` was not in the profile at all. Measurements, method and the sweep that
-found the last one are in `~/audio-fx-profiles-ab/README.md`.
+`copy.mts` is a proposal, not shipped code. When it lands it wants to be
+`packages/core/src/audioFxCopy.ts` beside the registry, with the completeness
+check as a test rather than a build step.
+
+The `PROFILES` figures — what one knob derives at gentle/middle/strong — are
+proposed values, not measured ones. They want the same before/after listen the
+clip-before-duck fix got.

skills-manifest.json

@@ -26,8 +26,8 @@
       "files": 121
     },
     "hyperframes-audio": {
-      "hash": "36435b85d7697d22",
-      "files": 5
+      "hash": "534cea75fe0f2bc6",
+      "files": 6
     },
     "hyperframes-cli": {
       "hash": "e042fcaaa3f9767f",