## Summary `kit-lock.json` is written during `kit install`, but normal install resolution does not use it as an authoritative dependency source. That makes deploys less reproducible and makes lockfiles misleading when installed package state diverges from manifest requests. ## Current behavior - `kit install` writes `kit-lock.json` after resolving dependencies. - Production install code does not read the lockfile during dependency resolution. - Git lockfile entries store the manifest ref string, not the resolved commit SHA. ## Desired behavior - Record the resolved Git commit SHA for every Git dependency. - On normal `kit install`, prefer the lockfile resolved commit when the manifest dependency source still matches. - Provide an explicit path for refresh/update behavior instead of mutating locked dependencies implicitly. - Detect and report lockfile drift clearly when the installed tree checksum/version does not match the lockfile. ## Related - #243 tracks the immediate bug where a changed manifest ref leaves the old checkout installed while the lockfile claims the new ref. - #213 added `kit-version` compatibility metadata, which should continue to be checked after lockfile resolution.