Project operations
Edit and Manage Projects
Use this when a project already exists and you need to change it without breaking its public identity. It connects draft edits, preview checks, release cuts, settings, visibility, and owner-only material.
Operational guide for editing, managing, and safely updating Vibecodr projects.
Implementation focus
Apply this flow when updating live work, changing public metadata, managing settings, or debugging mismatches between editor state and public playback.
Expected outcomes
- Edit source safely before publishing a new cut.
- Use BUMP IT and rollback without losing canonical app continuity.
- Separate public metadata from owner-only source, logs, secrets, and setup.
- Understand which settings affect discovery, embeds, and viewer behavior.
Manage a live project without losing its identity
Editing a Vibecodr project is not the same as overwriting a public file. You work in editable source, preview the change, then publish a new release when the runtime behavior is ready. The public app identity stays stable when you use BUMP IT to move the live Drop forward.
This matters for teams because public links, embeds, comments, remixes, and discovery history should not scatter every time a bug fix ships. Treat each release as a deliberate cut, with a short note about what changed for viewers.
- Use draft edits for work in progress.
- Preview from the same entry point viewers will use.
- Use BUMP IT when the same app should keep its public identity.
- Use exact cuts or rollback when a live update needs to be inspected or reversed.
Project settings, visibility, and owner-only material
Project management includes public-facing choices and owner-only controls. Titles, descriptions, covers, tags, profile context, and embed availability affect how people discover and understand the work. Source files, secrets, logs, setup notes, and sensitive backend details remain owner-only.
If a setting changes who can see, run, embed, or invoke something, treat it as a product decision. Explain the public effect in plain language, verify the route or player behavior, and avoid exposing operational details as if they were user instructions.
- Keep public metadata useful and human-readable.
- Keep credentials in Pulse Secrets, never in public descriptions or client-visible source.
- Use settings pages for embed and profile-level controls.
- Use troubleshooting docs when preview, publish, or discovery surfaces disagree.
Task example and next paths
Example: your team fixed a bug in a live app and wants the same public URL to keep working. Edit the source, preview the cut, use BUMP IT, and keep owner-only source, logs, and secrets out of the public release notes.
Use the related paths below as the next reading order. They are generated from the same route metadata that powers public HTML, markdown aliases, sitemap coverage, and docs navigation, so users and agents see one consistent documentation graph.
- Related path: /docs/studio
- Related path: /docs/bump-it
- Related path: /docs/source
- Related path: /docs/troubleshooting