## Ask Amend S07 and S08 for the eight spec gaps the OCI remote band recorded as Opens 5, 5a and 6 to 11 in [`docs/plans/2026-08-21-remote-conformance.md` §Spec-amendment candidates](https://gitlab.com/gitlab-org/ops/registry-conformance/-/blob/main/docs/plans/2026-08-21-remote-conformance.md). All eight are narrow. None blocks a step MR; each one forks an implementation, which is why they are filed rather than assumed. This is the OCI band's equivalent of #67, which carries the Band B three from Step 19. ## The eight **Open 5: no spec section admits the remote rows into the pluggable-behavior carve-out their hosted siblings rely on.** S07 §Pluggable behavior the spec does not pin covers `oci.blob.range-request`; S08 has no pluggable-behavior section of its own, naming the concept only by reference to S05's and to S07's. !275 narrowed this without closing it: AC #36 now says a row "can seed and *then* skip on a pluggable-behavior arm (S07 §Pluggable behavior), and that row completed", so the spec acknowledges the arm exists and that taking it still counts as establishing the fixture. What it does not say is that the arm is permitted for this row. AC #36 governs verdict accounting, not whether a `200` carrying the whole blob is conformant, so `oci.remote.blob-range`'s non-enforcing arm still rests on inference. An implementer reading only S08's cell makes that `200` a `StatusFail`, failing a registry OCI's own specification calls conformant. Narrowest fix: a sentence in S08 §Per-format rows saying the remote rows inherit their hosted siblings' pluggable-behavior treatment. It also covers `oci.remote.referrers-proxy` (Step 34) before it meets the same question against a v1.0 upstream. **Open 5a: the hosted `oci.blob.range-request` matcher accepts a `Content-Range` total the remote row requires.** `checkPartialContent` accepts `bytes 32-95/*`; `checkRemotePartialContent` requires `bytes 32-95/512`. The asymmetry is deliberate and is now stated at both sites: the remote row `GET`s the whole blob before asking for the slice, so the relay knows the complete length, which is the condition RFC 9110 §14.4's `*` allowance exists for the absence of. Open: whether the hosted row should issue a fill too and take the strengthened matcher with it. A registry that re-frames on a cold read passes the hosted row and fails the remote one against the same behaviour. **Open 6: Step 33's two departures from S08's `head-parity` row text.** S08 states the row as "returns the `GET` headers and no body". The body clause is not covered at all, because `net/http` discards a `HEAD` response's body before any caller sees it, so an assertion over it could not fail. And `Content-Length` is judged only when declared, because no RFC requires it on a `HEAD` and a relay whose cache write has not settled can omit it while behaving, so requiring it would fail such a registry intermittently. Narrowest fix for both: a sentence in S08 §Per-format rows scoping the row to the headers a client can observe and saying a `Content-Length` is judged when present. `docs/catalog/oci.md`'s row carries the wording to lift. **Open 7: S07 AC #26 and S07 §`Docker-Content-Digest` response header disagree on the by-tag basis.** AC #26 compares against "the digest known from the request path (by-digest) or test setup (by-tag)"; the response-header section says a `HEAD`'s header "repeats the digest the corresponding `GET` returns". `oci.remote.docker-content-digest` implements the second, because S08 scopes it to "the digest of the bytes served". A relay serving altered bytes under their own digest is correct about what it served, and that the bytes are not this run's is `oci.remote.pull-through-cache-manifest`'s finding. Fix: qualify AC #26's by-tag clause to the hosted rows it was written for, or say the two readings apply to different row classes. **Open 8: two S08 sites justify the OCI strict-equality flip by a row count Steps 31 to 33 made wrong.** AC #35's rationale says "OCI's section already holds `oci.remote.pull-through-cache-manifest` and `oci.remote.pull-through-cache-blob` at `not started`", and the §Downstream amendments row repeats it. Both are registered now, so the example no longer holds even though the deferral does. The replacement example this entry first offered has since gone the same way: it named `oci.remote.not-found` and `oci.remote.write-refused-blob-upload` as rows with no catalog row, and !272 authored both. Fix: restate both sites against the four `## Virtual` rows (`oci.virtual.upstream-resolution-order`, `tag-list-merge`, `degraded-upstream`, `ns-query-routing`), which are non-`optional` and which no step in either band can register until a spec defines the multi-upstream surface they describe. One clause has to travel with them or the restatement invites the opposite error: those four are the right example for "non-`optional` set larger than descriptor set" and the wrong one for "why the flip is waiting", because `inventory_test.go`'s `virtualSlugPrefix` already drops them and both directions pass today. Running those two things together is how this entry came to cite rows that then landed. **Open 9: AC #30's `n` counts settling descriptors, and `oci.remote.referrers-proxy` settles twice.** `--timeout`'s remote default is `2n × --settle-timeout + 5m`, and S08 is explicit that "the factor of two is the initial attempt plus one re-attempt, not 'settles once per such row'", so the budget allocates each settling descriptor exactly two settle-timeouts. The referrers row needs a referrer to list and the shared fixture stages none, so it seeds its own through a second `conformance.SeedAndSettle` inside its verdict, and can consume up to **four**. With the band's eight settling rows the derived default is `16 ×` and the worst case is `18 ×`, so the five-minute constant absorbs it at any ordinary settle timeout and it is not reachable today. It is still a definition that no longer matches the thing it counts, and the gap grows with every row that seeds more than one coordinate. Two fixes, and the choice is a spec decision: count *settles* rather than *descriptors that settle*, which means AC #30's counting entry point can no longer be `SelectDescriptors` alone; or require a row to settle once and push multi-artifact staging into the shared seeding contract, which wants doing before Maven's and npm's own listing rows land. Recorded rather than absorbed because a derived default that understates the work holds until a run is slow and then presents as a cancelled run rather than as a budget that was always too small. **Open 10: the Repeat read class says cache-state-dependent headers "reflect the hit", and does not say whether that is conditional.** AC #16 pins byte identity and nothing else; the class description adds the header clause. For blobs the only signal a client can read is whether `Content-Length` was declared, and both readings of the clause fail a relay that is behaving. The **unconditional** form (a warm blob read must always be length-framed) fails a relay that buffers its fill, which no specification forbids. The **conditional** form (the warm read must declare a length only if the cold one did not) fails a relay that streams its fill while committing its cache asynchronously, because its second read goes out before the commit lands, so both reads chunk. `oci.remote.repeat-read` shipped with the conditional reading in !272 and the review of !272 removed it: the row was failing chunked-then-chunked while passing length-then-chunked, though neither arrangement expresses a transition, so the asymmetry was the defect rather than the choice between readings. The clause is now asserted by **no row in any band**, and a target that never reflects a cache hit in any header passes every repeat-read row. That is a real coverage gap, and it is here rather than in a row that flakes on framing, which is what `remote_relay.go`'s `contentLengthUndeclared`, `oci.remote.head-parity` and `oci.remote.blob-range` each already decline to do. Fix: one sentence in the Repeat read class saying which reading applies. **Open 11: `oci.remote.not-found` reads a repository no row creates, which S07 says no row does.** The row is Absence class, so it seeds nothing and its repository is one the run never populates, which makes both its reads an **unknown-repository** read rather than an absent object in an existing repository. It accepts only `MANIFEST_UNKNOWN` on the manifest route and `BLOB_UNKNOWN` on the blob route. S07 §Resolutions says the two conditions differ, records that hosted AC #39 and AC #40 create an image first precisely to avoid the harder one, notes that Container Registry answers the object-level codes "whether or not the repository exists" while "the setup targets Artifact Registry, which differs", and closed with "No row asserts an unknown-repository read path" until this row landed. The same section records that "some v1.1 registries `404 NAME_UNKNOWN` on missing repos", and hosted AC #41 accepts `NAME_UNKNOWN` beside `MANIFEST_UNKNOWN` for exactly this reason, with `errCodeNameUnknown` already declared for it. So the row may be strictly narrower than the protocol admits for the condition it creates. Container Registry passes either way; Artifact Registry is the open question and `validation/evidence/step35/` is what settles it. Two separable halves: S07 §Resolutions' closing sentence is wrong as of !272 whichever way the code goes and is corrected either way (!272 does that); whether `judgeAbsence` accepts `errCodeNameUnknown` is the substantive half, and S08's cell for the row needs the same widening if it does, because "the S07 not-found codes" currently reads as the two route-specific ones. Not fixed in !272 deliberately: widening an accepted code set is loosening a conformance assertion, which `CLAUDE.md` §Critical rules puts in its own MR. ## Why one issue Six of the eight are one sentence each in S08 §Per-format rows or S07, and Opens 5 and 5a are two halves of one row. Splitting them into eight issues would spread one spec MR's worth of edits across eight threads. Opens 9, 10 and 11 arrived with !272 (Steps 34 to 36) and its review. Open 10 is the one with a behaviour change already shipped against it: the assertion it was filed about was removed, so the gap it records is currently uncovered rather than covered by a reading nobody pinned.