chore(release): bump to 0.4.1
🏗️ Build and Test JellyTau / Run Tests (push) Successful in 18m39s
Publish Documentation / Build & publish docs to gitea-pages (push) Successful in 5m40s
Traceability Validation / Check Requirement Traces (push) Successful in 16s
Build & Release / Run Tests (push) Successful in 6m1s
🏗️ Build and Test JellyTau / Android Compile Check (push) Successful in 9m26s
Build & Release / Build Linux (push) Successful in 19m41s
Build & Release / Build Windows (push) Successful in 13m57s
Build & Release / Build Android (push) Successful in 30m6s
Build & Release / Create Release (push) Successful in 24s

This commit is contained in:
2026-08-05 12:31:16 +02:00
parent 878ac5fa59
commit 1ef6180776
5 changed files with 21 additions and 4 deletions
+17
View File
@@ -6,6 +6,23 @@ Entries are grouped by the capability they change, not by commit. Requirement
IDs in parentheses point at [docs/requirements.md](docs/requirements.md); the
generated trace matrix lives in [docs/traceability.md](docs/traceability.md).
## v0.4.1
### 🐛 Fixes
- **The lockscreen pause works while a video's audio plays in the background.**
The handoff starts native audio and only then tears the WebView `<video>`
down — and that teardown fires a DOM `pause` the frontend reports like any
other, which left the controller believing webview media was still the
player. Transport stayed aimed at it: pressing pause on the lockscreen sent a
control command to a `<video>` that no longer existed while the native player
carried on, and the element's parting position report dragged the displayed
time backwards. A handoff is now tracked explicitly, so it hands transport to
the native backend and ignores what the dying element still reports. A pause
made from the lockscreen also survives the return to the app, instead of being
undone by the play state captured when the handoff began.
(UR-040, UR-005 → DR-052, DR-097)
## v0.4.0
### ✨ Features