@viberaven/cli 1.6.2 → 1.6.4

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 --agent-mode`
-
-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.
-
-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`.
-<!-- VIBERAVEN:END -->
-
-# VibeRaven CLI: agent instructions
-
-## Run it
-
-From the project root:
-
-```bash
-npx -y viberaven --agent-mode
-```
-
-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
-
-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`.
-
-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 --agent-mode`
+
+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.
+
+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`.
+<!-- VIBERAVEN:END -->
+
+# VibeRaven CLI: agent instructions
+
+## Run it
+
+From the project root:
+
+```bash
+npx -y viberaven --agent-mode
+```
+
+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
+
+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`.
+
+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,113 +1,113 @@
-# @viberaven/cli
-
-[![npm version](https://img.shields.io/npm/v/@viberaven/cli)](https://www.npmjs.com/package/@viberaven/cli)
-[![npm downloads](https://img.shields.io/npm/dw/@viberaven/cli)](https://www.npmjs.com/package/@viberaven/cli)
-[![license](https://img.shields.io/npm/l/@viberaven/cli)](https://www.npmjs.com/package/@viberaven/cli)
-
-<p align="center">
-  <img src="https://raw.githubusercontent.com/ohad6k/VibeRaven/main/assets/banner.png" alt="VibeRaven — AI got your app to demo. VibeRaven gets it to production." width="100%" />
-</p>
-
-VibeRaven is **the Card Table** — a local Studio where your AI-built app is laid out in front of you. Every provider (Supabase, Vercel, Stripe, ...) is a graded trading card in your hand: play a card and its production checks run instantly in chat; a **RAVEN GRADE 10** means that territory is production-ready. Versions are a pile you can pull from, your whole architecture is a region map of cards, and Codex, Claude Code, or Gemini CLI does the actual work — with you controlling how much it's allowed to touch.
-
-## Start the Studio
-
-```bash
-npx -y viberaven
-```
-
-That command opens the table:
-
-- **Your hand** — providers as foil cards; click or drop one on the table and its launch checks run in chat, graded 1-10 from repo evidence.
-- **The version pile** — pull a release card to see what changed (real git compare + changelog), view the diff, or ask the agent to explain it.
-- **The region map** — your app as territory: pages, modules, and provider cards connected by routes, every card movable.
-- **Agentic chat** — missions run through your connected CLI, with `ask` / `approve` / `full` access modes and inline approve for risky work.
-- Provider MCP visibility, terminal, and diff views included.
-
-The unscoped `viberaven` package is a small shim that launches this CLI package.
-
-## Agent Connections
-
-Inside the Studio, connect an installed CLI and test it before chat control:
-
-- Codex CLI
-- Claude Code
-- Gemini CLI
-
-Installed is not the same as connected. VibeRaven asks the selected CLI to prove it can run in the current repo before using it for real chat work.
-
-## Provider And Release Context
-
-Use the Studio side tabs and context chips to attach provider or version context to a chat mission:
-
-- Providers: Supabase, Vercel, GitHub, Stripe, Sentry, PostHog, Clerk, Auth.js, Resend, Upstash.
-- Releases: current and recent git tags, changelog snippets, rollback context, and release comparisons.
-- Architecture: repo and provider boundaries for inspection and planning.
-
-Provider dashboard checks are not cleared by repo-code edits. Billing/product configuration, DNS, webhooks, credentials, quotas, and live provider verification must still be completed or verified in the provider dashboard or through read-only provider evidence.
-
-## Machine And CI Commands
-
-The Studio is the default product surface. These commands remain available for automation and CI:
-
-```bash
-npx -y viberaven check --json
-npx -y viberaven --strict --json
-npx -y viberaven actions
-npx -y viberaven --verify --action VR-A1
-```
-
-For focused work:
-
-```bash
-npx -y viberaven next --json
-npx -y viberaven prompt --gap <id>
-npx -y viberaven audit --vercel-supabase
-```
-
-## Legacy Agent Mode
-
-`--agent-mode` is kept for older artifact-first agent workflows:
-
-```bash
-npx -y viberaven --agent-mode
-```
-
-It writes artifacts such as:
-
-- `.viberaven/agent-tasklist.md`
-- `.viberaven/gate-result.json`
-- `.viberaven/context-map.json`
-- `.viberaven/agent-summary.md`
-- `.viberaven/launch-playbook.md`
-
-New product work should prefer the Studio and MCP/chat context flow instead of the old tasklist-first loop.
-
-## MCP
-
-Use the MCP package when an agent host supports MCP tools:
-
-```bash
-npx -y @viberaven/mcp
-```
-
-The MCP server wraps the public CLI and exposes readiness, verification, action, audit, and healing tools without exposing secrets.
-
-## Development
-
-```bash
-npm --prefix packages/cli run typecheck
-npm --prefix packages/cli test -- local-ui/server.test.ts
-npm --prefix packages/cli run build
-```
-
-For a local package publish check, run from this package directory:
-
-```bash
-cd packages/cli
-npm pack --dry-run
-```
-
-## License
-
-MIT
+# @viberaven/cli
+
+[![npm version](https://img.shields.io/npm/v/@viberaven/cli)](https://www.npmjs.com/package/@viberaven/cli)
+[![npm downloads](https://img.shields.io/npm/dw/@viberaven/cli)](https://www.npmjs.com/package/@viberaven/cli)
+[![license](https://img.shields.io/npm/l/@viberaven/cli)](https://www.npmjs.com/package/@viberaven/cli)
+
+<p align="center">
+  <img src="https://raw.githubusercontent.com/ohad6k/VibeRaven/main/assets/banner.png" alt="VibeRaven — AI got your app to demo. VibeRaven gets it to production." width="100%" />
+</p>
+
+VibeRaven is **the Card Table** — a local Studio where your AI-built app is laid out in front of you. Every provider (Supabase, Vercel, Stripe, ...) is a graded trading card in your hand: play a card and its production checks run instantly in chat; a **RAVEN GRADE 10** means that territory is production-ready. Versions are a pile you can pull from, your whole architecture is a region map of cards, and Codex, Claude Code, or Gemini CLI does the actual work — with you controlling how much it's allowed to touch.
+
+## Start the Studio
+
+```bash
+npx -y viberaven
+```
+
+That command opens the table:
+
+- **Your hand** — providers as foil cards; click or drop one on the table and its launch checks run in chat, graded 1-10 from repo evidence.
+- **The version pile** — pull a release card to see what changed (real git compare + changelog), view the diff, or ask the agent to explain it.
+- **The region map** — your app as territory: pages, modules, and provider cards connected by routes, every card movable.
+- **Agentic chat** — missions run through your connected CLI, with `ask` / `approve` / `full` access modes and inline approve for risky work.
+- Provider MCP visibility, terminal, and diff views included.
+
+The unscoped `viberaven` package is a small shim that launches this CLI package.
+
+## Agent Connections
+
+Inside the Studio, connect an installed CLI and test it before chat control:
+
+- Codex CLI
+- Claude Code
+- Gemini CLI
+
+Installed is not the same as connected. VibeRaven asks the selected CLI to prove it can run in the current repo before using it for real chat work.
+
+## Provider And Release Context
+
+Use the Studio side tabs and context chips to attach provider or version context to a chat mission:
+
+- Providers: Supabase, Vercel, GitHub, Stripe, Sentry, PostHog, Clerk, Auth.js, Resend, Upstash.
+- Releases: current and recent git tags, changelog snippets, rollback context, and release comparisons.
+- Architecture: repo and provider boundaries for inspection and planning.
+
+Provider dashboard checks are not cleared by repo-code edits. Billing/product configuration, DNS, webhooks, credentials, quotas, and live provider verification must still be completed or verified in the provider dashboard or through read-only provider evidence.
+
+## Machine And CI Commands
+
+The Studio is the default product surface. These commands remain available for automation and CI:
+
+```bash
+npx -y viberaven check --json
+npx -y viberaven --strict --json
+npx -y viberaven actions
+npx -y viberaven --verify --action VR-A1
+```
+
+For focused work:
+
+```bash
+npx -y viberaven next --json
+npx -y viberaven prompt --gap <id>
+npx -y viberaven audit --vercel-supabase
+```
+
+## Legacy Agent Mode
+
+`--agent-mode` is kept for older artifact-first agent workflows:
+
+```bash
+npx -y viberaven --agent-mode
+```
+
+It writes artifacts such as:
+
+- `.viberaven/agent-tasklist.md`
+- `.viberaven/gate-result.json`
+- `.viberaven/context-map.json`
+- `.viberaven/agent-summary.md`
+- `.viberaven/launch-playbook.md`
+
+New product work should prefer the Studio and MCP/chat context flow instead of the old tasklist-first loop.
+
+## MCP
+
+Use the MCP package when an agent host supports MCP tools:
+
+```bash
+npx -y @viberaven/mcp
+```
+
+The MCP server wraps the public CLI and exposes readiness, verification, action, audit, and healing tools without exposing secrets.
+
+## Development
+
+```bash
+npm --prefix packages/cli run typecheck
+npm --prefix packages/cli test -- local-ui/server.test.ts
+npm --prefix packages/cli run build
+```
+
+For a local package publish check, run from this package directory:
+
+```bash
+cd packages/cli
+npm pack --dry-run
+```
+
+## 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.
+