Understand your app's services in VibeRaven
Read what VibeRaven knows about the services your app uses, and know which questions it does not answer.
Before you start
- An app added on viberaven.dev with a GitHub repository the server can read, and repo inspection available on the server. For a private repo, use Connect GitHub under Your apps when offered and grant access to that repository. A link alone does not grant private-repo access.
Steps
- Open your app's page on the 2D overview, or select "Overview" if you are in the work view. When inspection is available, the first visit starts a GitHub repo scan and lists recognised services under "Found in your repo". It can run before you connect your computer.
- Read each node on the map, such as database, hosting or payments. Its status distinguishes "Found in your repo", "Picked by you", "From an earlier scan", "Suggested", "Not found in the repo" and "Not checked yet". An unfilled area is optional, not proof that your app is broken.
- Select a node to open its choices under "Stack", then pick a service. It saves on its own. If saving fails, the page shows an error; pick again to retry.
- If a repo scan was attempted and did not finish, use "Scan again" when it is available. "Re-check" runs the separate local readiness check on your connected computer; it does not refresh the GitHub service scan.
What you should see
- A list of the services your code uses, kept apart from the ones you chose by hand.
If it does not work
- "Nothing recognised in the code yet.": The scan found no service it knows. Choose your services by hand; that records your choice, not a detection.
- "Repo scan is not available yet." or the scan stops: If Scan again is enabled, retry it. If inspection is unavailable, retrying cannot enable it. A private repo also needs GitHub access. You can still pick services by hand, connect your computer and make changes; a failed scan is shown as a warning, not a new finding.
Found in the code is not connected
A service is found in your code from evidence in the repository, such as a dependency or a configuration file. A Supabase client package says the code uses Supabase. It does not show that the credentials work, that the intended project is connected or that the deployed database has the permissions you expect.
A service you chose is your statement about the app. VibeRaven does not verify it against the provider.
Check the behavior a change touches
Start with the action your user needs to complete. If a change touched how private notes load, sign in as one test user and create a note, check that the same user can read it, then check from a second test user and while signed out. Use disposable test data. That covers that one behavior; it is not a security review.
A successful build and a page that loads answer different questions from a successful request to the provider. When you need the provider's own state, such as which row level security policies are live in Supabase or which variables are set in Vercel, read it in that provider's dashboard.
Provider MCP connections
Where your coding agent has a provider MCP connection that you authorized, the agent can use the tools that connection exposes. Which tools and permissions it has depends on the provider and your account. A configured connection is not proof that a particular request or change succeeded.
Next
Checked
Checked on October 15, 2026, by reading the website code through PR #50 and VibeRaven CLI 1.6.10. Website revisions are separate from CLI releases. Not a recorded end-to-end run.
VibeRaven is built for apps on Vercel + Supabase. Its checks are advice, not a gate: you decide what to ship. They read your repository and run your project's own scripts, so they are a repository check, not a live database or security test.