# Questions {#root} @status:doc/work @audience:user [p01] Real questions people asked, each answered in a few sentences with a link to the page that explains the mechanism. ## Do I commit the dependency tree? {#q-commit-vibedeps} [p02] Yes. `vibevm/vibedeps/` is committed on purpose, so an agent that clones the repository can read the whole lane without running anything and a reviewer can see exactly what text changed when a dependency moved. It is vibe's tree, not yours: never edit it, and let `vibe reinstall` rebuild it when in doubt. See [Two trees](../model/two-trees.xml). > [p03] `vibedeps/` is **committed** to the repository. A fresh clone is immediately bootable with no `vibe install`; the dependency corpus is visible and diffable; this matches the spec-driven principle that the committed spec corpus is the product. > > ## A dependency deep in my tree clashes on a version. How do I fix it? {#q-conflict} [p04] First read the resolver's explanation: it names the two constraints that disagree, and overlapping ranges are not a conflict. Then climb the ladder from lightest to heaviest. Widen a constraint you over-narrowed. Move the intermediate dependency to a version with a compatible constraint with `vibe update`. Add an `[[override]]` for the one [coordinate](../glossary/index.xml#coordinate), with a `reason`. Fork and use a [git source](../glossary/index.xml#git-source) when the dependency's own constraint must change. One version per package across the whole workspace is the rule, so vibe stops rather than installing two. > [p05] **Decision.** `[[override]]` bypasses the registry layer for a named pkgref: > > ## Why does install ask me to confirm? {#q-confirm} [p06] Because an install writes into your repository: the dependency tree, the [lock file](../glossary/index.xml#lock-file), the boot files, the [managed block](../glossary/index.xml#managed-block) in the instruction files. The plan shows all of it first. In a script, `--assume-yes` or `--unattended` answers for you; declining is not an error and leaves nothing half-written. > [p07] The plan / confirm / apply contract holds, but the plan's unit is **the set of packages to materialise plus the boot artifacts to regenerate**, not a per-file write list — `[writes]` is retired (§2.6). > > ## Does vibe call a language model? {#q-llm} [p08] Not on its own. vibe has no model inside it and every subsystem works algorithmically. When a step needs reasoning, vibe parks an instruction for the agent that hosts it, or, at a terminal, calls a model service you configured, only for that step and only if you switched the feature on. See [Ask your agent to do the work](../agent/ask-your-agent.xml). > [p09] Every core VibeVM subsystem retains a complete algorithmic mode. An LLM may improve quality when the operator explicitly enables that feature; credentials, endpoint presence, provider configuration or construction never activate a feature. VibeVM remains useful with no provider, no API access and no agent host. > > ## Can two versions of one package coexist in a project? {#q-two-versions} [p10] No. Resolution picks one version per package across the workspace, and the lane an agent reads would otherwise contain two versions of the same rules. If two members of a workspace truly need different majors, they are two workspaces. > [p11] Run anywhere inside a workspace, `vibe install` calls `Workspace::discover`, runs **one unified resolution** across every member's `[requires]`, materialises each resolved package once into `vibedeps/` (§2.1), and regenerates the boot artifacts (§2.3) for every entry-point node. One `vibe.lock` at the absolute root (PROP-007 §2.4). > > ## A registry I used has disappeared. Is my project stuck? {#q-registry-gone} [p12] Not while the machine [store](../glossary/index.xml#store) holds the packages: a stored version is usable even when no [registry](../glossary/index.xml#registry) lists it any more, and `vibe reinstall` rebuilds the tree from the lock file and the store. For the long run, `vibe registry vendor` writes a folder of everything the lock file references, which any machine can use as a `file://` [mirror](../glossary/index.xml#mirror). > [p13] **Decision (owner, 2026-08-19).** A package version present in the cache is **usable, and materialises, even when it exists in no registry at all** — deleted upstream, the whole organisation gone, every mirror down. This is not the `--offline` policy: `--offline` forbids the network, while this governs a run where the network is allowed, was consulted, and answered "no such package". *(Built 2026-08-20: the fallback fires strictly on the absence forms and rides the LOCKFILE pin — provenance comes from the existing lock entry, so a version in the store but in no lock and no registry is not rescued; minting a store-provenance wire form for that case is an owner act, held open.)* > > ## How do I pin a package to an exact version? {#q-pin} [p14] Install it with `@=1.2.0`, or pass `--exact` to `vibe install` or `vibe update` to write the resolved version as an exact pin into the [manifest](../glossary/index.xml#manifest). Without `--exact`, the manifest keeps a range and the lock file holds the pin, which is what most projects want. > [p15] `flow:wal@0.3.0` → exact. > > ## Can I edit vibe.lock by hand to silence a hash error? {#q-edit-lock} [p16] No. A [fingerprint](../glossary/index.xml#fingerprint) mismatch means the bytes served are not the bytes the lock file remembered: a force-pushed tag, a broken mirror or a deliberate [override](../glossary/index.xml#override). Find out which, then uninstall and reinstall to re-pin, remove the broken mirror, or record the override with its reason. Editing the lock file defeats the only integrity check you have. > [p17] a compromised mirror cannot silently substitute content — the mismatch triggers hard fail before any write; > > ## Why so many package kinds? {#q-why-eight-kinds} [p18] Because a tool that knows what a package is for before opening it can refuse the wrong thing early: a documentation package cannot carry a [boot snippet](../glossary/index.xml#boot-snippet), a server package must pin what it serves, a feature cannot name a framework. Each kind is one genre, and a word that meant two genres was split the moment it did. > [p19] **Decision.** `kind` (`flow` / `feat` / `stack` / `tool`) stays a **mandatory `[package]` field** but is now a pure attribute — it identifies nothing and names nothing. > > ## I am on a plane. What works? {#q-offline} [p20] Everything that reads the store and the project: install from the store with `--offline`, reinstall, check, tree, the local documentation reader. What does not work says so with the missing coordinate named, and never installs a partial result. Warm the store before you leave with `vibe cache add`. See [Work offline](../howto/work-offline.xml). > [p21] `--offline` never silently degrades to a partial result. > > ## The project is done. How do I ship it without vibe? {#q-remove-vibe} [p22] `vibe scrape` removes the vibe layer by contract and proves the native build still passes, either into a new folder or in place with recovery. It is different from `vibe clean`, which removes only what vibe can regenerate. See [Remove VibeVM from a project](../lifecycle/scrape.xml). > [p23] PROP-053 `vibe clean` removes > regenerable dependency and boot products while retaining authored project > state and `vibe.lock`. Scrape is not clean: it removes the Vibe > relationship itself and therefore requires a contract, native health > proof and recoverable commit. > > ## Why can I not install the manual into my project? {#q-docs-install} [p24] Documentation is read, not executed, and it must not enter the lane an agent reads at every session start. So a documentation package is warmed into the machine store with `vibe cache add`, read locally with `vibe doc serve`, and reached by an agent through a [skill](../glossary/index.xml#skill) or by address. See [Read documentation locally](../howto/read-documentation-locally.xml). > [p25] `vibe install` MUST refuse a `doc` package with a hint naming the warm-up command; documentation is warmed into the machine store with `vibe cache add` (§11), and the local reader and `vibe explain` read the store. > >