chore(model): apply canonical MongoDB validators to Development (admin collMod)

[quntao-z]

Follow-up from #727 (part of #210 Phase 6).

The canonical validator registry now declares moderate/error for all nine canonical collections and strict/error for the six audited-clean collections (accounts, evidence_claims, org_units, research_plans, review_decisions, source_documents). See docs/canonical-model-audit-210-phase6.md.

Development currently carries no canonical validators at all (model-refactor:validators --environment development plans nine collMods). The least-privilege application credentials in server/.env cannot run collMod (user is not allowed to do action [collMod]), so the apply fails closed with nothing applied.

Task: with admin credentials that can run collMod on the Development database, follow the runbook Development dry-run and apply flow (docs/canonical-mongodb-validator-runbook.md) to apply the reviewed plan (six strict + three moderate). Verify postApplyPlan is all noop and a fresh dry-run reports writesPlanned: 0.

collMod mutates no documents and is reversible via the generated rollbackPlan.

Refs #210, #727.

[quntao-z]

Claiming this. Verified the current state: a fresh dry-run against Development with the least-privilege server/.env credentials confirms the plan is exactly what's described here and in docs/canonical-model-audit-210-phase6.md:

• 9 collMod planned, 0 createCollection, 0 noop (Development currently has no validators at all)
• 6 strict: accounts, evidence_claims, org_units, research_plans, review_decisions, source_documents
• 3 moderate: researchers, role_assignments, taxonomy_terms

