Runtime launch model
How Vibes Start
A vibe can be visible before it is fully interactive. This page explains the launch states users can observe and report.
Runtime launch explanation for visible, ready, and interactive Vibecodr states.
Implementation focus
Use this when a runtime appears to load, hangs before controls work, or behaves differently between Studio, player, embed, focus, and vanity surfaces.
Expected outcomes
- Distinguish visible frame, shell readiness, and interactive app start.
- Understand why first opens can differ from warm opens.
- Name the failing surface before changing source code.
- Report runtime launch issues with useful public details.
A vibe has launch stages
A visible frame, shell readiness, and full interactivity are different states. A player surface can show the runtime frame before the app has finished starting, especially on the first open after publish or after dependency/runtime facts need to be prepared.
This is why a vibe can look present before controls respond. Vibecodr waits for enough readiness to avoid pretending an app is interactive when the runtime has not safely started.
- The visible frame means the host surface is present.
- Shell readiness means the runtime container is prepared enough to receive the app.
- Interactive readiness means the app code has started and can respond to input.
- Warm opens can feel faster than first opens because some runtime facts are already prepared.
Check the surface before changing code
Player, focus, Studio preview, embed, and vanity routes use the same published runtime facts, but each surface has different framing and viewer constraints. A problem in one surface does not always mean the source code is wrong.
When launch feels stuck, name the route, surface, browser, whether it happens signed in or signed out, and whether a new cut changed dependencies, presentation profile, or Pulse calls.
- If Studio preview starts but public player does not, check the published cut and runtime artifact.
- If player starts but embed does not, check embed visibility, allowlist, and pinned/live behavior.
- If controls never respond, report the surface and route with the expected first interaction.
Example and read next
Example: a player frame appears before buttons work. Separate visible frame, shell readiness, and interactive app start before changing source code or reporting the runtime as broken.
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: Runtime Presentation
- Read next: Troubleshooting
- Read next: Dependency Determinism
- Read next: Embeds