Bound last_health_status on the npm and Maven remote-repository tables

Problem

last_health_status is the only enum-style smallint column in the schema with no range CHECK. It appears on all three remote-repository tables:

Table	Migration	Bound
npm_remote_repositories	20260716120000	none
maven_remote_repositories	20260728120000	none
container_remote_repositories	20260804120000	CHECK (last_health_status IN (0, 1, 2))

Every other enum-style column in the schema is bounded — repositories.format, repositories.kind, repositories.visibility, namespaces.delivery_mode_override, npm_metadata_files.kind, npm_remote_metadata_files.kind, and now container_remote_repositories.auth_status.

The omission was never a decision. It came from ADR-007, which declares the column on all three remote-repository tables with no CHECK, and propagated into S13, S14, S15, and S16 with no plan step, acceptance criterion, migration comment, or test touching its domain. S13's behavioral-columns table is explicit where it does want a bound — the two rows above last_health_status read "Validated >= 0" and "Validated > 0" — so the silence there reads as unexamined rather than intended.

S16 bounded it on container_remote_repositories in !1275 (merged), which is why the three tables now disagree.

Proposal

Add the same bound to the two sibling tables:

ALTER TABLE npm_remote_repositories
    ADD CONSTRAINT check_npm_remote_repositories_last_health_status
    CHECK (last_health_status IN (0, 1, 2)) NOT VALID;

ALTER TABLE npm_remote_repositories
    VALIDATE CONSTRAINT check_npm_remote_repositories_last_health_status;

and the same for maven_remote_repositories.

NOT VALID then VALIDATE per database.md, though both tables are empty pre-production, so VALIDATE scans nothing and the lock exposure is negligible. No DROP is needed — neither table has an existing CHECK on the column to replace.

Scope

Two ALTER TABLE pairs in one migration, the regenerated structure.sql, and range assertions in the npm and Maven schema integration suites mirroring TestContainerRemoteConstraints_LastHealthStatusRangeCHECK — all three defined values as positive hits, plus 3, -1, 99 rejected.

Kept out of !1275 (merged) deliberately: that is a container step MR, and adding npm and Maven schema changes to it would make a single-table schema MR span three slices.

Why this is filed now rather than left implicit

!1189 (merged) hit the same shape. An AppSec finding there noted that maven_remote_packages.group_id/artifact_id accepted empty strings and that npm_remote_packages.name had the identical gap. Maven was fixed in that MR; npm was not, no follow-up was filed, and check_npm_remote_packages_name_length still carries no lower bound today. Filing this at the time the divergence is created is what stops the same outcome.

Related

• !1275 (merged) — adds the bound on container_remote_repositories
• #320 (closed) — S13 spec-text amendment naming the bounded shape as the one a later remote slice copies
• #30 — ADR-007 amendment recording the CHECK on the container block