From 144ff557b14efbbdf7a96b62c1a681d11d1b8a04 Mon Sep 17 00:00:00 2001
From: thePR0M3TH3AN <adambrettmalin@protonmail.com>
Date: Fri, 23 Oct 2026 08:54:43 -0400
Subject: [PATCH] storage-cors: record hosted Range probe audit

---
 docs/testing/storage-cors-range-audit-2026-10-23.md | 12 ++++++++++++
 1 file changed, 12 insertions(+)
 create mode 100644 docs/testing/storage-cors-range-audit-2026-10-23.md

diff --git a/docs/testing/storage-cors-range-audit-2026-10-23.md b/docs/testing/storage-cors-range-audit-2026-10-23.md
new file mode 100644
index 00000000..e47d00b0
--- /dev/null
+++ b/docs/testing/storage-cors-range-audit-2026-10-23.md
@@ -0,0 +1,12 @@
+# Hosted URL health Range fallback audit — 2026-10-23
+
+Inspected clean storage-cors HEAD 265ce4261f7c42f653ce0ac6a49da0eea16f0f66. Source and retained tests show the public playback promise for a bounded Range GET fallback is not implemented in the hosted health probe.
+
+The card-health path reaches UrlHealthController.handleUrlHealthBadge via feedCoordinator and probes candidate URLs in probeUrlList; playback calls the same controller through playbackCoordinator.probeUrl (js/app.js:5302-5305, js/app/playbackCoordinator.js:384-401,685, js/app/feedCoordinator.js:1319-1323, js/ui/urlHealthController.js:471-503). The controller sends fetch(trimmed, { method: "HEAD", mode: "no-cors", cache: "no-store", signal }) (urlHealthController.js:592-603). On network error, timeout, opaque response, or non-OK status such as 405, confirmPlayable falls back to a timed <video> load (urlHealthController.js:516-535,623-673; media queue and timeout at :321-460). That is a real media-element fallback, but the probe does not explicitly request a Range, read a bounded response prefix, or cancel a response-body reader at a byte cap.
+
+tests/url-health-head-lifecycle.test.mjs:378-405 controls HEAD outcomes for success, error, timeout, opaque and 405. Its fake fetch records the HEAD request; its JSDOM media adapter signals simulated load/error. The separate 405 mirror case at :493-505 asserts the media fallback and then a mirror HEAD. These tests preserve fallback and lifecycle behavior, but do not assert Range headers, status/Content-Range, bytes read, body cancellation, or a bounded transfer. No Range, bytes=, or Range-GET contract appears in these three URL health suites. docs/playbackService-overview.md:21-26 describes a HEAD reachability probe and playback/torrent fallback. The campaign acceptance at docs/agents/CAMPAIGN-2026-10-22.md:9 explicitly calls for a bounded first chunk/cancel and a HEAD-incompatible host fixture.
+
+Gap: current media-element fallback does not establish the promised controlled byte cap. This source/test audit does not prove the browser or origin never uses HTTP Range internally; the JSDOM transport does not observe those media bytes. No live host/network test was run. Health was tight (89% swap used at 2026-10-23T12:51Z), so no optional scratch reproduction was attempted.
+
+Possible implementation/test owner if routed: client-reliability owns js/ui/urlHealthController.js; keep js/app.js and playback coordinator read-only. Add a dedicated controlled-transport regression with an explicitly selected HEAD-incompatible response and assert bounded Range request, first-chunk byte limit, body cancellation, and live HEAD/media/mirror controls. The exact HEAD incompatibility policy and byte cap need contract routing before implementation. No source or retained test changes were authorized by this audit.
+