`docs/testing/e2e/limitations.md` is the index a reader consults to decide whether an e2e row's blocker is theirs to lift. Several of its entries do not hold against source. Each item below was checked by reading the code it cites, at branch tip `2f3c0c629` (off `sahmed/e2e-caproni-authz`). Two are material, because a docs-only fix misses part of each. ## 1. The classic-image-store entry is fully stale, and the same false rationale is duplicated outside `docs/` `### A docker daemon on the classic image store cannot push here at all` says the registry refuses a chunked `PATCH` carrying no `Content-Length` with `400 SIZE_INVALID`, "the headers alone decide it". It does not. `resolveChunkRange` returns `streamedChunk(offset), true` when there is no `Content-Range` and `ContentLength < 0`: - `internal/format/oci/upload.go:1537-1539` - `TestUploadPATCH_ChunkedTransferEncodingAccepted` drives exactly that framing (`internal/format/oci/upload_chunked_test.go:30-32`) - the fix is `6230e110a` *"fix(oci): accept streamed blob bodies on PATCH, PUT, and single POST"*, confirmed an ancestor of `origin/main` [#1021](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/1021), which the entry names as what would lift it, is closed `workflow::complete`. **The part a docs-only fix misses:** the same false rationale is duplicated as a CI comment at `.gitlab/ci/e2e-caproni-base.gitlab-ci.yml:54-62`, which states it as the reason `DOCKER_DRIVER: overlayfs` is set. Both copies need the edit. **One thing this does not settle,** and the entry's replacement should say so rather than assert the opposite: whether moby's classic push also sends a `Content-Range` on that `PATCH`. If it does, `internal/format/oci/upload.go:1576-1580` refuses it with `400 SIZE_INVALID` for *"Content-Length required when Content-Range is present"*, and the row would still fail — for a different reason than the entry gives. Settling it costs one rig run with `DOCKER_DRIVER: overlay2`, which no current job sets: that variable sits on `.e2e-caproni` at `.gitlab/ci/e2e-caproni-base.gitlab-ci.yml:63`, the base both e2e jobs extend, with no matrix. ## 2. The `*.setup.update-visibility` cells state a reason that is false `e2e.docker.setup.update-visibility` (`docs/testing/e2e/docker.md:48`) and `e2e.oci.setup.update-visibility` (`docs/testing/e2e/oci.md:43`) both say: *"closed beta is private-only, so there is no non-private visibility to flip to."* The management API accepts and stores all three values: - `api/openapi/v1.yaml:2794-2799` — the `Visibility` enum is `public`, `private`, `internal` - `internal/managementapi/create.go:234-241` — create defaults to private and accepts any enum member - `internal/managementapi/update.go:78-94` — `PATCH` decodes and applies it So the `PATCH`-flips-visibility clause is assertable today. What is absent is the second clause, that access behaviour changes accordingly. The rows may well stay `blocked`, but on the real reason. ## The rest Verified, and not claimed by any open MR: | where | claim | what source says | | --- | --- | --- | | `limitations.md:129` | the loader "ceilings [the health-check interval] below an hour" | ceiling is `remote.MaxFailureCounterScheduledInterval` = `math.MaxInt64/4` ≈ `640511h56m49s` (`internal/remote/failurecounter.go:38`, checked at `internal/config/virtualrepositories.go:483-486`) | | `limitations.md:439` | "every `size_bytes` clause of `e2e.maven.lifecycle.management-delete-storage-counters` ... settles at the reap" | false for the file-`DELETE` clause: `MavenFileDeleter.DeleteFile` returns `freedSizeBytes` as "the transaction's own last-reference report" (`internal/managementapi/file_delete.go:33`), so that delta lands on the accounting drain | | `limitations.md:922-926` | the redirect entry lists four affected rows | `e2e.npm.consume.metadata-content-type` and `e2e.npm.consume.metadata-head` also require an instance in redirect mode, and are absent. Both cells open "Against an instance whose effective delivery mode is redirect"; the rig pins `DELIVERY_MODE_PROXY` | | `limitations.md:1000-1003` | the redirect entry's `Lifted by` says an override API **and** a test-reachable object store are both needed | overstated for three of its four rows. Minting a redirect needs no reachability — `PresignGetObject` issues no request, and the size comes from Postgres (`internal/storage/pg_blobstore.go:214,227`). Only `e2e.maven.consume.conditional-get` needs the URL followed, because its client must hold the storage backend's own ETag | | the counter-cadence entry | its affected-rows list | omits `e2e.oci.remote.fill-storage-counters`, whose last clause needs a reconciliation pass to have run. `fill-storage-counters` appears nowhere in the file | ## The index is not a complete register, and it was written stale rather than left behind Measured at `2f3c0c629`, by intersecting the catalogs' `blocked`/`manual` rows with the ids named in `limitations.md`: **16 of 26 are named there; 10 are not.** The rest state their blocker in the row's own cell or its section intro. So a sweep for stale blockers has to read the catalogs too, not just this file. The ten unnamed: `e2e.docker.setup.update-visibility`, `e2e.docker.auth.ci-job-token`, `e2e.oci.setup.update-visibility`, `e2e.oci.auth.ci-job-token`, `e2e.maven.auth.ci-job-token`, `e2e.maven.lifecycle.delete-queue-unavailable`, `e2e.npm.auth.ci-job-token`, `e2e.npm.publish.attachments-first-over-quota`, `e2e.npm.consume.cold-read-slow-client`, `e2e.npm.consume.warm-read-slow-client`. The staleness is not drift. `limitations.md` was created on 2026-09-08 in `9b7f18355`, consolidating long-lived prose out of `e2e/README.md` and `docs/dev/caproni-e2e.md`; `6230e110a` was already an ancestor of `main` when the file was written. So the entries were authored against inherited prose rather than re-derived against code, which predicts recurrence on the next consolidation and makes the remedy a re-derivation pass over every entry rather than a patch to the ones caught here. ## Already claimed elsewhere — deliberately out of scope - `!2468` corrects the `sweep_interval` sub-one-hour ceiling claim and the sixty-second poll attribution in the counter-cadence entry. It does **not** touch the `size_bytes` sentence above. - `!2470` corrects the yarn `time` entry. - The two size-cap entries (`### The Maven artifact cap is not lowered on the rig`, `### The npm publish envelope cannot reach the global body cap on the rig`) and the `### The bootstrap profile can assert no emission` entry's "empty as it stands" claim are handled on an unmerged branch, per that file's rule that lifting an entry deletes it rather than rewording it. ## What a reader should do Re-derive every remaining entry against the code it cites before acting on it, and treat `Lifted by` as unverified. When fixing the classic-image-store entry, edit the CI comment in the same change.