--- title: Dependency Determinism | Vibecodr Docs description: Learn how Vibecodr freezes runtime dependency graphs, content-addresses executable dependency bytes, and keeps published vibes stable across player, overlay, embed, and vanity surfaces. canonical: https://vibecodr.space/docs/dependency-determinism --- # Dependency Determinism A published vibe should keep playing from the runtime facts it shipped with. This page explains how Vibecodr freezes dependency graphs, uses content-addressed execution, and keeps aliases from becoming accidental sources of truth. Marker: Public explanation of frozen dependency execution and runtime replay stability. ## Implementation focus Use this page when you want to understand why publish is stricter than preview, why exact dependency aliases are not enough, and how BUMP IT or remix changes the runtime lineage deliberately. ## Expected outcomes - Understand which dependency facts are frozen into a published artifact. - Know why SHA content-addressed dependency URLs outrank exact aliases during playback. - Use BUMP IT and remix without accidentally rewriting historical cuts. ## The promise When you publish a vibe, Vibecodr records the runnable artifact and the dependency facts needed to launch it again later. A public cut should not change because a package CDN, browser cache, or runtime surface happens to resolve a dependency differently tomorrow. ### Frozen graph Publish records the runtime manifest, dependency graph, and built artifact instead of leaving playback to rediscover them. ### Content address When Vibecodr has a dependency hash, playback uses that content-addressed byte identity rather than treating a version alias as final truth. ### Lineage stays clear BUMP IT creates the next cut for the same app. Remix creates a related but separate capsule. Neither rewrites the original release. ## Why aliases are not enough Package-version URLs are useful, but they are still aliases. A CDN edge, mirror repair, or old cache can temporarily disagree about the bytes behind an alias. For many libraries that is annoying. For React, Three, or other singleton-heavy runtimes, it can break the app outright by loading two incompatible copies of the same framework. Runtime dependency priority ```txt 1. Use the dependency SHA recorded in the published manifest. 2. Keep exact aliases only as import-map compatibility shims. 3. Fall back to aliases only for older artifacts that do not have enough frozen facts. 4. Require a new BUMP IT or remix when the creator wants different dependency bytes. ``` This keeps player, focused overlay, embeds, and vanity hosts from making separate guesses about dependency identity. ## What happens at publish 1. Vibecodr builds the runtime artifact from the selected source entry. 2. Browser-safe package imports are resolved into a deterministic dependency graph. 3. The artifact manifest records dependency freeze status, resolved imports, and hashes. 4. The public player surfaces launch from the manifest contract instead of local guesses. 5. If a fresh artifact cannot be frozen safely, publish should fail with a fixable dependency issue instead of shipping a fragile release. ## How playback stays stable ### All surfaces use one contract The player, focus overlay, embeds, and vanity runtime host read the same runtime manifest contract. Surface UI can differ, but dependency identity should not. ### Public mirrors prove freshness Fast public artifact manifests have to carry the current serve contract before Vibecodr uses them for playback. An old manifest object existing in storage is not enough. ### Vibecodr keeps playback current Vibecodr can improve the playback shell over time to preserve compatibility and safety. Your published artifact still owns its bundle, manifest facts, and dependency bytes. ### Historical cuts stay readable Older artifacts can still open while background repair or manifest normalization moves delivery metadata onto newer, safer lanes. ### Creators decide behavior changes Platform delivery can improve, but authored behavior changes belong to creator action: BUMP IT for the same app, remix for a related new capsule. ## Practical creator guidance - Prefer package imports that Vibecodr can resolve through the managed dependency path. - Avoid loading the same framework from multiple places, especially React, Three, p5, and rendering libraries with global or singleton state. - Use [Approved CDNs](/docs/approved-cdns) for HTML-style script loading, and keep secret-backed calls in Pulses. - Use [BUMP IT](/docs/bump-it) when a dependency upgrade is meant to change the live app. ## Structured route body ### What gets frozen A published vibe is more than the code you typed. Vibecodr stores the built runtime artifact, the runtime manifest, the selected entry point, and the dependency graph needed to execute it later. For managed npm-style dependencies, Vibecodr records resolved package facts and content hashes. Public playback then uses those frozen facts instead of asking the browser to rediscover the dependency graph from today's package registry or CDN behavior. - Published artifacts keep their own runtime manifest. - Frozen dependency entries point at content-addressed assets when the platform has a valid hash. - Version-like dependency aliases are compatibility lookups, not the final source of executable truth. - A new BUMP IT release or a remix creates new runtime facts instead of mutating the original cut. ### How playback stays consistent Player, focused overlay, embeds, and vanity runtime hosts all read the same manifest contract. That contract normalizes frozen dependencies onto content-addressed URLs and keeps old exact aliases only as shims for module imports that still refer to them. This is why a vibe should not start importing two different copies of the same framework because one surface hit an older cached alias. The published manifest decides the dependency bytes; surface-specific cache state should not. Runtime core is platform-owned, not artifact-owned. Vibecodr can advance bridge, guard, loader, and runtime-core assets to preserve compatibility and safety while the published artifact continues to own its bundle, manifest facts, and dependency bytes. - Runtime manifest reads normalize stored dependency facts before launch. - Direct public artifact mirrors must prove they carry the current manifest serve contract before viewers use them. - Exact dependency routes can be repaired or revalidated without changing which bytes a frozen artifact is supposed to execute. - Older historical artifacts stay readable while repair lanes converge their delivery metadata. ### What creators control Creators control changes by publishing a new cut. If the same app should keep its identity, use BUMP IT. If someone remixes a vibe, the remix becomes its own capsule and artifact lineage while still pointing back to the original as a relative. That line matters: Vibecodr can improve delivery wrappers, caches, and manifest normalization, but the authored published behavior should not silently become a different app because a shared dependency alias drifted somewhere else. - Use BUMP IT when the same app should move forward. - Use remix when the new work should become a related but separate capsule. - Pinned or historical cuts should keep loading from their recorded runtime facts. - If a dependency cannot be made deterministic, fresh publish should fail instead of shipping a fragile runtime. ### Example and read next Example: a published vibe uses an npm package that later changes upstream. Vibecodr should keep replaying from the frozen dependency facts recorded with the artifact, not from today's registry or CDN guesswork. Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system. - Read next: [Source & Versions](/docs/source) - Read next: [Vibe Runtime](/docs/vibe-runtime) - Read next: [Runtime Presentation](/docs/runtime-presentation) - Read next: [Vibes & Pulses](/docs/vibes-pulses) ## Related documentation - [/docs/source](https://vibecodr.space/docs/source/index.md) - [/docs/vibe-runtime](https://vibecodr.space/docs/vibe-runtime/index.md) - [/docs/runtime-presentation](https://vibecodr.space/docs/runtime-presentation/index.md) - [/docs/vibes-pulses](https://vibecodr.space/docs/vibes-pulses/index.md)