No check project compiles Runtime/Integrations, so no WUH rule has ever run there

[wallstop]

Runtime/Integrations/** — 19 files across Reflex, VContainer and Zenject — is excluded from every Generator~ check project. TypeCheck names the exclusion explicitly ($(RepoRoot)/Runtime/Integrations/**/*.cs), and EditorCheck, TestCheck and EditorTestCheck inherit it. So the shipped analyzers have never run over that tree.

That is not a theoretical gap. Four files carried the same rule-7 violation until #644's audit:

AttributeMetadataCache cache = _metadataCache ?? AttributeMetadataCache.Instance;
if (cache == null) { return; }

AttributeMetadataCache is a ScriptableObject. ?? is a CLR-null test, so a destroyed injected instance is not replaced by the live Instance — it is passed through, and the very next line's Unity == then reads it as null and returns. VContainer's RelationalSceneLoadListener and Zenject's RelationalComponentSceneInitializer bail there: every relational field in that scene stays null, with no log. WUH003 reports exactly this shape, and it never saw the file. The correct form was two lines away in RelationalComponentAssigner the whole time.

The four sites are fixed. This issue is the reason they could exist.

Why the exclusion is there

Each integration asmdef is gated on a third-party DI package define, and none of the three ships a NuGet package a check project could reference. That is the same situation Odin was in, and #347 solved it the same way it needs solving here: a shim declaring only the base classes and interfaces the package's own sources alias.

What would close this

• Enumerate the external surface each integration binds. Measured today: Reflex.Core, Reflex.Extensions, Reflex.Injectors, Reflex.Enums; VContainer, VContainer.Unity; Zenject. 19 files total, so the surface is small.
• Add shims under a new check project (or a fourth configuration of an existing one), declaring only what those files name — the Odin shim is the precedent for how narrow that can be.
• Load both analyzer DLLs, as every other check project does, so WPROTO### and WUH### both fire.
• Add the new project to scripts/typecheck-controls.js, with an anchor type from Runtime/Integrations/**, so the gate is proven able to fail over that tree rather than merely added.
• Extend lint-typecheck-asmdef-references and its --probe leg to the new project.

Alternative, if the shims prove too costly

A source linter cannot answer this: the analyzer's own documentation records why the signal has to be the receiver's type, because Vector2? p; p?.x is correct and common. So the choice is the shims or an explicit, recorded decision that this tree is unanalyzed — in which case the decision belongs in .llm/context.md beside rule 7, so the next author knows the rule is unenforced exactly there.

Related: #644, #347, #598.

[wallstop]

Closed by #692, with the gap demonstrated rather than asserted.

The external surface, measured. 18 types and 3 static extension holders, enumerated by compiling the 19 files against nothing and reading what the compiler asked for — not by grepping. Reflex.Core/Extensions/Injectors/Enums, VContainer, VContainer.Unity, Zenject. Namespace placement is load-bearing: two files import VContainer.Unity alone, so IInitializable has to live there or the shim would compile a file Unity refuses for a missing using.

A project, not a fourth configuration, for a reason the issue does not name: both lint-typecheck-asmdef-references (discovers Generator~/*Check/ directories) and typecheck-controls (anchors on a project) can only see a project — a configuration would be compiled without being gated. Also, the shims' top-level Reflex/VContainer/Zenject namespaces would widen every existing TypeCheck configuration, and folding Runtime/** in would re-report every runtime finding through a gate whose whole subject is 19 never-analyzed files.

The evidence step, which is the point. Restoring the exact shipped defect in Runtime/Integrations/Zenject/RelationalComponentSceneInitializer.cs:

Runtime/Integrations/Zenject/RelationalComponentSceneInitializer.cs(66,44): error WUH003: '_metadataCache' is a
'WallstopStudios.UnityHelpers.Tags.AttributeMetadataCache', and '??' compares against CLR null rather than through
UnityEngine.Object's '==' overload -- so a destroyed object is treated as alive and the guard does nothing.

With that same violation in place, typecheck:unity:default builds clean. That is the gap, shown. Reverted, md5-verified.

typecheck-controls now reports 5 check projects, 2 controls each, including integrations: … over Runtime/Integrations/. The anchor is load-bearing too: re-adding the exclusion makes both controls fail naming the tree that stopped compiling.

Something the build found that the enumeration did not. UnityObjectExtensions is internal, and Runtime/AssemblyInfo.cs grants the three integration assemblies InternalsVisibleTo (11 call sites across 5 files). So the project's AssemblyName has to be one of those names or it fails with 11 × CS0122 — the same mechanism TestCheck/EditorTestCheck already use.

lint-typecheck-asmdef-references gains rule 3, UNGOVERNED_BY_DESIGN. All three integration asmdefs are overrideReferences: false, so both existing rules go quiet for this project — which reads identically to a project whose source glob went empty. The four projects in that state are recorded with reasons and checked both ways.

Three configurations cover every #if in the tree: default, REFLEX_14_0_OR_NEWER off, UNITY_EDITOR off. protobuf-net was on the reference list and is dead weight; all three build clean without it (#598).

New measurement nothing could have taken before: WUH013 over Runtime/Integrations/** is 22 sites across 7 files. Recorded in CheckProjects.ruleset for whoever picks up #671. Two related totals there and in .llm/context.md were already contradictory (415 vs 420) and are both stale now — PR #685's foreach sweep landed in between — so no new grand total was recorded rather than a wrong one.

Still unverifiable here, and it is the same limitation the Odin shim has carried since #347: the shims are claims about someone else's API, and nothing local can check them. The gated Unity integration legs remain the only thing that compiles these files against the real packages.