feat: pollora:doctor and Site Health checks for silent failures

[ogorzalka]

pollora:status says what is there; pollora:doctor says whether it works, and what to run when it does not. Scoped in .claude/plans/pollora-doctor.md: a check only enters if it names a failure met in practice (or measured), is read-only, and prints its fix.

Checks

Check	Covers	Failure it names	Fix it prints
WordPress core patch	install	core still declares __() (patch skipped by composer-patches 2, exit 0); __() not Pollora's	composer patches-relock && composer patches-repatch
Composer patches lock	install	patches.lock.json missing or older than the framework's patches	same
Environment file	install	DB_NAME/DB_USER/WP_HOME not read; MySQL settings on a sqlite connection	Laravel's names
Configuration and route caches	install	config/routes cached outside production: .env/routes edits ignored	php artisan optimize:clear
Discovery cache (console)	all locations	classes added since the cache was written, named	php artisan discovery:clear
Builds	theme, plugins, modules	no theme; not built; built into another folder than Pollora reads; hot file → dev server stopped (none/502) or not exposed (404)	per case
Symlinked directories	theme, plugins, modules	linked under another name: build and site disagree on the folder	real copy / rename
Template placeholders	theme, plugins	%theme_*%, %plugin_*%, .stub left from a copied template	pollora:make:theme / pollora:make:plugin
Pattern files / cache	theme	.html or header-less files in patterns/; files missing from WordPress's cache	.php + docblock; delete_pattern_cache()
Routes over block templates	theme	Route::wp() answering in place of block templates (warning)	remove them
Blocks in the legacy folder	theme, plugins, modules	blocks in resources/blocks, which stops loading in v15 (warning)	move to resources/views/blocks
Blocks registered (Site Health only)	theme, plugins, modules	a block not registered in a web request	where to look

Plugins are those registered with pollora_register() (PluginRegistrar), modules the enabled nwidart modules. Build paths come from each asset container, or from ModuleAssetManager's own rules (new expectedAssetConfiguration()), so the check reads what Pollora reads.

Measured on the way

• A Blade view does not shadow a block template (index, single, page tried): not a check.
• A stale hot file: every asset points at the dead dev server, page unstyled. A TCP probe is not enough: DDEV's router listens on the port and answers 502 when Vite is stopped, 404 when the port is not exposed (buzz-demo: Vite answered 200 inside the container, 404 through the router). The check requests <hot>/@vite/client, as the page does.
• Found a regression from fix: enqueue Vite entries as script modules, after WordPress's import map #357 on the way: the Vite client enqueued with ?ver= — fixed separately in fix: enqueue the Vite client with no version #366.

Where

pollora:doctor (--json, exit 1 on an error) and Site Health (Tools › Site Health, "Pollora" badge), one registry of checks.

Tests

• 40 Pest tests in tests/Feature/Doctor, each failure replayed for a theme, a plugin and a module where it applies; E2E doctor.spec.ts (Site Health as an administrator).
• Real runs: buzz-demo clean; pollora-test reports two real problems: pollora-demo-plugin never built (and its vite.config.js writes build/plugins/), and both demos keep blocks in resources/blocks.
• Full suite 1359 passed; Pint, PHPStan, Rector clean.