@viberaven/cli 1.6.1 → 1.6.2

package/schemas/permissions-matrix.schema.json

@@ -1,90 +1,90 @@
-{
-  "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "https://viberaven.dev/schemas/permissions-matrix.v1.json",
-  "title": "VibeRaven permissions matrix (viberaven.permissions.json)",
-  "description": "Who may read, add, change and delete rows in each table, written by a person. `viberaven rls-test` checks the migrations against it. Never generate it from the app's own policies. Every cell is about rows owned by `owner`: owner acts on their own row, other_user is a different signed-in user acting on the owner's row, anon is a request with only the public anon key. For insert, the new row names the owner as its owner.",
-  "type": "object",
-  "additionalProperties": false,
-  "required": ["version", "tables"],
-  "properties": {
-    "$schema": { "type": "string" },
-    "version": { "const": 1 },
-    "description": { "type": "string" },
-    "defaultGrants": {
-      "description": "Table grants the test database gives new public tables. supabase-legacy: anon and authenticated get all privileges on new public tables, as on existing Supabase projects (the more exposed assumption). none: no default grants, only what the migrations grant.",
-      "enum": ["supabase-legacy", "none"],
-      "default": "supabase-legacy"
-    },
-    "tables": {
-      "type": "object",
-      "minProperties": 1,
-      "propertyNames": { "pattern": "^[A-Za-z_][A-Za-z0-9_$]*(\\.[A-Za-z_][A-Za-z0-9_$]*)?$" },
-      "additionalProperties": { "$ref": "#/$defs/table" }
-    }
-  },
-  "$defs": {
-    "table": {
-      "type": "object",
-      "additionalProperties": false,
-      "required": ["owner", "expect"],
-      "properties": {
-        "description": { "type": "string" },
-        "owner": {
-          "description": "How a row's owner is defined. Only `column = auth.uid()` is supported.",
-          "type": "object",
-          "additionalProperties": false,
-          "required": ["column", "is"],
-          "properties": {
-            "column": { "type": "string", "pattern": "^[A-Za-z_][A-Za-z0-9_$]*$" },
-            "is": { "const": "auth.uid()" }
-          }
-        },
-        "expect": { "$ref": "#/$defs/expectation" },
-        "seed": {
-          "description": "Values for columns the test cannot fill by itself (for example a NOT NULL foreign key). Used for every seeded and inserted row. Leave the owner column out.",
-          "type": "object",
-          "propertyNames": { "pattern": "^[A-Za-z_][A-Za-z0-9_$]*$" },
-          "additionalProperties": { "type": ["string", "number", "boolean", "null"] }
-        },
-        "updateColumn": {
-          "description": "Column the update probe changes. Default: the first plain column that is not the owner column or part of the primary key.",
-          "type": "string",
-          "pattern": "^[A-Za-z_][A-Za-z0-9_$]*$"
-        }
-      }
-    },
-    "expectation": {
-      "type": "object",
-      "additionalProperties": false,
-      "required": ["owner", "other_user", "anon"],
-      "properties": {
-        "owner": { "$ref": "#/$defs/actorCells" },
-        "other_user": { "$ref": "#/$defs/actorCells" },
-        "anon": { "$ref": "#/$defs/actorCells" },
-        "service_role": {
-          "description": "The service role bypasses RLS, so it is never tested.",
-          "const": "excluded"
-        }
-      }
-    },
-    "actorCells": {
-      "type": "object",
-      "additionalProperties": false,
-      "required": ["select", "insert", "update", "delete"],
-      "properties": {
-        "select": { "$ref": "#/$defs/cell" },
-        "insert": { "$ref": "#/$defs/cell" },
-        "update": { "$ref": "#/$defs/cell" },
-        "delete": { "$ref": "#/$defs/cell" },
-        "reassign": {
-          "description": "Optional. Setting the owner column of the owner's row to another user: the owner giving the row away, or another user taking it. Not tested when absent.",
-          "$ref": "#/$defs/cell"
-        }
-      }
-    },
-    "cell": {
-      "description": "allow: the action must work on the owner's row. deny: it must return nothing, change nothing, or be refused with a permission error. skip: not tested (N/A).",
-      "enum": ["allow", "deny", "skip"]
-    }
-  }
-}
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://viberaven.dev/schemas/permissions-matrix.v1.json",
+  "title": "VibeRaven permissions matrix (viberaven.permissions.json)",
+  "description": "Who may read, add, change and delete rows in each table, written by a person. `viberaven rls-test` checks the migrations against it. Never generate it from the app's own policies. Every cell is about rows owned by `owner`: owner acts on their own row, other_user is a different signed-in user acting on the owner's row, anon is a request with only the public anon key. For insert, the new row names the owner as its owner.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["version", "tables"],
+  "properties": {
+    "$schema": { "type": "string" },
+    "version": { "const": 1 },
+    "description": { "type": "string" },
+    "defaultGrants": {
+      "description": "Table grants the test database gives new public tables. supabase-legacy: anon and authenticated get all privileges on new public tables, as on existing Supabase projects (the more exposed assumption). none: no default grants, only what the migrations grant.",
+      "enum": ["supabase-legacy", "none"],
+      "default": "supabase-legacy"
+    },
+    "tables": {
+      "type": "object",
+      "minProperties": 1,
+      "propertyNames": { "pattern": "^[A-Za-z_][A-Za-z0-9_$]*(\\.[A-Za-z_][A-Za-z0-9_$]*)?$" },
+      "additionalProperties": { "$ref": "#/$defs/table" }
+    }
+  },
+  "$defs": {
+    "table": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["owner", "expect"],
+      "properties": {
+        "description": { "type": "string" },
+        "owner": {
+          "description": "How a row's owner is defined. Only `column = auth.uid()` is supported.",
+          "type": "object",
+          "additionalProperties": false,
+          "required": ["column", "is"],
+          "properties": {
+            "column": { "type": "string", "pattern": "^[A-Za-z_][A-Za-z0-9_$]*$" },
+            "is": { "const": "auth.uid()" }
+          }
+        },
+        "expect": { "$ref": "#/$defs/expectation" },
+        "seed": {
+          "description": "Values for columns the test cannot fill by itself (for example a NOT NULL foreign key). Used for every seeded and inserted row. Leave the owner column out.",
+          "type": "object",
+          "propertyNames": { "pattern": "^[A-Za-z_][A-Za-z0-9_$]*$" },
+          "additionalProperties": { "type": ["string", "number", "boolean", "null"] }
+        },
+        "updateColumn": {
+          "description": "Column the update probe changes. Default: the first plain column that is not the owner column or part of the primary key.",
+          "type": "string",
+          "pattern": "^[A-Za-z_][A-Za-z0-9_$]*$"
+        }
+      }
+    },
+    "expectation": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["owner", "other_user", "anon"],
+      "properties": {
+        "owner": { "$ref": "#/$defs/actorCells" },
+        "other_user": { "$ref": "#/$defs/actorCells" },
+        "anon": { "$ref": "#/$defs/actorCells" },
+        "service_role": {
+          "description": "The service role bypasses RLS, so it is never tested.",
+          "const": "excluded"
+        }
+      }
+    },
+    "actorCells": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["select", "insert", "update", "delete"],
+      "properties": {
+        "select": { "$ref": "#/$defs/cell" },
+        "insert": { "$ref": "#/$defs/cell" },
+        "update": { "$ref": "#/$defs/cell" },
+        "delete": { "$ref": "#/$defs/cell" },
+        "reassign": {
+          "description": "Optional. Setting the owner column of the owner's row to another user: the owner giving the row away, or another user taking it. Not tested when absent.",
+          "$ref": "#/$defs/cell"
+        }
+      }
+    },
+    "cell": {
+      "description": "allow: the action must work on the owner's row. deny: it must return nothing, change nothing, or be refused with a permission error. skip: not tested (N/A).",
+      "enum": ["allow", "deny", "skip"]
+    }
+  }
+}

