mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-03 04:38:33 +00:00
The previous commit's store guard was silently never true. A reveal request carries the BARE dom id — `revealElementId = runtimeAudioId(keyframeClip)`, because the panel and the runtime speak that — while the store's ids are `sourceFile#domId`. So `elementKey === id` compared "music-bed" against "index.html#music-bed" and the request was still cleared by its own selection. This is the id-space boundary the branch's own handoff names as the trap most likely to be re-broken, and it fails exactly as documented: no error, the feature just never matches. Caught only by driving the real UI — the store said `selected: "index.html#music-bed"` and `revealSurvived: null` in the same read. `revealTargetsSelection` now splits the key with the existing `splitTimelineElementKey` and is a named function in `playerStoreSelection.ts` so the crossing is stated once, where it happens. **Verified in the browser, both halves, which had never been watched working:** - clip NOT selected: clicking a lane label selects the clip, the rack opens, and the carve module expands (correct — that lane's node is a carve band). The request is consumed and retired to null by the new unmount clear. - clip ALREADY selected: collapsing the module and clicking the same lane again reopens it, which the old value-equality consumption could not do. studio player: 103 files, 1355 tests. fallow clean.