Why Service-Worker Refusal Is Better Than a Quiet Bypass

Scope: Engineering or methodology note based on a September 17, 2026 snapshot. Source-level behavior is not a public availability or universal compatibility claim. Any scenarios are illustrative, not customer outcomes.

A service worker can affect how a page obtains resources and behaves across navigations. A capture system should not quietly neutralize that behavior and then claim it observed the same application under equivalent conditions.

The current KodeCapture floor treats service-worker support as outside its admitted path. The source includes probing and explicit unsupported behavior rather than treating a silent bypass as a successful capture.

Changing the environment changes the question

Imagine a synthetic application whose service worker serves cached resources or controls an offline transition. Disabling that worker may make acquisition easier. It can also remove the very behavior the operator wanted to preserve.

A tool needs an explicit policy for that case. It should not silently run a different application environment and keep the same completeness claim because the entry page still rendered.

A refusal fixture is useful coverage

Korpus contains source-owned capability examples, including service-worker-related refusal pressure. The existence of such an example is not a product support announcement. It can demonstrate the opposite boundary: the current tool should recognize that it cannot make the intended claim.

That is an important distinction when reading a corpus inventory. A fixture count describes test material, not a list of universally supported browser features.

Future support needs its own contract

A broader service-worker path would need clear evidence about registration, control, resource provenance, lifecycle, and the replay behavior that matters to the declared journey. Those are proposed acceptance questions, not current delivery commitments.

The frozen Ushman research may inform the design, but it does not automatically qualify a Kalu implementation. The product owner needs to establish the current integration and failure behavior.

This article describes a current limitation, not a workaround guide. Operators should not interpret the limitation as an instruction to bypass application controls or broaden acquisition without authorization.

For an evaluation, ask whether the captured environment preserves the behavior relevant to the maintenance objective. An explicit unsupported result can protect that objective better than a smooth capture that quietly removed the difficult part of the application.