package/templates/AGENTS.snippet.md

@@ -1,56 +1,56 @@
-## VibeRaven Launch Readiness
-
-VibeRaven reads a repository and lists launch gaps for AI-built apps that deploy on Vercel and use Supabase. It runs locally: no login, no API key, no telemetry.
-
-Use it when the user asks whether a Vercel + Supabase app built with an AI tool is ready to launch or hand off, or wants to find migrations that create tables without RLS. This is advice, not a gate: the user decides when to ship. It is a repository check, not a live database test.
-
-### Humans
-
-```bash
-npx -y viberaven
-```
-
-This opens the local Studio. `npx -y viberaven check` prints a terminal verdict.
-
-### Agents
-
-```bash
-npx -y viberaven --agent-mode
-```
-
-1. Run `npx -y viberaven --agent-mode` from the project root.
-2. Read `.viberaven/agent-tasklist.md` first, `.viberaven/gate-result.json` for the verdict (`clear`, `warning` or `not_clear`), and `.viberaven/context-map.json` for compact agent context.
-3. Read `.viberaven/agent-summary.md` second for scan context.
-4. Read `.viberaven/launch-playbook.md` third for the full checklist.
-5. Use `npx -y viberaven next --json` or `npx -y viberaven prompt --gap <id>` for one focused repo-code fix. Local installs can use `viberaven prompt`.
-6. For Vercel + Supabase, run `npx -y viberaven audit --vercel-supabase` and check RLS, service role exposure, and Supabase pooler port 6543 instead of runtime port 5432.
-7. Do not claim provider dashboard checks are fixed by repo-code edits.
-8. After a batch of fixes, run tests/build, then `npx -y viberaven --verify`.
-
-For a CI verdict when the user wants one:
-
-```bash
-npx -y viberaven --strict
-```
-
-Also available:
-
-- `.viberaven/last-scan.json` - full mission map and gaps
-- `.viberaven/report.html` - visual map for the user
-- `npx -y viberaven init --dry-run` - preview local agent rules
-- `npx -y viberaven clean --plan` - write a non-destructive cleanup plan
-
-<!-- viberaven:agent-rules:start -->
-## VibeRaven Agent Rules
-
-VibeRaven reads a repository and lists launch gaps for AI-built apps that deploy on Vercel and use Supabase. This is advice, not a gate: the user decides when to ship. It is a repository check, not a live database test, and a clear result is not a security audit.
-
-- Suggest one pass with `npx -y viberaven --agent-mode` from the project root 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.
-- Read `.viberaven/agent-tasklist.md` first, `.viberaven/gate-result.json` for the verdict, and `.viberaven/context-map.json` for compact agent context.
-- Read `.viberaven/agent-summary.md` and `.viberaven/launch-playbook.md` before editing code for a listed gap.
-- Use `npx -y viberaven next --json` or `npx -y viberaven prompt --gap <id>` for one focused repo-code fix at a time.
-- Run `npx -y viberaven --verify` once per batch of fixes, not after every edit.
-- For the Vercel + Supabase repo evidence, run `npx -y viberaven audit --vercel-supabase`.
-- `npx -y viberaven --strict` returns the verdict as an exit code for CI when the user wants one.
-- Do not claim provider dashboard work is fixed by repo-code edits. Provider dashboard checks, billing/product configuration, DNS, webhooks, credentials, quotas, and live provider verification happen in the provider dashboard.
-<!-- viberaven:agent-rules:end -->
+## VibeRaven Launch Readiness
+
+VibeRaven reads a repository and lists launch gaps for AI-built apps that deploy on Vercel and use Supabase. It runs locally: no login, no API key, no telemetry.
+
+Use it when the user asks whether a Vercel + Supabase app built with an AI tool is ready to launch or hand off, or wants to find migrations that create tables without RLS. This is advice, not a gate: the user decides when to ship. It is a repository check, not a live database test.
+
+### Humans
+
+```bash
+npx -y viberaven
+```
+
+This opens the local Studio. `npx -y viberaven check` prints a terminal verdict.
+
+### Agents
+
+```bash
+npx -y viberaven --agent-mode
+```
+
+1. Run `npx -y viberaven --agent-mode` from the project root.
+2. Read `.viberaven/agent-tasklist.md` first, `.viberaven/gate-result.json` for the verdict (`clear`, `warning` or `not_clear`), and `.viberaven/context-map.json` for compact agent context.
+3. Read `.viberaven/agent-summary.md` second for scan context.
+4. Read `.viberaven/launch-playbook.md` third for the full checklist.
+5. Use `npx -y viberaven next --json` or `npx -y viberaven prompt --gap <id>` for one focused repo-code fix. Local installs can use `viberaven prompt`.
+6. For Vercel + Supabase, run `npx -y viberaven audit --vercel-supabase` and check RLS, service role exposure, and Supabase pooler port 6543 instead of runtime port 5432.
+7. Do not claim provider dashboard checks are fixed by repo-code edits.
+8. After a batch of fixes, run tests/build, then `npx -y viberaven --verify`.
+
+For a CI verdict when the user wants one:
+
+```bash
+npx -y viberaven --strict
+```
+
+Also available:
+
+- `.viberaven/last-scan.json` - full mission map and gaps
+- `.viberaven/report.html` - visual map for the user
+- `npx -y viberaven init --dry-run` - preview local agent rules
+- `npx -y viberaven clean --plan` - write a non-destructive cleanup plan
+
+<!-- viberaven:agent-rules:start -->
+## VibeRaven Agent Rules
+
+VibeRaven reads a repository and lists launch gaps for AI-built apps that deploy on Vercel and use Supabase. This is advice, not a gate: the user decides when to ship. It is a repository check, not a live database test, and a clear result is not a security audit.
+
+- Suggest one pass with `npx -y viberaven --agent-mode` from the project root 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.
+- Read `.viberaven/agent-tasklist.md` first, `.viberaven/gate-result.json` for the verdict, and `.viberaven/context-map.json` for compact agent context.
+- Read `.viberaven/agent-summary.md` and `.viberaven/launch-playbook.md` before editing code for a listed gap.
+- Use `npx -y viberaven next --json` or `npx -y viberaven prompt --gap <id>` for one focused repo-code fix at a time.
+- Run `npx -y viberaven --verify` once per batch of fixes, not after every edit.
+- For the Vercel + Supabase repo evidence, run `npx -y viberaven audit --vercel-supabase`.
+- `npx -y viberaven --strict` returns the verdict as an exit code for CI when the user wants one.
+- Do not claim provider dashboard work is fixed by repo-code edits. Provider dashboard checks, billing/product configuration, DNS, webhooks, credentials, quotas, and live provider verification happen in the provider dashboard.
+<!-- viberaven:agent-rules:end -->

