The S13 implementation plan (`docs/plans/2026-07-16-s13-virtual-remote-foundation.md`, MR !954) identified four points in the S13 spec (`docs/specs/S13-virtual-remote-foundation.md`) that need correction. The S13 Step 5 review (!1048) identified three more. The S16 container remote spec review (!797) identified one more. The plan implements the spec as written; this issue tracks the follow-up spec-amendment MR so the corrections live in the single source of truth rather than only in the plan's Research Findings and MR review threads. 1. Stale dependency rows. The Dependencies table and the paragraph after it say the S05 consecutive-failure counter and the S27 scheduled probe are "coded against an interface and stub until it lands." Both backends are now on `main` (`internal/cache/counter.Counter` and `internal/jobsriver.RegisterPeriodic`). Update the rows to reflect they are implemented. 2. Closed credential-encryption tracker. The spec cites work item #68 as the deferred credential-encryption dependency. #68 is closed and was only a documentation-guidance task; the live encryption tracker is #262. Repoint the References, Data Model, Configuration, and Resolutions references. 3. HTTP-client cover cross-reference. The Fetch section cites "security cover 11" for the per-request body-size cap override; the body-size cap is cover 13 (cover 11 is the slow-header timeout). Fix the cross-reference. 4. Single-flight follower text. Clarify that a mid-stream raw follower (one that joins after streaming has started) is served from the committed document, matching the transformed-follower path - consistent with the plan's Step 8 resolution. 5. Outbound-proxy cover claims diverge from the cited reference. The Outbound proxy section states that the resolved-address deny-list (cover 5) and DNS-rebinding protection (cover 6) "cannot be enforced" for a proxied request. The reference implementation the spec cites (`gems/gitlab-http/lib/gitlab/http_v2/`) does enforce the resolved-address deny-list under a proxy, best-effort: `UrlBlocker#validate_resolved_uri` resolves the destination and runs the deny-list, the allowlist, and `deny_all_requests_except_allowed` against the answer, relaxing only DNS-rebinding protection (`dns_rebind_protection &&= !proxy_in_use`). Only cover 6 is genuinely voided by a proxy. The section is also silent on what happens to `outbound_allowlist` and `deny_all_except_allowed` under a proxy, neither of which is one of the 14 numbered covers - so a reader cannot tell that `deny_all_except_allowed: true` stops restricting destinations once a proxy is configured. Scope the disabled-cover claim to cover 6 and describe destination validation under a proxy. Identified in the !1048 review, which implements destination validation under a proxy to match the reference. 6. Decompression cap scope. Cover 14 says the decompression cap "default matches the body cap", while cover 13's body cap is sized per request type. The wording leaves it ambiguous whether the decompression bound is per-type or a single global number, and a global reading lets a metadata request bounded at `body_size_cap_metadata` stream up to `decompression_size_cap` decompressed. State explicitly that the decompression bound follows the effective per-request body cap, with `decompression_size_cap` as the global ceiling. Identified in the !1048 review and implemented there. 7. `outbound_allowlist` entry grammar. The Configuration section describes the field only as "Trusted hosts/IPs (CIDR allowed) that bypass local-network blocks", and the acceptance criteria cover only allowlist mode with a bare host. The implementation additionally supports port-scoped entries (`host:port`, `ip:port`, where a port-scoped entry permits only that port and a bare entry permits every port), normalizes IPv4-mapped prefixes, and fails startup on entries it cannot enforce (malformed entries, port `0` or above `65535`, and zoned IPv6 literals). Document the entry grammar in the field description and add a port-scoped acceptance criterion alongside the existing allowlist-mode one. The configuration reference (`docs/dev/configuration-reference.md`) documents as-is behavior by charter, so it cannot serve as the normative definition of the syntax. Identified in the !1048 review. 8. `auth_status` in the behavioral-columns table and the clear-on-`url`-change rule. The S16 container remote spec adds `container_remote_repositories.auth_status` (`smallint`, `NOT NULL`, `DEFAULT 0`, values `0=unknown, 1=none, 2=bearer`) with `CHECK ((auth_status = 2) = (auth_url IS NOT NULL))`, memoizing the challenge-discovery verdict — a nullable `auth_url` meant both "discovery has not run against this upstream" and "discovery ran and the upstream needs no token", so every request against an anonymous upstream re-ran the discovery `HEAD` for the life of the remote. S13 is where the companion column already lives: its behavioral-columns table documents `auth_url` as container-only, and its credential-management rule and the matching acceptance criterion both name `auth_url` on its own in the clear-on-`url`-change behavior ("container additionally clears the cached `auth_url`"). `auth_status` has to reset to `0` under that same rule, so the rule and the criterion are both incomplete without it: a surviving `bearer` verdict leaves the row failing its own CHECK, and a surviving `none` verdict lets a new upstream that does require a token be pulled anonymously. Add the column to the behavioral-columns table as container-only, and name it alongside `auth_url` in both the rule and the criterion. This is spec text rather than code, and S16 cannot extend an S13 acceptance criterion on its own — until it lands, `docs/specs/S16-container-remote.md` is the only place the column and its reset are written down. Identified in the !797 review; the ADR-007 half of the same amendment is #30 item 10. 9. `RequestBuilder` credential lifetime. The spec says nothing about when a `remote.RequestBuilder` implementation reads the remote's stored credentials, and two landed doc comments now give opposite instructions about the lifetime of the same object. `internal/format/maven.UpstreamRequestBuilder` documents itself as "a point-in-time credential snapshot: creds is captured by value at construction, so it must not outlive a credential write. Construct one per fetch. Caching one per remote repository would keep a cleared or rotated pair reaching the upstream until the cache turned over, which is the one failure mode of this type that no signal distinguishes from normal operation." `remote.SingleFlight` requires the opposite — "construct ONE SingleFlight per remote repository, long-lived" — and it captures the `RequestBuilder` at construction, so the layer holds one builder for the repository's whole lifetime. Both rules cannot hold for a builder handed to the coalescing layer. Both slices compose the layer now, each holding one long-lived flight per remote repository — Maven inside `mavenRemoteFlights.build` in `internal/format/maven/remote_artifact.go`, and npm through `npmremote.NewFlightRegistry` in `internal/format/npm/npmremote/flight_registry.go` — and each answers the hazard in its own slice rather than at the seam: Maven leaves the capturing builder in place and puts a delegating builder in front of it that reads the credentials inside `BuildRequest`, while npm's `LiveUpstreamConfigSource` reads the URL and the bearer token from the datastore on every call. So the rule is unwritten rather than unexercised, and two slices reaching it independently by different mechanisms is the case for stating it once at the seam — nothing stops the next builder capturing again. `internal/format/oci.UpstreamRequestBuilder` is the closest model for the wording: it resolves its `Authorization` inside `BuildRequest` on every call through `UpstreamAuthenticator`, and reads the Basic pair behind the token exchange at call time too. It is not yet a third composing slice, and the two halves of that have come apart since this was written: `oci.NewUpstreamRequestBuilder` now has a production caller at `cmd/artifact-registry/wire_oci_remote.go`, but the container glue composes no flight layer at all — `RemoteOperations` builds a `remote.Fetcher` directly, which its own doc comment states and gives its reasons for. So container already reads its credentials at call time without having reached the seam that forces the question. What makes it a third composing slice is a container slice composing `SingleFlight`, not a fill merging; do not read a merged manifest or blob fill as having closed this. State the rule where the seam is specified: an implementation reads mutable credentials at call time inside `BuildRequest` rather than capturing them at construction. The seam already requires a freshly allocated request per call, so reading the current pair there costs nothing and removes the lifetime question entirely. Identified while reviewing the S16 container remote plan (!1199); until this lands, the S16 spec's Follow-ups is the only place it is written down. The premise above was corrected after the !1806 review: this item previously said nothing composed `SingleFlight` on `main`, which stopped being true when the Maven and npm remote slices landed their flights. 10. `304` probe mapping is under-specified. The spec maps an upstream `304` to `ProbeFresh`, unqualified. The implementation qualifies it: a `304` to a conditional probe (one that sent `If-None-Match`) maps to `ProbeFresh`, while an unsolicited `304` maps to `ProbeHit`. An unsolicited `304` is a protocol violation, but it is still an existence claim, and treating it as a positional failure would silently return a `404` when the misbehaving upstream is the only holder of the file. The amendment should ratify the qualified mapping. Raised by @jdrpereira from the !1153 review (S13 Step 9, Prober) — discussed in the [!1153 review thread](https://gitlab.com/gitlab-org/ops/artifact-registry/-/merge_requests/1153#note_3618501741) and originally proposed in [his comment here](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/320#note_3622100051), where it was numbered 8 before that number was taken. 11. Read-time size-cap errors are not cache-fallback transport failures. The Cache fallback section classifies the body-size and decompression caps (`ErrResponseSizeTooLarge`, `ErrDecompressionTooLarge`) in the transport-failure family, eligible for the stale-cache fallback. The implementation cannot honor that: both errors are raised during a body `Read` — never returned from `UpstreamDoer.Do` — so they never reach Fetch's single post-send wrap site and never carry the transport marker the ratified positive, fail-closed `fallbackEligible` classification requires. They are a policy rejection of content the upstream successfully served, not upstream unreachability; a cap tripping inside the fill surfaces as `ErrCacheFill`, which is deliberately non-eligible. Amend the cache-fallback rule to name the read-time cap class a deliberate exclusion from the fallback family. Ratified in the !1290 review (raised by @sylviashen in [this thread](https://gitlab.com/gitlab-org/ops/artifact-registry/-/merge_requests/1290#note_3643011104)); the code-side doc correction landed there as d0f69b62 (`fallbackEligible` doc and `errors.go`). 12. `scheduled_interval` bounds. The Configuration section documents `scheduled_interval` (default `5m`) with no bounds, while the loader rejects non-positive values and anything at or above one hour: the sweep worker's per-kind timeout override equals the interval, and at one hour or more it collides with River's stuck-job rescue window, so a live sweep could be rescued mid-run and re-fired as a duplicate. Ratify the `(0, 1h)` bound in the spec's configuration table. Introduced in the !1279 review (S13 Step 15, scheduled sweep), where the loader validation (`internal/config/virtualrepositories.go`) and the as-is constraint text (`docs/dev/configuration-reference.md`) landed; the spec is the remaining place the bound is not written down. Per the CLAUDE.md guardrail, open the spec-amendment MR with status Approved (not Draft). Related to !954, !1048, and !797.