# Device autosave investigation — 2026-10-09

## Result

No old=saves/new=does-not-save transition was reproduced. No product fix or breaking commit is justified by the available evidence. The interrupted run's commit b59fc72 already supplied the real-server harness, policy tests and phase comparison results; this continuation retained them and reran verification.

The tested current frontend is the Phase 5 snapshot 21c1273 (parent of b59fc72), matching the requested regression scope. The shared `main` reference advanced during other queue work; this investigation did not change branches or incorporate those changes. Historical `autosave-main.json` represents main when the earlier run executed, not the subsequently advanced reference.

## Exact behavior

Both b77938a and Phase 5 have the same on-open gate: `saveBeforePlay:true`, video mode, no `preferStream`, web OPFS supported, and no existing saved copy. Save before playing defaults false. Audio-only and explicit streaming bypass the save. Successful saves become the playback source; failed saves fall through to streaming.

Creating a playlist with a video or adding a video to an existing playlist calls `preload()` directly, including when autoPreload is false. On launch, autoPreload:true tops up playlists; pinned playlists top up even with the setting off. Enabling Auto-save through Settings persists the flag and starts playlist saves. The labels describe different policies; opening an arbitrary video with defaults never automatically saved in the old build either.

References: frontend/app.js:2328 (on-open gate), :1946 (playlist policy), :1952 (pinned policy), :7107 (create playlist); frontend/views-core.js:1119 (Settings handler).

## Evidence

Fresh continuation commands:

```sh
node perf/autosave.mjs --allow-unsupported-webkit --out perf/.tmp/autosave-recheck-current.json
node perf/autosave.mjs --frontend perf/fixtures/shell-1175f1a1d2c1 --asset-hashing 0 --asset-sync 0 --allow-unsupported-webkit --out perf/.tmp/autosave-recheck-old.json
node --test frontend/*.test.js
(cd server && bun install && bun run test)
```

Each build passed all 12 scenarios per engine. Chromium stored a complete real three-second H.264/AAC file, marked cachedIds and displayed it in Saved in all eight positive scenarios; the four negative scenarios did not save. Excerpts from both runs:

```text
chromium open-default: PASS saved=false
chromium open-save-first: PASS saved=true
chromium playlist-add-setting-off: PASS saved=true
chromium settings-save-first: PASS saved=true
webkit settings-save-first: PASS UI/save guard only; OPFS unavailable
```

The Chromium settings-save-first scenario logged `Cannot read properties of null (reading 'addEventListener')` on both old and current builds despite completing the save. Assertions passing do not mean error-free UI; this shared error is a follow-up, not a newly introduced save failure.

Linux Playwright WebKit has no native OPFS: its 12 passes establish UI/settings and capability-guard behavior only. No storage shim was used, and a genuine WebKit save remains unverified. The harness exits 2 without the explicit unsupported allowance. Thus the requested old/new/fixed comparison and a regression test failing on the allegedly broken build cannot honestly be supplied.

Existing committed evidence under perf/results/autosave-*.json: Chromium Phase 1/2 all 12 cases, Phase 3/4/5 six positive cases, and both rollback flags six positive cases all passed. No failing phase tip exists in those runs. Frontend policy tests cover settings/pinning, duplicate saves and failed/paused saves remaining retryable.

Continuation suites: 201 frontend tests passed; server 124 passed, two permitted worker failures due to Python ModuleNotFoundError: No module named yt_dlp. No other server failure.

## Neighbor audit and iPhone follow-up

Downloads, Saved, OPFS and download actions remain eager core assets. Export awaits feature:export; Share/External use the lazy facade. DirectMedia.hasSource returns false before its lazy module starts, which can select a server source instead of a paired source. P2P counts can initially appear empty before delayed startup. Neither was shown to prevent a server save.

No runtime code changed; download bytes and startup behavior are unchanged. On the installed iPhone, verify the running build, Save before playing, audio-only and auto-save settings, then open a fresh video and separately add it to a playlist. Capture Downloads failure details, available storage, and Saved after relaunch/offline playback. Native iOS OPFS, quota/eviction and suspension during download require that device. A failing native sequence is needed to identify and fix the reported regression.