package/templates/CLAUDE.snippet.md

@@ -1,14 +1,14 @@
-<!-- viberaven:agent-rules:start -->
-## VibeRaven Agent Rules
-
-VibeRaven reads a repository and lists launch gaps for AI-built apps that deploy on Vercel and use Supabase. This is advice, not a gate: the user decides when to ship. It is a repository check, not a live database test, and a clear result is not a security audit.
-
-- Suggest one pass with `npx -y viberaven --agent-mode` from the project root 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.
-- Read `.viberaven/agent-tasklist.md` first, `.viberaven/gate-result.json` for the verdict, and `.viberaven/context-map.json` for compact agent context.
-- Read `.viberaven/agent-summary.md` and `.viberaven/launch-playbook.md` before editing code for a listed gap.
-- Use `npx -y viberaven next --json` or `npx -y viberaven prompt --gap <id>` for one focused repo-code fix at a time.
-- Run `npx -y viberaven --verify` once per batch of fixes, not after every edit.
-- For the Vercel + Supabase repo evidence, run `npx -y viberaven audit --vercel-supabase`.
-- `npx -y viberaven --strict` returns the verdict as an exit code for CI when the user wants one.
-- Do not claim provider dashboard work is fixed by repo-code edits. Provider dashboard checks, billing/product configuration, DNS, webhooks, credentials, quotas, and live provider verification happen in the provider dashboard.
-<!-- viberaven:agent-rules:end -->
+<!-- viberaven:agent-rules:start -->
+## VibeRaven Agent Rules
+
+VibeRaven reads a repository and lists launch gaps for AI-built apps that deploy on Vercel and use Supabase. This is advice, not a gate: the user decides when to ship. It is a repository check, not a live database test, and a clear result is not a security audit.
+
+- Suggest one pass with `npx -y viberaven --agent-mode` from the project root 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.
+- Read `.viberaven/agent-tasklist.md` first, `.viberaven/gate-result.json` for the verdict, and `.viberaven/context-map.json` for compact agent context.
+- Read `.viberaven/agent-summary.md` and `.viberaven/launch-playbook.md` before editing code for a listed gap.
+- Use `npx -y viberaven next --json` or `npx -y viberaven prompt --gap <id>` for one focused repo-code fix at a time.
+- Run `npx -y viberaven --verify` once per batch of fixes, not after every edit.
+- For the Vercel + Supabase repo evidence, run `npx -y viberaven audit --vercel-supabase`.
+- `npx -y viberaven --strict` returns the verdict as an exit code for CI when the user wants one.
+- Do not claim provider dashboard work is fixed by repo-code edits. Provider dashboard checks, billing/product configuration, DNS, webhooks, credentials, quotas, and live provider verification happen in the provider dashboard.
+<!-- viberaven:agent-rules:end -->

