Stable playback contract
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.
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.
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 just 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.
- Worker 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.