@viberaven/cli 1.7.0 → 1.7.1

package/AGENTS.md

@@ -1,64 +1,64 @@
-<!-- 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 check`
-
-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 check`.
-<!-- VIBERAVEN:END -->
-
-# VibeRaven CLI: agent instructions
-
-## Run it
-
-From the project root:
-
-```bash
-npx -y viberaven check
-```
-
-It writes, in `.viberaven/`:
-
-1. `agent-tasklist.md`: one TASK block per gap, with fix type, file, exact fix, verify command and whether the user must act
-2. `gate-result.json`: the verdict, `gate.status` (`clear`, `warning` or `not_clear`), and `topGapIds`
-3. `context-map.json`: compact context for the next step
-4. `agent-summary.md` and `launch-playbook.md`: scan context and the full checklist
-5. `gaps/<gapId>.json`: detail for each gap
-
-## Work the gaps
-
-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.
-3. A successful heal updates `.viberaven/loop-state.json`. After a batch of up to `batchSize` fixes, or when `scanNow` is true, run `npx -y viberaven --verify` (or `viberaven_verify`) once, not after every fix.
-4. For a task with `requiresUserAction: true`, show the user the task's action and wait for their answer: a provider step (the `VIBERAVEN_PROVIDER_ACTION` block with dashboard URL and step), or a repo change that needs their yes. For `rls_disabled` that change enables RLS without policies, so browser reads return no rows until policies exist; call `viberaven_heal_apply` or run `npx -y viberaven fix --gap rls_disabled` only after they agree. The task's MCP arguments leave out `yes: true`; add it once they agree. Do not claim dashboard, billing, DNS or webhook setup is done from repo edits alone.
-5. If `stalled` is true, stop re-running the check and tell the user which gaps remain.
-6. Stop when `gate.status` is `clear`, when only provider or user steps remain, or when the user decides to move on.
-
-A clear `gate.status` means the repo checks found no blockers. It is not a security audit and does not show what is live in Supabase or Vercel.
-
-## Other commands
-
-```bash
-npx -y viberaven check                      # terminal verdict, exit 1 when blockers exist
-npx -y viberaven next --json                # the next step from the last scan
-npx -y viberaven audit --vercel-supabase    # RLS in migrations, pooler port, service role key
-npx -y viberaven --strict                   # verdict as an exit code for CI: exit 1 when gate.status is not_clear
-npx -y viberaven init --agents all --dry-run
-npx -y viberaven clean --plan               # non-destructive cleanup plan
-```
-
-`viberaven_validate_npm_package` (MCP) looks a new package name up on the public npm registry before an install.
-
-## Current machine-readable docs
-
-- Skill: https://viberaven.dev/SKILL.md
-- Agent rules: https://viberaven.dev/AGENTS.md
-- CLI docs: https://viberaven.dev/cli.md
-- MCP config: https://viberaven.dev/mcp.md
+<!-- 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 check`
+
+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 check`.
+<!-- VIBERAVEN:END -->
+
+# VibeRaven CLI: agent instructions
+
+## Run it
+
+From the project root:
+
+```bash
+npx -y viberaven check
+```
+
+It writes, in `.viberaven/`:
+
+1. `agent-tasklist.md`: one TASK block per gap, with fix type, file, exact fix, verify command and whether the user must act
+2. `gate-result.json`: the verdict, `gate.status` (`clear`, `warning` or `not_clear`), and `topGapIds`
+3. `context-map.json`: compact context for the next step
+4. `agent-summary.md` and `launch-playbook.md`: scan context and the full checklist
+5. `gaps/<gapId>.json`: detail for each gap
+
+## Work the gaps
+
+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.
+3. A successful heal updates `.viberaven/loop-state.json`. After a batch of up to `batchSize` fixes, or when `scanNow` is true, run `npx -y viberaven --verify` (or `viberaven_verify`) once, not after every fix.
+4. For a task with `requiresUserAction: true`, show the user the task's action and wait for their answer: a provider step (the `VIBERAVEN_PROVIDER_ACTION` block with dashboard URL and step), or a repo change that needs their yes. For `rls_disabled` that change enables RLS without policies, so browser reads return no rows until policies exist; call `viberaven_heal_apply` or run `npx -y viberaven fix --gap rls_disabled` only after they agree. The task's MCP arguments leave out `yes: true`; add it once they agree. Do not claim dashboard, billing, DNS or webhook setup is done from repo edits alone.
+5. If `stalled` is true, stop re-running the check and tell the user which gaps remain.
+6. Stop when `gate.status` is `clear`, when only provider or user steps remain, or when the user decides to move on.
+
+A clear `gate.status` means the repo checks found no blockers. It is not a security audit and does not show what is live in Supabase or Vercel.
+
+## Other commands
+
+```bash
+npx -y viberaven check                      # terminal verdict, exit 1 when blockers exist
+npx -y viberaven next --json                # the next step from the last scan
+npx -y viberaven audit --vercel-supabase    # RLS in migrations, pooler port, service role key
+npx -y viberaven --strict                   # verdict as an exit code for CI: exit 1 when gate.status is not_clear
+npx -y viberaven init --agents all --dry-run
+npx -y viberaven clean --plan               # non-destructive cleanup plan
+```
+
+`viberaven_validate_npm_package` (MCP) looks a new package name up on the public npm registry before an install.
+
+## Current machine-readable docs
+
+- Skill: https://viberaven.dev/SKILL.md
+- Agent rules: https://viberaven.dev/AGENTS.md
+- CLI docs: https://viberaven.dev/cli.md
+- MCP config: https://viberaven.dev/mcp.md