package/templates/CURSOR.snippet.md

@@ -1,14 +1,14 @@
-<!-- viberaven:agent-rules:start -->
-## VibeRaven Agent Rules
-
-VibeRaven reads a repository and lists launch gaps for AI-built apps that deploy on Vercel and use Supabase. This is advice, not a gate: the user decides when to ship. It is a repository check, not a live database test, and a clear result is not a security audit.
-
-- Suggest one pass with `npx -y viberaven --agent-mode` from the project root 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.
-- Read `.viberaven/agent-tasklist.md` first, `.viberaven/gate-result.json` for the verdict, and `.viberaven/context-map.json` for compact agent context.
-- Read `.viberaven/agent-summary.md` and `.viberaven/launch-playbook.md` before editing code for a listed gap.
-- Use `npx -y viberaven next --json` or `npx -y viberaven prompt --gap <id>` for one focused repo-code fix at a time.
-- Run `npx -y viberaven --verify` once per batch of fixes, not after every edit.
-- For the Vercel + Supabase repo evidence, run `npx -y viberaven audit --vercel-supabase`.
-- `npx -y viberaven --strict` returns the verdict as an exit code for CI when the user wants one.
-- Do not claim provider dashboard work is fixed by repo-code edits. Provider dashboard checks, billing/product configuration, DNS, webhooks, credentials, quotas, and live provider verification happen in the provider dashboard.
-<!-- viberaven:agent-rules:end -->
+<!-- viberaven:agent-rules:start -->
+## VibeRaven Agent Rules
+
+VibeRaven reads a repository and lists launch gaps for AI-built apps that deploy on Vercel and use Supabase. This is advice, not a gate: the user decides when to ship. It is a repository check, not a live database test, and a clear result is not a security audit.
+
+- Suggest one pass with `npx -y viberaven --agent-mode` from the project root 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.
+- Read `.viberaven/agent-tasklist.md` first, `.viberaven/gate-result.json` for the verdict, and `.viberaven/context-map.json` for compact agent context.
+- Read `.viberaven/agent-summary.md` and `.viberaven/launch-playbook.md` before editing code for a listed gap.
+- Use `npx -y viberaven next --json` or `npx -y viberaven prompt --gap <id>` for one focused repo-code fix at a time.
+- Run `npx -y viberaven --verify` once per batch of fixes, not after every edit.
+- For the Vercel + Supabase repo evidence, run `npx -y viberaven audit --vercel-supabase`.
+- `npx -y viberaven --strict` returns the verdict as an exit code for CI when the user wants one.
+- Do not claim provider dashboard work is fixed by repo-code edits. Provider dashboard checks, billing/product configuration, DNS, webhooks, credentials, quotas, and live provider verification happen in the provider dashboard.
+<!-- viberaven:agent-rules:end -->