Questions
01Real 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?
02Yes. 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.
03vibedeps/is committed to the repository. A fresh clone is immediately bootable with novibe 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?
04First 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, with a reason. Fork and use a 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.
05
Decision. [[override]] bypasses the registry layer for a named pkgref:
Why does install ask me to confirm?
06Because an install writes into your repository: the dependency tree, the lock file, the boot files, the 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.
07
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?
08Not 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.
09 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?
10No. 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.
11 Run anywhere inside a workspace,vibe installcallsWorkspace::discover, runs one unified resolution across every member's[requires], materialises each resolved package once intovibedeps/(§2.1), and regenerates the boot artifacts (§2.3) for every entry-point node. Onevibe.lockat the absolute root (PROP-007 §2.4).
A registry I used has disappeared. Is my project stuck?
12Not while the machine store holds the packages: a stored version is usable even when no 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.
13 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--offlinepolicy:--offlineforbids 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?
14Install 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. Without --exact, the manifest keeps a range and the lock file holds the pin, which is what most projects want.
15
flow:wal@0.3.0 → exact.
Can I edit vibe.lock by hand to silence a hash error?
16No. A 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. 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.
17 a compromised mirror cannot silently substitute content — the mismatch triggers hard fail before any write;
Why so many package kinds?
18Because 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, 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.
19 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?
20Everything 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.
21
--offline never silently degrades to a partial result.
The project is done. How do I ship it without vibe?
22vibe 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.
23 PROP-053vibe cleanremoves regenerable dependency and boot products while retaining authored project state andvibe.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?
24Documentation 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 or by address. See Read documentation locally.
25vibe installMUST refuse adocpackage with a hint naming the warm-up command; documentation is warmed into the machine store withvibe cache add(§11), and the local reader andvibe explainread the store.