Odzyskanie: po powrocie do projektu (baner nad osią czasu) albo na stronę beatu (baner w panelu Quick Take) użytkownik dostaje „Odzyskaj i zapisz” / „Dokończ zapis” albo świadome „Odrzuć nagranie” (z potwierdzeniem). Nic nie jest wysyłane automatycznie. Jeśli kopia zna już serwerowy takeId, najpierw idzie idempotentna finalizacja tego samego take'a (serwer powtarza wynik dla READY) — dopiero martwa sesja (wygasła / bez pliku) pozwala na nowy upload. Kopia jest usuwana dopiero po potwierdzeniu zapisu (READY) tego samego takeId; inny takeId z serwera → kopia zostaje. Po sukcesie Quick Take pokazuje odzyskane nagranie do odsłuchu. Przy wymaganej zamianie próbki (REPLACE_REQUIRED) kopia i dzierżawa zostają do potwierdzenia albo anulowania zamiany.

Wiele kart i dzierżawa: każda operacja (upload, odzyskanie, odrzucenie) bierze wyłączną dzierżawę w transakcji IndexedDB (serializowanej między kartami). Dzierżawa trwa 120 s, jest odnawiana co 30 s przez jeden łańcuch setTimeout i nie dłużej niż 15 min od przejęcia. Każda zmiana rekordu sprawdza właściciela dzierżawy (porównanie i zapis w jednej transakcji): stara karta nie nadpisze ani nie zwolni dzierżawy nowej — dostaje LEASE_LOST. Odnowienie i zwolnienie są idempotentne; odnawianie kończy się przy zakończeniu, anulowaniu albo utracie dzierżawy. Przed finalizacją przy odzyskaniu dzierżawa jest odnawiana — jeśli przepadła, nie ma finalizacji, a użytkownik widzi „obsługę przejęła inna karta”. Odnawianie jest lokalne, więc działa też bez sieci; baner odświeża listę po online, focus i visibilitychange. Nagranie trwające w innej karcie nie jest pokazywane. Dzierżawa istnieje tylko w przeglądarce — przed duplikatem po stronie serwera chronią CONCURRENT_SESSION i idempotentna finalizacja.

PENDING_UPLOAD — serwerowe okno wysyłki (STU-16, migracja supabase/migrations/20261018120000_stu16_pending_upload_window.sql, tylko lokalnie, niewdrożona): rezerwacja PENDING_UPLOAD blokuje nowe nagrania tego samego aktora (konto albo hash gościa) tylko przez okno wysyłki 900 s liczone zegarem serwera od created_at (public.take_pending_upload_window_seconds(), w TS TAKE_PENDING_UPLOAD_WINDOW_SECONDS; równe maks. dzierżawie klienta 15 min; wartość potwierdzona przez Ownera 2026-10-18 — OD-REC-PENDING-UPLOAD-TTL). Rezerwacja jest „przeterminowana”, gdy okno minęło i w storage.objects nie ma jej pliku. Wtedy następny claim tego samego aktora (claim_take_recording_session / claim_anon_take_recording_session, w tej samej transakcji i pod tym samym advisory lockiem co finalize) oznacza ją FAILED z failure_reason = PENDING_UPLOAD_WINDOW_ELAPSED i tworzy nową; to samo robi janitor przez release_stale_pending_take_reservations(p_limit) (tylko service_role, blokada per aktor, warunek ponawiany w UPDATE). Rezerwacja, której plik już dotarł, nigdy nie jest zwalniana i da się ją sfinalizować do expires_at; READY i retencja bez zmian; limit dzienny, REPLACE_REQUIRED i inne błędy claimu cofają zwolnienie (rollback transakcji). Janitor usuwa też plik wysłany już po zwolnieniu rezerwacji. Stary takeId po zwolnieniu dostaje przy finalizacji 403 „not awaiting finalize”, więc odzyskanie robi dokładnie jeden nowy upload (bez duplikatu). SESSION_DAY_CAP: zwolnienie rezerwacji po oknie (claim albo janitor → FAILED / PENDING_UPLOAD_WINDOW_ELAPSED) nie zwraca dziennej sesji — licznik dnia UTC liczy wszystkie take'i aktora z created_at w tym dniu, niezależnie od statusu (także FAILED); przejęcie slotu to nowy claim i zużywa kolejną sesję. Ryzyko szczątkowe: upload trwający dłużej niż okno zostaje unieważniony, jeśli w tym czasie ten sam aktor rozpocznie nowe nagranie albo przejdzie janitor — kopia lokalna zostaje do odzyskania, a spóźniony plik usuwa janitor. Przed STU-16 rezerwacja blokowała do pełnego expires_at retencji (gość: 2 h), jeśli przeglądarka nie znała takeId. Gdy go zna (sprawdzone w Chromium: upload zablokowany po SESSION_CREATED), odzyskanie woła finalizację tego take'a, serwer odpowiada 403 i oznacza go FAILED, co zwalnia slot — a klient robi dokładnie jeden nowy upload i dostaje jeden READY. Klient niczego nie usuwa na podstawie wieku, nie finalizuje w ciemno i nie tworzy duplikatu: kopia ze znanym takeId idzie tylko idempotentną finalizacją tego samego take'a, a przy CONCURRENT_SESSION kopia zostaje z komunikatem „trwa inna sesja nagrania”, który podaje, po ilu minutach niedokończona rezerwacja przestaje blokować zapis. Testy: src/lib/takes/stu16-pending-upload-window-live.test.ts (lokalny Supabase, stan bazy czytany po każdej operacji) i src/lib/studio/stu-16-pending-upload-window.test.ts.

