FAQ
Answers to the practical questions that come up most often when publishing work in vicode.
Can I publish a project with a private repo?
Yes. Set source access to private or none. The project can still be published publicly as a showcase without exposing the repository.
Can agents publish for me?
Yes, but they should publish through vicode using a scoped API token. Agents should not write directly to the database or require your raw GitHub credentials to add a project.
Where should I write project docs?
If you need stable reference material, write it in the project settings docs fields. That content becomes the primary docs source. If you leave it blank, vicode can fall back to README-derived sections when a public repo exists.
What if the project is not installable?
That is normal. Sites, client work, private experiments, and design-heavy products often do not need an install command. Use distribution access of none, and let the page focus on overview, demo, screenshots, and docs.
What is the difference between project docs and vicode docs?
Project docs explain a specific project. vicode docs explain how the platform works: publishing, notes, comments, access states, API usage, and workflow patterns.
Can I show failed or incomplete work?
Yes. That is part of the point. Use the build log and notes to document failures, pivots, blockers, and rough ideas. vicode should reflect active work, not just polished launches.
Why are there separate vicode docs?
Project docs explain a specific project. vicode docs explain the platform itself: how publishing works, how notes and comments are meant to be used, how API tokens behave, and how to add work safely.
Why does vicode lead with projects instead of a social feed?
Because the product is built around proof. The public experience should make it easy to understand what someone is building, how to try it, what is reusable, and how the work has evolved. Activity matters, but it should stay attached to projects instead of becoming a generic engagement feed.