Step-by-step delivery
How-To Guides
This section is for practical build sequences: from first publish to production-safe automation, with explicit route and capability boundaries.
Execution-first implementation guides for production Vibecodr work.
Implementation focus
Use this section when you are wiring a feature now and need execution order, expected outcomes, and quick checks.
Expected outcomes
- Ship a new vibe without breaking existing links.
- Move backend responsibilities into Pulses with clear ownership.
- Apply automation and secret rules before exposing public routes.
First publish path
A safe first publish starts with the smallest working surface. Build or paste the client experience, preview it, add metadata that explains what the viewer can do, then publish only when the runtime output matches the intended behavior.
Publishing creates a public post and an artifact that viewers run. Later updates should use BUMP IT when the same app identity should keep its backlinks, embeds, and discovery history.
- Use Composer for quick ideas and Studio for project-shaped work.
- Preview before publishing so runtime and source assumptions are checked early.
- Add creator SEO fields during publish when the post should be discoverable outside Vibecodr.
- Use BUMP IT for updates to the same app; publish a new app only when the identity should change.
Production-safe Pulse path
When an app needs a backend, create Pulse files under the server lane instead of putting secrets or privileged calls into the vibe. The client calls same-origin /api routes, while the Pulse runs on the trusted edge plane.
The owner is responsible for application-level authorization when a public endpoint should not be open-ended. Vibecodr keeps platform grants and secrets out of public projection, but it does not magically know the business rules for every endpoint.
- Put secret-backed provider calls in Pulses, not browser code.
- Validate request shape and method in the Pulse handler.
- Add signatures, session checks, or rate limits for restricted behavior.
- Keep response payloads minimal and avoid returning secrets or operational metadata.
Example and read next
Example: you imported a small app, previewed it, added SEO copy, confirmed the live runtime, and now need the same public identity to keep moving forward. Use the publish flow first, then BUMP IT for future cuts.
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: VibeComposer (/docs/composer)
- Read next: Studio (/docs/studio)
- Read next: BUMP IT (/docs/bump-it)
- Read next: Pulse Routing (/docs/pulse-routing)