The sync transport, as data: how to learn the remote artifact's current version and how to fetch its bytes. Injected so syncStep is unit-testable without a network; the composition root draws one from a newS3CveSource.

Why an artifact fetch did not yield usable bytes: refused by this side (the object oversteps the configured byte cap, or the response carried no ETag to record), or not delivered at all (a transport fault, classified into the core vocabulary at the adapter edge). A value on the CveFetch channel, never an exception: the sync task's step folds it into its outcome and the schedule retries.

The byte cap's mid-stream escape hatch: cappedAt sits inside a conduit pipeline (no value channel of its own), so it reports an overstepped cap by throwing this -- confined typed exception, caught at the adapter boundary (s3Download) and folded into OsvDbTooLarge. It never crosses the CveFetch interface.

An S3-backed advisory-fetch source: the amazonka Env is built once at newS3CveSource and captured, so s3CveFetchFor yields a CveFetch per (bucket, object key, byte cap) without re-discovering credentials per mount. The runtime adapter that seals the SDK env behind the sync's transport, matching newSqsQueue; the composition shell never handles the env.

Build an S3CveSource, constructing the S3 amazonka env once (honouring the pre-parsed endpoint override) and capturing it, so every ecosystem's CveFetch shares one credential discovery.

A CveFetch against one bucket, object key, and byte cap, over the captured env.

A pass-through conduit that refuses to stream past the byte cap: the enforcement behind the source's bounded download, where the declared content length is only the fast-fail. A breach throws the confined OsvDbCapExceeded (a conduit has no value channel of its own); the adapter boundary folds it into OsvDbTooLarge.

Everything one ecosystem's sync task operates on.

What one syncStep concluded; the caller (runCveSync) logs it and decides scheduling.

One detect-download-verify-swap cycle against the last seen ETag. Total over the fetch and over verification -- a failed fetch and a refused artifact are both outcomes, not exceptions -- so the caller's scheduling is a plain fold over SyncOutcome. See the module header for the file discipline.

The task's timing: the boot burst's backoff delays and the steady poll interval, both in microseconds. The composition root ships bootBackoffDelays and the configured poll interval; tests inject tiny values.

One ecosystem's sync task: the boot burst, then the steady poll, forever.

The boot burst attempts a sync immediately and retries per the schedule's backoff until an artifact is live, so a healthy deployment is rules-engine complete within seconds of boot. It concedes early on a rejected artifact (retrying the same bytes cannot end differently) and gives up after the schedule with a warning. The proxy serves regardless, since an empty slot only ever abstains into deny-by-default, and the poll keeps trying.

A fetch fault arrives as a value in the step's outcome and is logged here; residue (a filesystem fault on the temp path, a contract escape) propagates to the supervision the composition root wraps this task in (superviseLoop), which restarts the task -- it simply resumes from the remote artifact. notifyFirstSync runs after each successful swap (its consumer, the readiness signal, is an idempotent one-way flip).

The shipped boot-burst backoff: an immediate first attempt, then retries after each of these, then the burst concedes and the steady poll takes over. Constants by design; the poll interval is the operator-facing knob.

The boot-burst backoff schedule compiled to a Control.Retry policy: the n-th retry waits the n-th delay (microseconds) before it, and the policy stops (yields Nothing) once the list is spent, so the list's length is the retry budget. Inspect the schedule without sleeping with simulatePolicy.