# Filesystem Checks Beat Declared Flags for Classification Stability ## Claim When a system needs a durable, hard-to-spoof classification, checking for the actual artifact a feature requires is more reliable than trusting a declared flag that can drift out of sync with reality. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds when the artifact being checked is a true prerequisite for the feature it signals — a WordPress block theme literally cannot render without `templates/index.html`, so the check can't be spoofed without also satisfying the requirement. - Breaks when the check has side effects the author didn't intend to opt into — here, silently inheriting classification through the parent-theme chain with no way to declare intent otherwise. - Doesn't argue declared flags are always worse — only that they're weaker specifically as a *classification* mechanism when the underlying capability itself can be checked directly. ## Evidence WordPress's `wp_is_block_theme()` doesn't consult `theme.json`, patterns, or any `add_theme_support()` declaration — it checks only whether `templates/index.html` exists, up the parent-theme chain. This makes the classification durable (a theme genuinely can't function as block-based without that file) but also gives it a blast radius its declared-flag alternative wouldn't have: a child theme inherits block-theme status from its parent with zero declaration of its own, and if WordPress 7.1 gates post-editor iframe behavior on this same check, that inheritance becomes a silent, unannounced behavior change. ## Links - [[3. Resources/Permanent Notes/Update Signatures Prove Provenance Not Freshness]] — contrasts: both are cases of "the signal available isn't quite the property you actually need" — a signature proves who shipped something, not when; a file's presence proves capability, not intent - [[3. Resources/Permanent Notes/Sanitize by Value Not by Input Type]] — extends: both prefer checking the actual property that matters (content shape / file existence) over trusting a declared category that can be wrong - [[3. Resources/MOCs/Open Source Governance MOC]] — applies-in: undocumented inheritance behavior in a widely-used classification function is a governance/communication gap as much as a technical one - [[3. Resources/MOCs/WordPress Platform Design MOC]] — applies-in: Explains how WordPress core decides block theme status. ## Tests / falsifiers - Find a case where a declared-flag classification system (e.g., `add_theme_support()`) proved more reliable in practice than a filesystem check for the same feature — if declared flags routinely stay in sync with reality in a comparable system, the claim needs narrowing. - Confirm whether WP 7.1 actually gates iframe behavior on `wp_is_block_theme()`; if it doesn't, the "silent blast radius" half of the evidence weakens even though the classification-stability claim itself still holds. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Full Document Contents/Articles/How WordPress Decides a Theme Is a Block Theme - Gutenberg Times]] — traces `wp_is_block_theme()` to its `WP_Theme::is_block_theme()` implementation and the parent-theme inheritance behavior.