TTL i sprzątanie: kopie starsze niż TAKE_LOCAL_RECOVERY_TTL_SECONDS (24 h) oraz kopie już potwierdzone są usuwane przy następnym wyświetleniu banera (Studio lub strona beatu), niezależnie od zakresu. „Anuluj” w trakcie nagrywania usuwa kopię od razu.

Gdy pamięć jest niedostępna (tryb prywatny, brak IndexedDB, brak miejsca): nagrywanie działa jak wcześniej, tylko w pamięci karty, a panel pokazuje „Lokalne zabezpieczenie niedostępne”. Przy przekroczeniu quota niepełna kopia jest usuwana, żeby nie udawała zabezpieczonej. Utracone połączenie z bazą (inna karta ją usunęła lub podniosła wersję — versionchange, zdarzenie close, InvalidStateError) adapter otwiera ponownie raz, przy następnej operacji, bez przeładowania strony.

Błędy zapisu przy odzyskaniu: komunikaty są po polsku i bez surowych kodów: brak sieci → „Brak połączenia z serwerem… spróbuj ponownie po odzyskaniu połączenia”, pełny limit aktywnych nagrań (REPLACE_REQUIRED / ACTIVE_READY_CAP) → prośba o usunięcie lub zastąpienie nagrania, dzienny limit sesji (SESSION_DAY_CAP) → osobny komunikat, że kopia zostaje do odnowienia limitu (najdłużej do TTL kopii) albo odrzucenia. We wszystkich tych przypadkach lokalna kopia zostaje.

Ograniczenia przeglądarek: przeglądarka może usunąć dane IndexedDB (czyszczenie danych, presja miejsca, Safari ITP po 7 dniach bez wizyty). Ostatnie ≤ 250 ms przed awarią może przepaść. popstate (Back/Forward) nie da się przechwycić — zamiast blokady historia działa normalnie, a przerwane nagranie zostaje do odzyskania. IndexedDB nie gwarantuje przetrwania danych — kopia lokalna to zabezpieczenie „best effort”, a jedynym potwierdzeniem zapisu jest READY z serwera. Zweryfikowano tylko w Chromium (390×844 i 1440×900; syntetyczne źródło audio lub systemowy „Miks stereo”, nie fizyczny mikrofon): przeładowanie w trakcie, odrzucenie z potwierdzeniem i Escape, brak sieci, PENDING_UPLOAD, długi upload z trzykrotnym odnowieniem dzierżawy, druga karta (BUSY, bez przycisków), guard wyjścia. Safari i Firefox nie zostały sprawdzone.

Diagnostyka: DevTools → Application → IndexedDB → brd-take-recovery (records: status, chunkCount, byteSize, claim, upload.stage — bez treści audio). W DOM: data-recording-phase, data-testid="take-local-safety" (data-state), take-recovery-banner (data-surface), take-recovery-item (data-kind), take-recovery-notice. Komunikaty błędów nie zawierają tokenów ani podpisanych URL-i; do zgłoszeń nie dołączaj fragmentów audio ani cookies.

Komunikaty UI: aktywne nagrywanie · zabezpieczone lokalnie · wymaga odzyskania · przesyłanie w toku · zapis potwierdzony · błąd zapisu · odzyskanie niemożliwe.

Testy: src/lib/studio/stu-14-recording-recovery.test.ts (scenariusze STU-14 1–25 i kontrakt formatu) oraz src/lib/studio/stu-15-recovery-lease.test.ts (Quick Take, dodatkowe scenariusze odzyskiwania 21–25 ze specyfikacji STU-15, dzierżawa 26–36 na fałszywych timerach, sieć / wiele kopii / TTL / odrzucenie / limity 37–43) oraz src/lib/studio/stu-15-recovery-idb.test.ts (ponowne łączenie adaptera IndexedDB na deterministycznej atrapie). Wspólny magazyn w pamięci zamiast IndexedDB: src/test/take-recovery-memory-store.ts; bez mikrofonu i sieci.