A raw response fetched from a registry -- the unparsed bytes of a metadata document, as returned by fetchMetadata. It is kept opaque-of-bytes here so the protocol/data plane (fetch) is separate from parsing: a parse* field turns a RegistryResponse into a domain type.

The artifact descriptor a mirror publish is assembled from: the filename, integrity digests, and declared size of the artifact the worker's ingest re-evaluation re-admitted under current policy. The worker derives it entirely from current metadata -- the queue payload carries no digest or size -- so the published document can only ever name what the shared admission gate floor-checked (see Ecluse.Core.Worker.Job).

maHashes is a NonEmpty because admission refuses a digest-less version (the integrity-presence policy), so a descriptor with nothing to verify or publish is unrepresentable by construction.

The digest value of the first admitted Hash computed with the given HashAlg, or Nothing when the artifact carries none. It reads only maHashes and consults no ecosystem, so it lives beside the descriptor: npm's publish codec picks the SRI and SHA1 entries this way to fill dist.integrity and dist.shasum.

Why parsing a RegistryResponse into a domain type failed. Parsing is the boundary that turns untrusted wire data into the proxy's precise types, so a failure is reported (not thrown): the caller decides how to respond.

Why a metadata fetch could not produce a response body, reported as a value so a read-path consumer maps each cause onto its own outcome -- the serve read adapter onto the response it renders, the worker's mirror-presence probe onto its fall-through -- rather than catching a typed throw two calls away. Total over the read fetch: an unformable request URL, a response-bound breach, and a transport fault are all in this channel, so no fetch failure rides up outside the declared type.

Why publishing an artifact to a registry failed -- a genuine write fault reported by the mirror write (mpPublishArtifact; an Queue job is then left un-acked and retried; see docs/architecture/cloud-backends.md).

This is the write-path fault and nothing more: forming the request URL is a separate concern (a UrlFormationError), so a read-path fetch can no longer surface a failure mislabelled as a publish.

Why a publish could not complete, surfaced as a value rather than thrown so the mirror worker decides retry vs. drop by an exhaustive pattern match rather than by catching (and re-classifying) an exception. The cases differ in exactly that -- retryability -- which is the whole reason this is a value: a registry rejection or a transport fault is worth redelivering, an unformable URL never is.

Why an upstream request URL could not be formed from configuration and an already-parsed PackageName.

This is a protocol-independent fault shared by every request an adapter builds -- metadata fetch, artifact fetch, and publish alike -- so a read-path failure is reported as what it is rather than borrowing the write-path's PublishError. It reports that the configured base URL is empty or the URL the adapter formed could not be parsed.

The response from the publication target after relaying a publish document. Kept in memory (no streaming) -- the relayed body is small (typically a JSON envelope and a tarball under the target's size limit), and buffering it whole lets the proxy catch and log an exception before starting a chunked response it would otherwise abandon mid-stream.

Why a first-party publish relay produced no response from the publication target, reported as a value so the serve path renders each cause directly: an unformable target URL is the operator-misconfiguration 500, and a transport fault or an overstepped response bound is the target-unreachable 502 (in both, the target's own answer never arrived whole). Total over the relay: no relay failure rides up outside the declared type.