package/LICENSE

@@ -1,21 +1,21 @@
-MIT License
-
-Copyright (c) 2026 VibeRaven
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+MIT License
+
+Copyright (c) 2026 VibeRaven
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -1,67 +1,67 @@
-# @viberaven/cli
-
-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.
-
-## Start From Your App
-
-Requires Node.js 20 or newer. Run from the app's project root:
-
-```bash
-# Open the local Studio
-npx -y viberaven@1.6.12
-
-# Fresh terminal check
-npx -y viberaven@1.6.12 check
-```
-
-The `viberaven` package launches this CLI. Studio combines findings, provider context and git comparisons. For chat, select an installed/authenticated Codex CLI, Claude Code or Gemini CLI and use **Test connection**. Access modes: `ask`, `approve`, `full`. Stop Studio with Ctrl+C.
-
-## Repository Evidence And Tasks
-
-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.
-
-`check --json` prints a findings summary and artifact paths. `--json` without `check` runs a fresh scan and prints the full gate object.
-
-```bash
-npx -y viberaven@1.6.12 check --json
-npx -y viberaven@1.6.12 audit --vercel-supabase --json
-npx -y viberaven@1.6.12 fix --gap <gapId> --dry-run
-npx -y viberaven@1.6.12 init --agents all --dry-run
-```
-
-Read tasks and source before targeted edits. Preview fixes first. The `rls_disabled` recipe adds an RLS migration without policies: agree before applying, because browser roles lose row access until policies exist. Apply/test through your database workflow; recheck after a batch. Provider actions require provider evidence.
-
-## Exit Codes And CI
-
-`check` returns 0 with no critical blockers, allowing warnings; 1 for critical blockers; 2 for a scan or comparison error. Unrestricted SELECT can be intentional public content and is a default warning. The focused audit returns 1 whenever its status is not `pass`, including warnings.
-
-```bash
-# Fail on blockers
-npx -y viberaven@1.6.12 --strict --json
-# Also fail on warnings
-npx -y viberaven@1.6.12 --strict=warning --json
-```
-
-Default `--strict` returns 0 for `clear`/`warning`, 1 for `not_clear`, 2 for `error`, 3 for `unknown` or unavailable results. `--strict=warning` also returns 1 for warnings.
-
-## Optional Artifact Compatibility Mode
-
-Older integrations can keep the canonical artifact command:
-
-```bash
-npx -y viberaven check
-```
-
-Studio remains the default. MCP hosts use the separate [`@viberaven/mcp`](https://www.npmjs.com/package/@viberaven/mcp) package.
-
-## Scope And Evidence
-
-The scan needs no VibeRaven login or API key; npm downloads can need network. It does not query live policies, prove complete permission coverage, run your build or deploy. With RLS off, table grants determine which roles and operations can reach rows. Verify live user access and provider environment, DNS, billing and webhooks separately. A clear result or score is not a security audit.
-
-The [missing-RLS example](https://ohad6k.github.io/VibeRaven/examples/proof/missing-rls/) and [RLS comparison](https://ohad6k.github.io/VibeRaven/examples/proof/rls-comparison/) retain published **1.6.3** runs. They are maintainer-authored, not new scans or independent endorsement. Comparison databases are local, not hosted Supabase.
-
-[Public repository](https://github.com/ohad6k/VibeRaven) | [Agent reference](https://ohad6k.github.io/VibeRaven/llms.txt). License: MIT.
+# @viberaven/cli
+
+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.
+
+## Start From Your App
+
+Requires Node.js 20 or newer. Run from the app's project root:
+
+```bash
+# Open the local Studio
+npx -y viberaven@1.6.12
+
+# Fresh terminal check
+npx -y viberaven@1.6.12 check
+```
+
+The `viberaven` package launches this CLI. Studio combines findings, provider context and git comparisons. For chat, select an installed/authenticated Codex CLI, Claude Code or Gemini CLI and use **Test connection**. Access modes: `ask`, `approve`, `full`. Stop Studio with Ctrl+C.
+
+## Repository Evidence And Tasks
+
+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.
+
+`check --json` prints a findings summary and artifact paths. `--json` without `check` runs a fresh scan and prints the full gate object.
+
+```bash
+npx -y viberaven@1.6.12 check --json
+npx -y viberaven@1.6.12 audit --vercel-supabase --json
+npx -y viberaven@1.6.12 fix --gap <gapId> --dry-run
+npx -y viberaven@1.6.12 init --agents all --dry-run
+```
+
+Read tasks and source before targeted edits. Preview fixes first. The `rls_disabled` recipe adds an RLS migration without policies: agree before applying, because browser roles lose row access until policies exist. Apply/test through your database workflow; recheck after a batch. Provider actions require provider evidence.
+
+## Exit Codes And CI
+
+`check` returns 0 with no critical blockers, allowing warnings; 1 for critical blockers; 2 for a scan or comparison error. Unrestricted SELECT can be intentional public content and is a default warning. The focused audit returns 1 whenever its status is not `pass`, including warnings.
+
+```bash
+# Fail on blockers
+npx -y viberaven@1.6.12 --strict --json
+# Also fail on warnings
+npx -y viberaven@1.6.12 --strict=warning --json
+```
+
+Default `--strict` returns 0 for `clear`/`warning`, 1 for `not_clear`, 2 for `error`, 3 for `unknown` or unavailable results. `--strict=warning` also returns 1 for warnings.
+
+## Optional Artifact Compatibility Mode
+
+Older integrations can keep the canonical artifact command:
+
+```bash
+npx -y viberaven check
+```
+
+Studio remains the default. MCP hosts use the separate [`@viberaven/mcp`](https://www.npmjs.com/package/@viberaven/mcp) package.
+
+## Scope And Evidence
+
+The scan needs no VibeRaven login or API key; npm downloads can need network. It does not query live policies, prove complete permission coverage, run your build or deploy. With RLS off, table grants determine which roles and operations can reach rows. Verify live user access and provider environment, DNS, billing and webhooks separately. A clear result or score is not a security audit.
+
+The [missing-RLS example](https://ohad6k.github.io/VibeRaven/examples/proof/missing-rls/) and [RLS comparison](https://ohad6k.github.io/VibeRaven/examples/proof/rls-comparison/) retain published **1.6.3** runs. They are maintainer-authored, not new scans or independent endorsement. Comparison databases are local, not hosted Supabase.
+
+[Public repository](https://github.com/ohad6k/VibeRaven) | [Agent reference](https://ohad6k.github.io/VibeRaven/llms.txt). License: MIT.

package/SECURITY.md

@@ -1,59 +1,59 @@
-# Security - `@viberaven/cli`
-
-## Managed Scan Boundary
-
-The npm CLI does not read `OPENAI_API_KEY` and does not accept a bring-your-own-key scan path. Scans use the VibeRaven managed API after device login, same as the signed-in VS Code extension.
-
-- API keys for model calls live on the server, not in the published npm package.
-- Local credentials store only a VibeRaven access token in `%APPDATA%\viberaven\credentials.json` or `~/.config/viberaven/`.
-- Never commit `credentials.json` or paste tokens into chat.
-
-## Safe Commands
-
-Human terminal:
-
-```bash
-npx -y viberaven
-```
-
-Agent or CI gate:
-
-```bash
-npx -y viberaven --agent-mode
-npx -y viberaven --verify
-npx -y viberaven --strict
-```
-
-VibeRaven is the Agent Context + Production Gate. Agents should read `.viberaven/agent-tasklist.md`, `.viberaven/gate-result.json`, and `.viberaven/context-map.json` before claiming an app is safe to deploy.
-
-## Written Artifacts
-
-After a scan, the CLI may create:
-
-| Path | Contents |
-|------|----------|
-| `.viberaven/last-scan.json` | Full scan payload |
-| `.viberaven/agent-tasklist.md` | Agent tasklist |
-| `.viberaven/gate-result.json` | Machine gate verdict |
-| `.viberaven/context-map.json` | Compact agent context |
-| `.viberaven/gaps/<gapId>.json` | Per-gap evidence |
-| `.viberaven/agent-summary.md` | Human/agent summary |
-| `.viberaven/launch-playbook.md` | Launch checklist |
-| `.viberaven/report.html` | Local HTML report |
-
-Repo scanners redact common key patterns in evidence strings; the CLI runs an extra redaction pass before writing files.
-
-## Provider Boundaries
-
-Provider dashboard checks are not cleared by repo-code edits. Billing/product configuration, DNS, webhooks, credentials, quotas, and live provider verification must be completed or verified in the provider dashboard or through read-only provider evidence.
-
-## MCP and npm Configuration
-
-`@viberaven/mcp` runs the CLI as `npx -y --package=@viberaven/cli@<its own version> -- viberaven ...`. Before it starts that npx, it removes every `npm_package_*` and `npm_lifecycle_*` variable and every `npm_config_*` variable except registry, proxy, TLS and auth settings. So the environment the MCP was started in cannot change what npx runs, add `node-options`, or point npx at another npmrc file.
-
-The child npx still reads npmrc files the normal way: your `~/.npmrc`, the global npmrc, and the `.npmrc` of the folder it runs in. That last one is the scanned repo's own `.npmrc`. It applies exactly as it does when you run `npx viberaven` in that folder yourself, and it can set options such as `node-options`. Only run VibeRaven, through MCP or directly, on repos whose `.npmrc` you would run npx under.
-
-## Reporting Issues
-
-If you believe a scan artifact leaked a secret, rotate the key immediately and open an issue at https://github.com/ohad6k/VibeRaven/issues with the redacted file path only.
-
+# Security - `@viberaven/cli`
+
+## Managed Scan Boundary
+
+The npm CLI does not read `OPENAI_API_KEY` and does not accept a bring-your-own-key scan path. Scans use the VibeRaven managed API after device login, same as the signed-in VS Code extension.
+
+- API keys for model calls live on the server, not in the published npm package.
+- Local credentials store only a VibeRaven access token in `%APPDATA%\viberaven\credentials.json` or `~/.config/viberaven/`.
+- Never commit `credentials.json` or paste tokens into chat.
+
+## Safe Commands
+
+Human terminal:
+
+```bash
+npx -y viberaven
+```
+
+Agent or CI gate:
+
+```bash
+npx -y viberaven --agent-mode
+npx -y viberaven --verify
+npx -y viberaven --strict
+```
+
+VibeRaven is the Agent Context + Production Gate. Agents should read `.viberaven/agent-tasklist.md`, `.viberaven/gate-result.json`, and `.viberaven/context-map.json` before claiming an app is safe to deploy.
+
+## Written Artifacts
+
+After a scan, the CLI may create:
+
+| Path | Contents |
+|------|----------|
+| `.viberaven/last-scan.json` | Full scan payload |
+| `.viberaven/agent-tasklist.md` | Agent tasklist |
+| `.viberaven/gate-result.json` | Machine gate verdict |
+| `.viberaven/context-map.json` | Compact agent context |
+| `.viberaven/gaps/<gapId>.json` | Per-gap evidence |
+| `.viberaven/agent-summary.md` | Human/agent summary |
+| `.viberaven/launch-playbook.md` | Launch checklist |
+| `.viberaven/report.html` | Local HTML report |
+
+Repo scanners redact common key patterns in evidence strings; the CLI runs an extra redaction pass before writing files.
+
+## Provider Boundaries
+
+Provider dashboard checks are not cleared by repo-code edits. Billing/product configuration, DNS, webhooks, credentials, quotas, and live provider verification must be completed or verified in the provider dashboard or through read-only provider evidence.
+
+## MCP and npm Configuration
+
+`@viberaven/mcp` runs the CLI as `npx -y --package=@viberaven/cli@<its own version> -- viberaven ...`. Before it starts that npx, it removes every `npm_package_*` and `npm_lifecycle_*` variable and every `npm_config_*` variable except registry, proxy, TLS and auth settings. So the environment the MCP was started in cannot change what npx runs, add `node-options`, or point npx at another npmrc file.
+
+The child npx still reads npmrc files the normal way: your `~/.npmrc`, the global npmrc, and the `.npmrc` of the folder it runs in. That last one is the scanned repo's own `.npmrc`. It applies exactly as it does when you run `npx viberaven` in that folder yourself, and it can set options such as `node-options`. Only run VibeRaven, through MCP or directly, on repos whose `.npmrc` you would run npx under.
+
+## Reporting Issues
+
+If you believe a scan artifact leaked a secret, rotate the key immediately and open an issue at https://github.com/ohad6k/VibeRaven/issues with the redacted file path only.
+