Problem

The Catalog and Routing team is migrating sharded-cluster integration tests out of jstests/sharding/ (ShardingTest-based suites) toward the JS core ecosystem (jstests/core/, jstests/core_sharding/, jstests/noPassthrough/). The migration is tracked under SPM-3835 and the placement rules are documented in the internal handbook "Migrating from sharding suites to the JS core ecosystem".

Today the rule is only social. New tests still keep landing under jstests/sharding/ because nothing enforces it, which slows down the migration and adds maintenance cost to a suite the team is trying to retire.

Proposed solution

Add a CI guardrail that fails any PR which introduces a new .js file under jstests/sharding/. Modifications, deletions, and intra-directory moves of existing tests remain allowed so that ongoing cleanup and reorganization is not blocked. The error message points contributors at the migration handbook and the recommended target directories.

Existing tests under jstests/sharding/ are grandfathered: the check runs against the PR's diff, so files already in the tree are not flagged.