Build the shared `internal/virtual` **collection mode**: the foundation seam that asks every eligible upstream for its document, records each position's outcome, and settles one aggregate verdict over those records. Plan: `docs/plans/2026-09-04-virtual-collection-mode.md`, added by [!2357](https://gitlab.com/gitlab-org/ops/artifact-registry/-/merge_requests/2357). Six steps, and each step MR's title ends with `(S13 collection mode plan: <step>/6)`. The plan's `## Status` table is the single writer for the step MR references. The Spec Reference is [S13](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/main/docs/specs/S13-virtual-remote-foundation.md), which owns `internal/virtual`. S13 did not describe a collection mode when this issue was filed; `0ed9f263d` (!2414) added its [Collection mode](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/main/docs/specs/S13-virtual-remote-foundation.md#collection-mode) section, so the owning spec now carries the contract. The behaviour is specified twice, in the two merged consumer specs that book it: S30's `### Package-level metadata merge` and S31's `### Cross-upstream packument merge`. S32 carries the same shape for container, with its amendment open as [!2240](https://gitlab.com/gitlab-org/ops/artifact-registry/-/merge_requests/2240). ## Why this is not part of #290 The seam is format-blind and serves S30, S31 and S32, so it is built once rather than three times, which is what #266's "Shared seam" item asks for. It sits upstream of S31's Step 13 (#894): that step's dependency row in `docs/plans/2026-08-21-s31-npm-virtual.md` names the shared collection mode alongside Steps 8 and 12. Parsing, merging and serialising a document stay with each consuming slice. ## Steps | # | Step | Issue | | --- | --- | --- | | 1 | per-position outcome vocabulary | #1244 | | 2 | the collection verdict | #1245 | | 3 | the health gate marks instead of excluding | #1246 | | 4 | the collection entry point | #1247 | | 5 | per-position cache fallback and the veto arm | #1248 | | 6 | the per-position wait bound | #1249 | ## Gates Each of these is a person or an MR rather than an ambiguity in the behaviour, which S30 and S31 both specify. - **The S13 spec amendment** stating that the foundation owns the collection mode. It gated Step 1's MR rather than the plan MR, so the plan merges first and the amendment's reviewer reads the shape being ratified. It merged as `0ed9f263d` (!2414), so this gate is closed and Step 1 may open. - **`resolution.position_wait_timeout`'s key name and default value**, owed to the S13 DRI, gating Step 6 alone. While the DRI has not set them, Step 6's MR may not open; once they are set, Step 6 waits on Step 4 only. The plan's `## Dependencies` carries the range the DRI chooses inside: below `request_total_timeout`'s `30s`, with `ceil(N / probe_concurrency)` waves of the bound fitting inside `resolve_timeout`. - **`resolution.negative_cache_ttl`.** `S31-npm-virtual.md:85`, read at `dbf8b383f`, makes the S13 DRI ratifying **both** keys a gate on the step MR that implements collection, and this plan books only the wait bound. The negative cache needs its own plan for the in-process LRU, its ceiling and its eviction. While no plan owns the key, S31's Step 13 part 2 stays gated on it. This plan reads that `:85` gate as reaching S31's own step rather than this plan's Step 4; a reviewer who reads it as naming Step 4 should raise that before Step 4 opens, because it would add a second key to Step 4's gates. - **`ResolveTimeout` on `remote.ResolutionConfig`.** Step 4 reads it, Step 6 reads it, and Step 5 waits on it through Step 4, so while the field is undeclared none of the three may open. Whichever of S32's Step 11 and #1139 declares it first closes the gate for all three. Checked on 2026-09-10 at `9a4c10b0c`: no symbol named `ResolveTimeout` exists under `internal/remote`, S32's Step 11 books the declaration in `docs/plans/2026-08-27-s32-container-virtual.md` and has no MR, and #1139 has no MR either. The configuration key `virtual_repositories.resolution.resolve_timeout` is a different surface and already landed under #1069; the Go field on the struct is the part still missing. ## Merge order !2357 merged, so step MRs may open under the plan-before-code guardrail. Step 3 merged as !2422 and #1246 is closed. Of the five steps left, Step 1 is the only one with no dependency inside the plan. The rest form a chain rather than parallel tracks: - **Step 1** (#1244) may open now. Its S13 amendment gate is closed. - **Step 2** (#1245) waits on Step 1. - **Step 4** (#1247) waits on Steps 1, 2 and 3, and on the MR that declares `ResolveTimeout`. - **Step 5** (#1248) waits on Step 4 alone. - **Step 6** (#1249) waits on Step 4 and on the S13 DRI's ratification of `position_wait_timeout`. So Steps 5 and 6 are the only pair that can run at the same time, and only once Step 4 has landed and the DRI has set the key. Steps 1 and 2 cannot: Step 2 reads the vocabulary Step 1 adds. Step 3 and Step 6 are this plan's two editors of `internal/virtual/resolve.go`. Step 3's order against S32's Step 10a was "either, and whichever lands second rebases"; Step 3 merged first, so S32's Step 10a is the one that rebases. Step 6 is ordered behind whichever MR declares `ResolveTimeout`. Other branches outside this plan also edit `resolve.go`, and no pipeline reports that overlap, so run `git diff --name-only main...HEAD` against the open MRs before opening Step 6. Related to #266.