Part of #1046 — **`repositories.last_updated_at` and `repositories.downloads_count` each have a writer on one format only**. Both columns get a production writer on the hosted paths the specs say move them, and those writers are reassigned from S18 to this work. The two read paths the plan does **not** reach are container remote (S16) and npm remote (S15); both stay with [#292](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/292). **References:** [repository-column-writers plan](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/main/docs/plans/2026-09-03-repository-column-writers.md) (see "Step 4"). Line-number citations for the symbols below are pinned in the plan; this item names files and symbols only, so it does not go stale as the tree moves. **Type:** `feat` | **Depends on:** Step 1 (the spec amendment defining the npm event) | **MR:** none yet ## Blocked on Open Question Q1 The third repository-keyed family carries `downloads_count` and nothing else, while `counterbuf.Family.Fields()` is two slots wide and both `Buffer.Increment` and `Buffer.Merge` iterate the whole array. The plan's **Open Questions** states the two routes: pair `downloads_count` with a second repository-level counter, or add a skip-empty leg to both scripts. While Q1 is unanswered this step cannot be implemented, because the second route edits the shipped script path S22 owns and the choice is not this plan's to make alone; once the S22 pipeline's DRI rules on it, together with #292, the chosen route fixes the `Family` constant and its `Fields()` arm and the step opens. The sub-decision is recorded as a note on [#292](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/292) rather than as a work item of its own, because a new number is warranted only when it changes who does the work or when it lands, and this changes neither. ## Scope Stand up the third repository-keyed counter family the coalescing ruling takes, its drain and its write-back, and give npm's delivery-gated download path the first increment that feeds it. **Accepted scope smell:** this step spans `internal/accounting`, `internal/accounting/counterbuf`, `internal/datastore` and `internal/format/npm`, which is wider than one package. It is named rather than left for a reviewer to rediscover. Splitting the family from its only producer would land a family nothing writes beside a drain with nothing to drain, so neither half is reviewable alone; the step stays whole and its **Tests** list is what bounds it. ## Files - `internal/accounting/counterbuf/keys.go` (Modify) — the `Family` constant, its `Fields()` arm, its `known()` arm, the dirty-set key constant, and the `DirtySets.Key` arm. The `Family` doc comment saying "the two families are the two accounting scopes" moves with them. - `internal/accounting/counterbuf/keys_test.go` (Modify) — `TestFamily_Fields` pins `counterbuf.Family("downloads_scoped").Fields()` as the zero array, so that assertion moves with whatever the family is named. - `internal/accounting/emit.go` (Modify) — an emitter method for the new family. `EmitRepoCounters` takes its deltas as named scalars, so this is a new method rather than a widened one. - `internal/accounting/chunk_worker.go` (Modify) — a third River worker and its job-args type beside `RepoChunkWorker` and `NamespaceChunkWorker`; two `CounterDrainStore` methods, a baselines read and an apply, since the apply rather than `resolve` is where the write-back runs; and the worker's River registration. The interface's doc comment also records that this family's apply carries no baseline guard. - `internal/accounting/drain_trigger.go` (Modify) — a third trigger worker, its args and its tick plan, beside `RepoDrainTriggerWorker`, `NamespaceDrainTriggerWorker`, `repoTickPlan` and `namespaceTickPlan`. Without it the family is a write-only sink. - `internal/accounting/register.go` (Modify) — the third trigger's `RegisterWorker` and `RegisterPeriodic` entries, beside the existing pairs. - `cmd/artifact-registry/wire_accounting.go` (Modify) — the two new kinds in `accountingRiverKinds()`. - `internal/datastore/counter_drain.go` (Modify) — the family's baselines read and its apply, beside `lockRepoScopesStmt` and `applyRepoDeltasStmt`. The apply does **not** carry the `AND r.last_reconciled_at = v.baseline` leg. - `internal/accounting/chunk_worker_integration_test.go` (Modify) — an `ElementsMatch` over exactly `{"repo_scoped", "namespace_scoped"}` for the bail counter's `counter_family` label, under the message "must carry exactly one series per counter family". `ElementsMatch` pins the pair exactly, so a third family that can bail reddens that assertion, which is what shows the enumeration is load-bearing rather than decorative. - `internal/accounting/metrics.go` (Modify) — `metricLabelFamily`'s doc comment says the label admits "the two `counterbuf.Family` constants the cardinality audit pins", so the third family moves that claim and the audit entry behind it. - `docs/dev/observability.md` (Modify) — three lines each pin `counter_family` to `repo_scoped` or `namespace_scoped`. The `counter_emits_total` row needs more than widening: it tells on-call to read the `dropped` series "as a rate of losses that heal rather than of losses that stay", which is **inverted** for this family, because no pass recomputes `downloads_count`. For the third family a `dropped` sample is a loss that stays and does warrant action, and the row says so per family rather than once. - `docs/dev/storage-accounting.md` (Modify) — three obligations in one file. **The family enumerations:** the dirty-set key table carries one row per family, so a third family adds a third row; the sentence reading "`<family>` is `repo_scoped` or `namespace_scoped`, and `<member>` is `<namespace_id>:<repository_id>` or `<namespace_id>`", where only the family clause is falsified, since a repository-keyed third family's member is already `<namespace_id>:<repository_id>`; and the `counter_family` label enumeration. `grep -n 'repo_scoped'` at the plan's basis returns exactly these three sites, which is what closes the set. **The inverted heal claim:** the shed arm's drop described as "a rate of losses that heal at the configured `reconciliation_interval`, rather than a rate of permanent ones", the same inversion `docs/dev/observability.md` carries; `git grep -c 'losses that heal'` returns those two files and one hit each, so the pair is the whole set and fixing one is what reopens the finding. **The out-of-scope bullet:** the sentence saying download tracking "can reuse this pipeline's mechanism for `downloads_count`, which is additive like every field here". This plan does not reuse the mechanism, it adds a family to it, so the bullet either moves or says this plan supersedes it — named because a reader checking whether `downloads_count` belongs in this package lands on it first. - `internal/format/npm/counter_emit_dispatch.go` (Modify) — `meterCounterEmit` hard-codes `colRepositorySizeBytes`, and that constant's own comment says it "labels every counter-emit outcome; a rate under it is never a byte total". Once this step dispatches a `downloads_count` emit through the helper, a shed or panicked npm download increment books under `column="size_bytes"`. The helper takes the column, the same widening Step 5 makes to OCI's copy, and the download arm adds a sixth `counterEmitSite` value. - `internal/accounting/emit_drop_log.go` (Modify) — the `dropLogFamilies` catalog, whose own comment says "a new `counterbuf.Family` reaches it from here". `newDropLogLimiter` allocates one slot per (family, reason) pair over that catalog, so a catalogued family gets one slot **per reason**. A family absent from it gets no slot of its own: `allow` falls through its `!ok` leg to the shared terminal `unknown` slot. The absent family is therefore **over**-rationed rather than unrationed — every drop reason collapses onto that one slot, so the family gets at most one record per window across all of its reasons, and shares even that with any other out-of-catalog key. The nil-receiver leg is a different case, reached only when the limiter itself is nil. - `internal/datastore/repositories.go` (Modify) — the format-neutral `downloads_count` write-back beside `MarkRepositoryLastUpdated`, taking an `n int64` delta rather than `MavenRepositoryStore.BumpRepoDownloadCount`'s fixed `+1`, and carrying the same guards, the `soft_deleted_at IS NULL` leg that method already has, and its `RowsAffected` contract. - `internal/datastore/query_names.go` (Modify) — the query name. - `internal/format/npm/counter_emitter.go` (Modify) — a third method on the `CounterEmitter` interface, and a download-handler option beside `WithCounterEmitter`, which today wires the emitter onto the **publish** handler only. - `internal/format/npm/download.go` (Modify) — the emit beside `bumpLastDownloaded`, under the existing `deliveryModeNone` gate. - npm composition root (Modify) — `cmd/artifact-registry/` wires the emitter onto the download handler, derived at implementation time from the publish handler's existing wiring. **Shared seams:** `internal/datastore/repositories.go` and `internal/datastore/query_names.go` are both edited by !2268, which reworks `MarkRepositoryLastUpdated` in the file this step adds a method to. `internal/datastore/repositories.go` is a three-step seam inside this plan as well: Steps 2 and 3 each carry it for a doc-comment edit. **Which cap this occupies.** This step takes **no** npm `bufferedUpdate` label and no npm quota, because the increment travels on the accounting pipeline rather than on npm's per-format async helper, so npm's single 64-slot `bufferedUpdateMaxInFlight` gains no occupant and the publish path's `last_updated_at` writes keep their share of it. Routing the bump through `bufferedUpdate` instead would have let a download flood shed the very publish writes Steps 2 and 3 exist to make work. The cap it **does** occupy is npm's counter-emit dispatcher, whose `counterEmitSem` holds 64, beside the publish path's own emits. That name is not unique to it: the same name and the same 64 are carried by the copies in `internal/format/oci` and `internal/format/maven`, each over its own package-local `counterEmitMaxInFlight`, so `git grep -n 'var counterEmitSem' -- internal` returns one per format package and reading any of them as a single service-wide cap is the error. Three identical pairs across three packages is the duplication [#559](https://gitlab.com/gitlab-org/ops/artifact-registry/-/issues/559) tables; no step here adds a fourth. ## Acceptance A delivered npm tarball GET books exactly one increment into the buffer. A HEAD, a 304, a 404, and a stream that ends short of the declared length book none, which the existing `serveBlob` classifier already decides by returning `deliveryModeNone`. A soft-deleted repository is skipped at the write-back. One drain tick over a repository holding N buffered increments issues exactly one `UPDATE` adding N: that is the property coalescing exists to deliver, and the one a per-read writer cannot have. **Observability acceptance:** a shed or panicked npm download increment meters under its own column rather than `size_bytes`, so an operator can tell a lost download increment from a lost byte delta; and `docs/dev/observability.md`'s `counter_emits_total` row tells on-call that a `dropped` sample on this family is a loss that stays rather than one that heals. This step adds no `result="ok"` arm, for the reason Step 5 gives. ## Tests - Existing: `TestFamily_Fields`, whose `downloads_scoped` assertion moves with the family's name. - Existing: diff the rest of that suite for subtests that enumerate the families as a closed pair, rather than only adding cases beside them. The dropped-subtest failure mode is what this bullet guards. - New: the family's key builders, its `known()` membership and its dirty-set key, mirroring the existing per-family cases rather than writing a twin. - New: one increment per delivered download, and no increment for each `deliveryModeNone` cause the classifier names. - New: the write-back's argument guards and its soft-deleted no-op, mirroring `TestMavenRepositoryStore_BumpRepoDownloadCount_ArgumentGuards` rather than writing a twin of it. - Integration: N buffered increments drain to one `UPDATE` of +N, beside the existing single-increment case in `internal/datastore/maven_repositories_integration_test.go`. ## Log volume under a brownout A refusing Redis costs one `Warn` per (counter family, drop reason) per `dropLogWindow`, which is one minute, rather than one record per dropped emit. That ration is why this step's log cost does not scale with download rate, and it is why the step adds the new family to `dropLogFamilies` rather than leaving it to the fail-open leg. Worth stating because `internal/logging`'s sampler acts only on records carrying the `access` message, so these records are **unsampled** and the figure quoted here is the figure that reaches the pipeline.