What a File-to-File Map Can See
The copy-deploy mechanism is a map: one source file, one destination file, per consumer that opted in. It is exact about bodies. It is silent about relationships. If file A uses a type from file B, the map has no idea. It will deliver A to a consumer whose rows never named B, or whose B came from somewhere else, and every row it does have will compare cleanly against its own source.
For a leaf, that silence is correct. A generated vocabulary binding has no kit-internal imports. A pin helper that talks to a system keychain and returns a result has no kit-internal imports. The eight copies of a launcher's main file can even carry three different provenance stamps and still be harmless, as long as the bodies match — the stamp is not the body, and the files do not form a graph.
Layered infrastructure is a graph. A fence that depends on an identity type, an engine that depends on both, a store that depends on a document type that depends on a decoder helper: these are not leaves. Deliver them as leaves and the first time one consumer's rows carry one file without the other, the failure is a compile error in one consumer, on one build, with no row in the map reporting drift. The map compared the right bytes. It compared the wrong unit.
The Compiler Is the Unit You Actually Needed
A package is one build. Its targets are separate modules, but every one of them is compiled from the same tree in the same build, so types stay coherent: the compiler checks each edge against the version that is actually beside it. That is a property no amount of discipline on top of a file map can reconstruct — you would be rebuilding a module system by hand, in a script whose entire job is to not know what the files mean.
So layered Swift moved. The leaves stayed. The generated catalog stayed generated, because its authority is the data file, not any Swift source; turning it into a package product would hide the copies from the guard that exists to catch a hand-written fourth table. The rule for new shared Swift is now: if it sits on a kit-internal edge — it uses a type or function another shared file declares, or another shared file uses one of its own — it goes in the package. A graph root and a graph leaf travel together. If it has no such edge, the file map is still the narrower, better mechanism.
Do Not Migrate the Leaves as Housekeeping
The leftover Swift leaves are not unfinished business. They are the files for which the file map is still the right answer. Moving one into the package "to clean up" would pay a conversion cost for no coherence gain, and it would blur the rule the next author needs: graph or leaf, not Swift or not.
Migrate a leaf only when a change puts it on a kit-internal edge — it starts using something another shared file declares, or another shared file starts using it. A second consumer, or two copies wanting a shared test, is the copy-mechanism's own trigger, not a reason to put a leaf in the package. Until an edge appears, the package and the map sit beside each other, and the next lesson is how they are not allowed to reach into each other.