One Script, Two Modes
The whole enforcement mechanism is a single script with a flag. In deploy mode it walks a manifest and writes each kit source into each consumer's declared target path. In check mode it walks the same manifest and, instead of writing, compares — reporting every target whose body differs from its source, and every target that should exist and does not.
Using one program for both is not an economy measure; it is the correctness argument. If deploy and check were separate implementations, they could disagree about what "the expected content" is, and then the check would be verifying something the deploy never produces. Sharing the code path means the check is asking exactly the question the deploy answers.
Two Kinds of Failure, Reported Separately
Check mode distinguishes drifted from missing, and it is worth keeping them apart because they have different causes and different fixes. Drifted means the file is there and its body does not match — somebody edited a copy, or a deploy was never run after a kit change. Missing means the manifest says this consumer should have the file and it is not there — usually a new consumer added to a target list before the deploy ran.
Both fail, but the messages differ, and the message is where most of the value of a check lives. "Differs from the kit source" tells you to look at a diff. "The kit expects it vendored" tells you to run the deploy. Collapsing them into a generic failure would mean every incident starts with the same investigation.
What This Buys at Review Time
There is a quieter benefit that shows up when reading someone else's change. In a consumer repository, a diff that touches a vendored file is immediately suspicious — the header says do not edit here, and the drift test would have caught it. So a reviewer does not need to know which files are shared: the header announces it, and the test enforces it.
That is the difference between a convention and a mechanism. A convention requires every reviewer to remember which files are off-limits. A mechanism means the reviewer can review the interesting part of the change and trust that the boring invariant is already held.