`vibe.lock` is the file vibe writes and you commit: the exact versions the project got. This page explains every field so you can read a diff of it in a pull request and know what changed.
There is one `vibe.lock` per workspace, at the absolute root, beside the root [manifest](../glossary/index.xml#manifest); members never have their own. `vibe install` and `vibe update` write it; `vibe clean` keeps it; nothing edits it by hand. It is the recorded decision; the dependency tree on disk is only its consequence and can always be rebuilt from it.
| Field | Meaning |
| `generated_by`, `generated_at` | the vibe version and the time of the last write; informational |
| `schema_version` | the lock schema; an older vibe refuses a newer schema rather than misreading it |
| `solver` | the resolver that produced the graph |
| `root_dependencies` | the coordinates the manifests asked for directly; the baseline of the freshness check |
| `language_chain` | the resolved language preference and its fallbacks, so a re-install on another machine materialises the same files |
`root_dependencies` copies the manifest's `[requires.packages]`, so the [lock file](../glossary/index.xml#lock-file) is a self-contained snapshot that needs no manifest to read. Removing a root with `vibe uninstall` drops it from both files; removing a package that is only a transitive dependency is refused with an explanation.
| Field | Meaning |
| `group`, `name`, `version` | the coordinate that was resolved |
| `kind` | the package's kind, for placement and filters |
| `content_hash` | the fingerprint of the package's shippable tree; the identity; verified on every fetch |
| `registry` | the name of the registry that answered, from the manifest's list |
| `source_url`, `source_ref`, `resolved_commit` | where and at what git ref the bytes were fetched this time; informational, always the canonical address even when a mirror served |
| `source_kind` | `registry`, `git`, `override` or `path`: which resolution path produced the entry; for `path` the URL field holds the member's folder relative to the root |
| `dependencies` | the resolved dependencies of this package, as exact coordinates |
| `overridden` | true when an `[[override]]` supplied the package |
| `features`, `subskills` | the active features and subskills recorded for the package |
| `files_written` | the project files this package's install wrote outside its own folder, so that uninstall can remove exactly them |
| `via_redirect` | the address of the registry stub that delegated the package elsewhere, when one was followed; absent otherwise |
A changed `version` with a changed `content_hash` is an update. A changed `content_hash` with the same version is impossible in a healthy world: vibe refuses it at fetch time, so if you see it in a diff someone edited the file. A changed `source_url` alone is a [mirror](../glossary/index.xml#mirror) or a host migration and means nothing for the project. A new entry with `source_kind = "override"` is a patch someone applied on purpose and should carry a reason in the commit message.
An unchanged manifest against an unchanged [lock file](../glossary/index.xml#lock-file) makes `vibe install` skip the resolver entirely: the lock is the answer.
The lock file records no [registry](../glossary/index.xml#registry) [index](../glossary/index.xml#index-registry) and no mirror: reproducing it needs only the [coordinates](../glossary/index.xml#coordinate), the [fingerprints](../glossary/index.xml#fingerprint) and a source that can serve them.
`vibe why <coordinate>` explains from the lock file and the manifests why a package is in the project, or what blocked it.
The file is read strictly: a field vibe does not know is an error, not a warning, so a hand edit or a field from a newer vibe is caught at once.