@viberaven/cli 1.4.4 → 1.5.0

package/README.md

@@ -1,115 +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="assets/report/assets/viberaven-hero.png" alt="VibeRaven — the raven fanning its hand of provider cards" width="460" />
-</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.
-
-![The VibeRaven Card Table](assets/report/assets/viberaven-table.png)
-
-## 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

@@ -47,6 +47,12 @@ Repo scanners redact common key patterns in evidence strings; the CLI runs an ex
 
 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.