No code or tooling changes are needed - model-refactor:validators (from #221/#727/#762) already generates and would apply the correct plan. This issue is purely the data operation: applying it needs Mongo credentials that can run collMod on the Development database, which the app's server/.env intentionally does not have (least privilege). I don't have separate admin credentials for the Development cluster available to me, so I can't complete the actual apply step myself. Flagging this for whoever holds Development admin DB access to run the runbook's apply command, or to hand me the admin connection string so I can run it and verify postApplyPlan is all noop.

[quntao-z]

Ran the Development dry-run and pre-apply readiness (MONGODBURL pathname /Development, host yalelabs0.ilyce1q.mongodb.net). Plan is unchanged from the claim:

• 9 collMod, 0 createCollection, 0 noop, writesPlanned 9. planFingerprint c70e9632c3bac853755c3d4576ec2bc04a2b028cfa0aa760ff50c4e2469d43b9.
• 6 strict/error: accounts, evidence_claims, org_units, research_plans, review_decisions, source_documents.
• 3 moderate/error: researchers, role_assignments, taxonomy_terms.
• rollbackPlan: 9 entries (restore-previous-validation); collMod mutates no documents and is reversible.

Re-ran model-refactor:strict-readiness against current Development: all 6 strict collections report nonConformingCount 0 / strictReady true, so the strict flips are safe against current data. researchers has 7 legacy non-conformers, which is exactly why it stays moderate (moderate grandfathers them); role_assignments and taxonomy_terms are 0.

Apply is still blocked on credentials, now confirmed by a fail-closed attempt: it stopped at the first command with user is not allowed to do action [collMod] on [Development.accounts], Applied: (none), nothing mutated. The server/.env user (ycsmaintenanceylabs) is least-privilege and cannot collMod, and no admin connection string is present in server/.env or the environment.

Handoff for the credentialed step: with an admin connection string that can run collMod on Development, re-run the runbook apply flow (fresh dry-run, then --apply --apply-from <dry-run> --confirm-canonical-validator-apply development), then confirm postApplyPlan is all-noop and a fresh dry-run reports writesPlanned 0. No code or tooling changes needed.

[quntao-z]

Investigated this from a Dev-only worker session. All read-only checks pass and the plan is safe to apply, but the actual collMod apply is blocked on credentials.

Dry-run plan (fresh, against Development): 9 collMods planned (accounts, evidence_claims, org_units, research_plans, researchers, review_decisions, role_assignments, source_documents, taxonomy_terms), all to validationLevel: strict, validationAction: error. 0 createCollection, 0 noop.

strict-readiness audit: 9/9 collections clean, 0 non-conforming documents in any of them.

reference-integrity audit: 11/11 edges clean, 0 missing-required refs, 0 orphaned refs.

Apply attempt: failed immediately and cleanly as this issue predicted:

CanonicalMongoValidatorApplyError: Canonical validator apply stopped at accounts: user is not allowed to do action [collMod] on [Development.accounts]. Applied: (none). Unattempted: evidence_claims, org_units, research_plans, researchers, review_decisions, role_assignments, source_documents, taxonomy_terms.

No partial state, nothing written. The least-privilege server/.env MONGODBURL genuinely cannot run this.

Remaining work is credential-only: someone with a Development MongoDB user that has collMod needs to point MONGODBURL at that user and rerun:

yarn model-refactor:validators --environment development --apply \
  --apply-from /tmp/ylabs-canonical-validators-development-dry-run.json \
  --confirm-canonical-validator-apply development \
  --output /tmp/ylabs-canonical-validators-development-apply.json

(fingerprint 6823daa0ae2ce957e5df565258fa149b1ef0cc508720dd68af0f1452aaba095d, matching the plan above), then confirm postApplyPlan is all noop and a fresh dry-run reports writesPlanned: 0.

[quntao-z]

Development still carries no canonical validators, so this closed as completed without the apply landing

Read directly from Development at 2026-09-23T01:25Z, after this issue was closed as completed at 2026-09-22T21:42Z:

collection	validator	validationLevel
accounts	none	-
org_units	none	-
research_plans	none	-
researchers	none	-
role_assignments	none	-
taxonomy_terms	none	-

All six canonical collections the registry declares today carry no $jsonSchema, no validationLevel and no validationAction. The last comment on this issue is from 2026-08-24 and records the apply failing closed on user is not allowed to do action [collMod], and nothing since records a successful apply. So the blocker this issue names is still the blocker, and the close hides it rather than resolving it.

Two consequences worth stating plainly, because both are the "merged but never applied" shape:

• canonicalMongoValidatorRegistry.ts declaring validationLevel: 'strict' for six collections is code, not state. No database rejects a single non-conforming write today.
• chore(model): carry canonical validator strict flips forward to Beta and Production #754 made the promotion's staging path carry a collection's validation options onto its replacement, so an applied Development flip now reaches Beta and Production through the ordinary copies instead of needing its own live-database apply. That mechanism is correct and merged, and it currently carries nothing, because there is no applied flip on Development to carry.

Nothing here needs new code. It needs a Development connection whose credentials can run collMod, then the Development dry-run and apply flow in docs/canonical-mongodb-validator-runbook.md, and a comment recording postApplyPlan all-noop plus a fresh dry run at writesPlanned: 0. Reopening is an owner call; I am recording the measurement so the state is not mistaken for done. Also noted on #210, whose validator-tightening task item this is.

[quntao-z]

Reopening: this was closed as completed, but the operation it tracks has not taken effect.

Read independently just now against Development: 0 of 25 collections carry a $jsonSchema validator. This issue's own last comment records the apply failing with user is not allowed to do action [collMod], so the close was recorded on an attempt that did not succeed rather than on a verified result.

That matters more than a tracker tidiness point, because #754 has since landed the carry-forward mechanism (PR #3033) after finding that every Beta to Production promotion was silently stripping the validator from 5 of the 6 canonical collections: rename carries no collection options, so promotion staging created without them dropped the schema. That fix is correct and worth having on its own, but what it carries forward is whatever Development holds, and Development currently holds no validator. So the two together presently deliver nothing.

What this needs, in order:

1. A database user with collMod, or an equivalent path that can attach the validator. The apply cannot succeed without it, and no amount of retrying the script changes that.
2. Re-read the collection options afterwards rather than trusting the script's exit code. The instrument is listCollections and checking options.validator.$jsonSchema, which is how this was just measured.
3. Only then is the promotion carry meaningful, and only then should this close.

Verification rule worth stating on the issue itself: an operation that reports a permissions error has not run, and a script's exit code is not evidence. The repo already records this for data repairs; it applies to schema operations too.

[quntao-z]

Re-measured: 0 of 24, and the blocker is one grant

Read from real collection options (listCollections({}, { nameOnly: false })), not from the registry declaration:

• 0 of 24 Development collections carry a $jsonSchema validator.
• 6 of 6 declared canonical collections plan a collMod, each drifting on validator, level and action, because none stores a validator at all.
• Neuter check: inverting the predicate counts 24 of 24 collections without a validator, so the zero is a real zero rather than an instrument error.

Two corrections to this issue's body. The registry declares six collections, not nine, because the claim-graph collections were retired under #2814. And the strict/moderate split is gone: all six are declared strict.

The credential in server/.env holds readWriteAnyDatabase@admin, 25 granted actions including createCollection but not collMod. A bare non-mutating collMod probe is refused with user is not allowed to do action [collMod] on [Development.<collection>].

Why this was closed while its apply had failed

The CLI did exit non-zero and did name the failed collection. What it never did was record anything at --output. The runbook tells the operator to review the apply artifact's postApplyPlan, so a stale success artifact from an earlier run stayed at that path and read as a clean apply. Reproduced: a stale success file survived a fully refused apply untouched.

#3127 fixes that and adds the drift detector:

• Every run records its outcome at --output, failures included. A failed run writes "mode": "failed" with the refusal and no applied or postApplyPlan field, and --apply-from rejects it as a reviewed plan.
• A missing collMod grant now reports every remaining planned collMod as refused, not just the first, because it is a database-wide privilege gap. Other rejections stay scoped to the collection that failed.
• yarn --cwd server model-refactor:validators-assert --environment development asserts presence against the database and exits non-zero on drift, separating validator-absent (no $jsonSchema stored at all, the promotion-stripping and never-applied signature) from validator-drifted and collection-missing.

Four new guards, each mutation-checked. Verified against the real database: the assert exits 1 naming all six collections, and a refused apply exits 1 and replaces a stale success artifact.

The one remaining blocker

The repository owner must grant collMod on the target database to the operator's database user. Nothing else is outstanding, and no code change can work around it.

Copy-pasteable, and now in docs/canonical-mongodb-validator-runbook.md under Required MongoDB grant. In Atlas: Database Access -> Custom Roles -> Add New Custom Role, name canonicalValidatorAdmin, inherit readWriteAnyDatabase@admin, add the collMod action, assign to the operator's user. Or with userAdmin on admin:

db.getSiblingDB('admin').createRole({
  role: 'canonicalValidatorAdmin',
  privileges: [{ resource: { db: 'Development', collection: '' }, actions: ['collMod'] }],
  roles: [{ role: 'readWriteAnyDatabase', db: 'admin' }],
});

db.getSiblingDB('admin').grantRolesToUser('<operator-database-user>', [
  { role: 'canonicalValidatorAdmin', db: 'admin' },
]);

Revoke after the apply:

db.getSiblingDB('admin').revokeRolesFromUser('<operator-database-user>', [
  { role: 'canonicalValidatorAdmin', db: 'admin' },
]);

Do not widen the shared application credential: collMod on a student-facing database is a privilege the running server never needs.

Apply Development only. Beta and Production receive the flips through the ordinary whole-collection copies, which carry the mirrored validation options since #754. Keep this issue open until the grant exists and the apply reports postApplyPlan all noop with a fresh dry run at writesPlanned: 0.