Build: Add file type verification for CSS and JS directories

[NoumaanAhamed]

Summary

Adds automated enforcement of file type restrictions in CSS and JS source directories. Currently, it's possible to place files with incorrect extensions (e.g., .php files) in src/wp-includes/css/, src/wp-includes/js/, src/wp-admin/css/, and src/wp-admin/js/ without any automated check catching it.

This PR introduces two-directional enforcement:

Inward Check

"These folders should only ever contain their respective file types"

Verifies that CSS directories only contain .css files and JS directories only contain .js files. Gitignored build artifacts (e.g., registry.php, *.asset.php, TinyMCE skins) are handled via an allow-list in the Grunt task only — the GitHub Actions workflow operates on a clean checkout and never encounters them.

Outward Check

"These file types should only ever be in these folders"

Verifies that .css and .js files do not exist outside their designated css/ and js/ directories within wp-includes/ and wp-admin/. Excluded directories that legitimately contain CSS/JS files:

• wp-includes/blocks/ — Gutenberg block-specific assets (gitignored).
• wp-includes/build/ — Routes/pages build system JS files (tracked).

Changes

Gruntfile.js

• Adds a verify:file-types Grunt task with both inward and outward checks.
• Wired into the existing verify:build composite task (runs during grunt build).
• Allow-list for gitignored build artifacts that exist locally after build:dev (TinyMCE skins/fonts/images, *.asset.php manifests, registry.php, CodeMirror/Jcrop/mediaelement/thickbox/imgAreaSelect bundled assets, SCSS color scheme sources, license files).

.github/workflows/file-type-check.yml (New)

• Lightweight GitHub Actions workflow using shell find commands (no npm ci required).
• Triggers on pull requests and pushes when files change in the target directories or when CSS/JS files are added anywhere under wp-includes/ or wp-admin/.
• No allow-list for gitignored files needed — checkout only contains tracked files.
• Follows existing WordPress workflow conventions: pinned action SHAs, concurrency groups, permission scoping, repository guard, slack notifications, and failed-workflow dispatch.

Testing

Test	Result
npx grunt jshint:grunt	✅ Lint free
npx grunt verify:file-types on clean codebase	✅ Passed
Inward violation: .php file in src/wp-includes/css/	✅ Detected
Outward violation: .css file in src/wp-admin/includes/	✅ Detected

Trac ticket: https://core.trac.wordpress.org/ticket/65279

Use of AI Tools

AI assistance: Yes
Tool(s): Gemini (Antigravity IDE)
Model(s): Claude Opus 4.6 (Thinking)
Used for: Initial code skeleton generation for the Grunt task and GitHub Actions workflow; codebase analysis to identify all gitignored vs tracked files requiring allow-listing; iterative refinement based on review feedback. Final implementation and testing were reviewed and validated by me.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props mohamedahamed.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.