@viberaven/cli 1.6.12 → 1.7.0

package/AGENTS.md

@@ -1,15 +1,15 @@
 <!-- VIBERAVEN:START -->
 VibeRaven reads a repository and lists launch gaps for AI-built apps that deploy on Vercel and use Supabase. It runs fully locally: no login, no API key, no telemetry.
 
-Canonical agent command: `npx -y viberaven --agent-mode`
+Canonical agent command: `npx -y viberaven check`
 
-If this command is run from the `viberaven` repo itself, use `node packages/cli/dist/cli.js --agent-mode` to avoid resolving the local package metadata.
+If this command is run from the `viberaven` repo itself, use `node packages/cli/dist/cli.js check` to avoid resolving the local package metadata.
 
 Suggest one pass before a Vercel + Supabase app launches or is handed off, after a Supabase migration or policy change, or when the user reports a production error about RLS, env vars, the database connection, the service role key or a Stripe webhook. It is not needed for apps that do not use Vercel and Supabase, for general SQL or deployment questions, or for one local error.
 
 This is advice, not a gate: the user decides when to ship. It is a repository check, not a live database test: it cannot show which RLS policies are live in production, and a clear result is not a security audit.
 
-Prefer `viberaven_check_readiness` when the VibeRaven MCP server is configured; otherwise `npx -y viberaven --agent-mode`.
+Prefer `viberaven_check_readiness` when the VibeRaven MCP server is configured; otherwise `npx -y viberaven check`.
 <!-- VIBERAVEN:END -->
 
 # VibeRaven CLI: agent instructions
@@ -19,7 +19,7 @@ Prefer `viberaven_check_readiness` when the VibeRaven MCP server is configured;
 From the project root:
 
 ```bash
-npx -y viberaven --agent-mode
+npx -y viberaven check
 ```
 
 It writes, in `.viberaven/`:
@@ -32,7 +32,7 @@ It writes, in `.viberaven/`:
 
 ## Work the gaps
 
-The run prints a block between `VIBERAVEN_NEXT_ACTION_START` and `VIBERAVEN_NEXT_ACTION_END` with `batchSize`, `batchApplied`, `remainingInBatch`, `scanNow`, `stalled`, `type` (`repo-code`, `provider-action`, `verify`, `stalled` or `done`), `gapId` and `requiresUserAction`.
+Read the task list for each gap's fix route and whether user action is required. For legacy batch-loop integrations, the optional `--agent-mode` output also prints a block between `VIBERAVEN_NEXT_ACTION_START` and `VIBERAVEN_NEXT_ACTION_END` with `batchSize`, `batchApplied`, `remainingInBatch`, `scanNow`, `stalled`, `type` (`repo-code`, `provider-action`, `verify`, `stalled` or `done`), `gapId` and `requiresUserAction`.
 
 1. For a repo-code task with `requiresUserAction: false` that lists an MCP call, call `viberaven_heal_apply { gap: "<gapId>", yes: true }` or run `npx -y viberaven fix --gap <gapId>`. Preview first with `npx -y viberaven fix --gap <gapId> --dry-run` or `viberaven_heal_plan`.
 2. For a repo-code task without an MCP call, patch it directly with `npx -y viberaven prompt --gap <gapId>` as guidance. Make minimal, targeted changes and do not refactor unrelated files.

package/README.md

@@ -1,6 +1,6 @@
 # @viberaven/cli
 
-A successful deploy does not show whether one user can read another user's rows. VibeRaven reads an AI-built Vercel + Supabase app's repository for missing row level security (RLS), permissive policies and other launch gaps, then writes findings and tasks a coding agent can work through.
+VibeRaven checks AI-built apps on Vercel + Supabase for launch gaps before you ship: tables without RLS, permissive policies such as `using (true)`, service_role keys in client code, anon-callable security definer functions, the wrong pooler port and unverified Stripe webhooks. It reads the repository on your machine, then writes findings and tasks a coding agent can work through.
 
 Use a pass before launch or client handoff, after a migration or policy change, or when investigating a production RLS, environment, database connection, service-role or Stripe webhook failure.
 
@@ -20,7 +20,7 @@ The `viberaven` package launches this CLI. Studio combines findings, provider co
 
 ## Repository Evidence And Tasks
 
-Checks include migration tables without RLS, unrestricted policy conditions such as `USING (true)`, browser-exposed service-role keys, environment names missing from `.env.example` or similar templates, and Stripe handlers without raw-body signature verification.
+Checks include migration tables without RLS (Supabase lint `rls_disabled_in_public`), unrestricted policy conditions such as `USING (true)`, browser-exposed service-role keys, security definer functions that no migration closes to `anon` (lint `anon_security_definer_function_executable`), a direct 5432 database URL instead of the 6543 pooler, environment names missing from `.env.example` or similar templates, and Stripe handlers without raw-body signature verification. Each gap is listed in the [GitHub README](https://github.com/ohad6k/VibeRaven#what-it-checks).
 
 `check` refreshes `.viberaven/agent-tasklist.md` (tasks and source locations), `gate-result.json` (full verdict), `context-map.json` (agent context) and `gaps/<gapId>.json` without patching app source.
 
@@ -53,7 +53,7 @@ Default `--strict` returns 0 for `clear`/`warning`, 1 for `not_clear`, 2 for `er
 Older integrations can keep the canonical artifact command:
 
 ```bash
-npx -y viberaven --agent-mode
+npx -y viberaven check
 ```
 
 Studio remains the default. MCP hosts use the separate [`@viberaven/mcp`](https://www.npmjs.com/package/@viberaven/mcp) package.