No unit test asserts that CodeGen loads persisted validators under --no-ai — the same regression has shipped twice

Start at packages/CodeGenLib/src/Database/manage-metadata.ts:5481 and inspect how the emitValidators predicate queues validators. Use the ManageMetadataBase stubbing patterns in src/tests/entity-subclass-codegen.test.ts and src/tests/idempotency/generated-code-sql.test.ts. Done means a test with skipDBUpdate true and ParseCheckConstraints disabled verifies a validator is queued and runValidationGeneration is called with generateNewCode false.

The gap

mj codegen --no-ai silently deleting every committed Validate() override has now shipped twice, and there is still no unit test asserting the behaviour.

The current predicate (manage-metadata.ts:5481):

const emitValidators = skipDBUpdate || ag.featureEnabled('ParseCheckConstraints');

That single line is the whole of #4372's fix, and #4370 fixed the other half of the same regression. Neither PR added a test. From #4372's own description:

Both times that regression shipped, the log said exactly this line and nothing else.

A defect that has regressed twice, silently, with the success log reporting ✔ either way, is the canonical case for a cheap direct assertion.

Why the drift gate is not sufficient on its own

The CodeGen drift gate does catch it end-to-end, which is why #4372 was approvable without this. But as the only guard it has two weaknesses:

1. It needs Docker, SQL Server, 78 migrations and roughly ten minutes, so it cannot run in the fast unit tier.
2. It is the mechanism that locked in the loss last time. While the committed artifact had 0 validators, the gate required that output — restoring the 56 overrides failed CI and deleting them passed. A gate that compares against a committed artifact cannot tell you the artifact is the thing that is wrong.

A unit test at the predicate has neither property.

Suggested shape

With skipDBUpdate = true and ParseCheckConstraints disabled, a validator must still be queued — and runValidationGeneration must be called with generateNewCode = false, which is what keeps the LLM out of the load path.

The fixture pattern already exists in the package: src/__tests__/entity-subclass-codegen.test.ts and src/__tests__/idempotency/generated-code-sql.test.ts both stub ManageMetadataBase.

Worth red-proofing against the pre-#4372 predicate, so the test is known to fail without the fix.

Origin

Found reviewing #4372.