CorexScreens
Corex\Config\AdminUi\CorexScreens · class · Config layer
The one answer to “is this admin screen ours?” (spec 097, FR-004). Extracted from CorexAdminAssets, where it had grown a second consumer that wanted nothing else from that class — NotificationToolbar injected the whole asset loader and named the property $screens, which is the code saying what it actually needed. Spec 097 would have made a third, so the predicate is its own class now and the asset loader keeps a delegate for callers that already had one. Every consumer must resolve to the same answer or the shell fragments: a screen that counts as ours for the stylesheet but not for the help removal renders the CoreX surface with a WordPress Help tab on top of it. Static, deliberately, and this is the one place in the shell that is. Principle IV exists so that collaborators can be substituted — this has none: no state, no I/O, no branching on configuration, just a regex over a string. There is nothing a test would want to fake here, and making it injectable would have meant either a fourth constructor parameter threaded through three classes or a new inside a constructor, which is the violation Principle IV actually names. Corex\Guides\Corex\CorexGuides::all() is the same shape and the same call.