@viberaven/cli 1.4.4 → 1.5.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.md +157 -157
- package/LICENSE +21 -21
- package/README.md +1 -3
- package/SECURITY.md +59 -53
- package/dist/cli.js +13764 -32046
- package/dist/console/app.js +251 -251
- package/dist/console/index.html +46 -46
- package/dist/console/styles.css +267 -267
- package/dist/playbooks/_stack-default.json +11 -11
- package/dist/playbooks/auth-supabase.json +31 -31
- package/dist/playbooks/stripe.json +66 -66
- package/dist/playbooks/supabase.json +51 -51
- package/dist/playbooks/vercel.json +42 -42
- package/dist/report/report-cli.css +1466 -1466
- package/dist/report/station.css +11854 -11854
- package/dist/report/station.js +8317 -8317
- package/dist/stack/app.js +18 -0
- package/dist/stack/stack.css +854 -0
- package/package.json +84 -75
- package/playbooks/_stack-default.json +11 -11
- package/playbooks/auth-supabase.json +31 -31
- package/playbooks/stripe.json +66 -66
- package/playbooks/supabase.json +51 -51
- package/playbooks/vercel.json +42 -42
- package/schemas/permissions-matrix.schema.json +90 -0
- package/templates/AGENTS.snippet.md +52 -52
- package/templates/CLAUDE.snippet.md +17 -17
- package/templates/CURSOR.snippet.md +17 -17
- package/assets/report/assets/provider-authjs.svg +0 -5
- package/assets/report/assets/provider-aws.svg +0 -5
- package/assets/report/assets/provider-logrocket.svg +0 -4
- package/assets/report/assets/viberaven-favicon.png +0 -0
- package/assets/report/assets/viberaven-hero.png +0 -0
- package/assets/report/assets/viberaven-logo.png +0 -0
- package/assets/report/assets/viberaven-mascot.png +0 -0
- package/assets/report/assets/viberaven-table.png +0 -0
- package/assets/report/report-cli.css +0 -1466
- package/assets/report/station.css +0 -11854
- package/assets/report/station.js +0 -8319
- package/dist/cli.js.map +0 -7
- package/dist/report/assets/viberaven-hero.png +0 -0
- package/dist/report/assets/viberaven-table.png +0 -0
package/AGENTS.md
CHANGED
|
@@ -1,157 +1,157 @@
|
|
|
1
|
-
<!-- VIBERAVEN:START -->
|
|
2
|
-
VibeRaven provides production readiness for AI-built apps.
|
|
3
|
-
|
|
4
|
-
Canonical command: `npx -y viberaven --agent-mode`
|
|
5
|
-
|
|
6
|
-
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.
|
|
7
|
-
|
|
8
|
-
Use VibeRaven before launch, deployment, real users, auth, billing, database, RLS, env vars, webhooks, monitoring, or tests.
|
|
9
|
-
|
|
10
|
-
Agent loop: run VibeRaven, read Mission Map (`.viberaven/mission-map.md`), fix one launch gap, re-run VibeRaven.
|
|
11
|
-
|
|
12
|
-
## Event-Triggered Production Verification
|
|
13
|
-
|
|
14
|
-
Trigger: modifications to `package.json`, `vercel.json`, `supabase/migrations/**/*`, `.env.example`, auth/billing/webhook paths, or deploy workflow files.
|
|
15
|
-
|
|
16
|
-
1. Do NOT claim "production ready" or close a deploy checklist until `gate.status === "clear"` in `.viberaven/gate-result.json`.
|
|
17
|
-
2. Do NOT run verify after every file patch. Batch heals, then `npx -y viberaven --verify` once per loop.
|
|
18
|
-
3. Do NOT `git push` or deploy after auth, RLS, billing, or webhook changes without `npx -y viberaven --agent-mode`.
|
|
19
|
-
4. If anomalies appear, read `.viberaven/agent-tasklist.md` fully before writing new repo logic.
|
|
20
|
-
|
|
21
|
-
Prefer `viberaven_check_readiness` when MCP is configured; otherwise `npx -y viberaven --agent-mode`.
|
|
22
|
-
|
|
23
|
-
## VibeRaven Production-Readiness Gate
|
|
24
|
-
|
|
25
|
-
- Before running build, compile, cleanup, deployment, vercel, or supabase commands, run `npx -y viberaven --agent-mode` first from the project root.
|
|
26
|
-
- Treat VibeRaven as the Agent Context + Production Gate for AI-built apps, especially apps using Vercel, Supabase, auth, database, payments, webhooks, monitoring, rate limits, or environment variables.
|
|
27
|
-
- Read `.viberaven/agent-tasklist.md` first. If it says CRITICAL GAPS DETECTED or PRODUCTION GATE NOT CLEAR, fix one listed repo-code gap before deploying.
|
|
28
|
-
- Read `.viberaven/gate-result.json` for the machine verdict.
|
|
29
|
-
- Read `.viberaven/context-map.json` for compact agent context.
|
|
30
|
-
- Read `.viberaven/agent-summary.md` second for scan context.
|
|
31
|
-
- Read `.viberaven/launch-playbook.md` third for the full checklist.
|
|
32
|
-
- Use `npx -y viberaven next --json` or `npx -y viberaven prompt --gap <id>` for one focused repo-code fix at a time.
|
|
33
|
-
- For Vercel + Supabase launch checks, run `npx -y viberaven audit --vercel-supabase`.
|
|
34
|
-
- Run `npx -y viberaven --verify` after one fix.
|
|
35
|
-
- Run `npx -y viberaven --strict` before deploy or CI pass.
|
|
36
|
-
- Use `npx -y viberaven --heal --plan --gap <id>` before any heal apply.
|
|
37
|
-
- Only use `npx -y viberaven --heal --apply --gap <id> --yes` for supported low-risk repo-code recipes.
|
|
38
|
-
- Preview local rule installation with `npx -y viberaven init --agents all --dry-run`.
|
|
39
|
-
- Cleanup is non-destructive: only run `npx -y viberaven clean --plan` to create a reviewable cleanup plan.
|
|
40
|
-
- 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 MCP evidence.
|
|
41
|
-
- Do not claim provider dashboard work is fixed by repo-code edits.
|
|
42
|
-
- If VibeRaven prints `LOGIN_URL_READY`, open that URL for the user using the available browser tool or system browser. Tell the user: "I opened VibeRaven sign-in so you can approve access; I will continue after approval." Do not ask for passwords, tokens, cookies, or secrets. Keep the terminal process alive while the user approves.
|
|
43
|
-
|
|
44
|
-
## VibeRaven Production Copilot Loop
|
|
45
|
-
|
|
46
|
-
After every scan, read `.viberaven/agent-tasklist.md` for the prioritized task list.
|
|
47
|
-
|
|
48
|
-
The loop is:
|
|
49
|
-
|
|
50
|
-
1. Read `VIBERAVEN_NEXT_ACTION` from scan output for `batchSize`, `batchApplied`, `scanNow`, and `stalled`.
|
|
51
|
-
2. If `stalled: true`, stop calling verify — address provider-action gaps or report to the user.
|
|
52
|
-
3. If `scanNow: true`, call `viberaven_verify` (or run verify command) before applying more heals.
|
|
53
|
-
4. For each repo-code task where `requiresUserAction: false` (up to `batchSize` per batch):
|
|
54
|
-
- Call MCP: `viberaven_heal_apply { gap: "<gapId>", yes: true }`
|
|
55
|
-
- Or run heal apply command
|
|
56
|
-
5. After a successful heal, VibeRaven increments `.viberaven/loop-state.json`. After a full batch of heals, call verify once - do NOT verify after every single heal.
|
|
57
|
-
6. If verify prints `SCAN_DEFERRED`, do not retry verify. Apply the next listed repo-code heal. Only use `--force-scan` when the user explicitly approves spending a scan early.
|
|
58
|
-
7. Repeat until `gate.status === 'clear'` in `.viberaven/gate-result.json`.
|
|
59
|
-
8. If `requiresUserAction: true`:
|
|
60
|
-
- Read `VIBERAVEN_PROVIDER_ACTION` from terminal output.
|
|
61
|
-
- Present `dashboardUrl` and `exactStep` to the user.
|
|
62
|
-
- Wait for user confirmation, then verify.
|
|
63
|
-
9. If `fixType === 'upgrade-required'`, provide upgradeUrl and move on.
|
|
64
|
-
|
|
65
|
-
Do not stop at "scan complete." The loop is not done until `gate.status === 'clear'`.
|
|
66
|
-
<!-- VIBERAVEN:END -->
|
|
67
|
-
|
|
68
|
-
# VibeRaven CLI - Agent Instructions
|
|
69
|
-
|
|
70
|
-
Use VibeRaven when the user asks whether an app is production-ready, launch-ready, safe to deploy, or missing auth, database, payments, deployment, monitoring, security, provider setup, Vercel, or Supabase checks.
|
|
71
|
-
|
|
72
|
-
VibeRaven is the Agent Context + Production Gate.
|
|
73
|
-
|
|
74
|
-
## Required Agent Loop
|
|
75
|
-
|
|
76
|
-
Run from the project root:
|
|
77
|
-
|
|
78
|
-
```bash
|
|
79
|
-
npx -y viberaven --agent-mode
|
|
80
|
-
```
|
|
81
|
-
|
|
82
|
-
Read in this order:
|
|
83
|
-
|
|
84
|
-
1. `.viberaven/agent-tasklist.md` - the tasklist-first gate
|
|
85
|
-
2. `.viberaven/gate-result.json` - the machine verdict
|
|
86
|
-
3. `.viberaven/context-map.json` - compact context for the next agent step
|
|
87
|
-
4. `.viberaven/agent-summary.md` - scan context
|
|
88
|
-
5. `.viberaven/launch-playbook.md` - full launch checklist
|
|
89
|
-
|
|
90
|
-
Fix one repo-code gap at a time. Prefer:
|
|
91
|
-
|
|
92
|
-
```bash
|
|
93
|
-
npx -y viberaven next --json
|
|
94
|
-
npx -y viberaven prompt --gap <id>
|
|
95
|
-
```
|
|
96
|
-
|
|
97
|
-
After a fix:
|
|
98
|
-
|
|
99
|
-
```bash
|
|
100
|
-
npx -y viberaven --verify
|
|
101
|
-
npx -y viberaven --strict
|
|
102
|
-
```
|
|
103
|
-
|
|
104
|
-
For Vercel + Supabase checks:
|
|
105
|
-
|
|
106
|
-
```bash
|
|
107
|
-
npx -y viberaven audit --vercel-supabase
|
|
108
|
-
```
|
|
109
|
-
|
|
110
|
-
## Production Copilot Loop
|
|
111
|
-
|
|
112
|
-
After every scan, read `.viberaven/agent-tasklist.md` for the prioritized task list.
|
|
113
|
-
|
|
114
|
-
The loop is:
|
|
115
|
-
|
|
116
|
-
1. Read `VIBERAVEN_NEXT_ACTION` from scan output for `batchSize`, `batchApplied`, `scanNow`, and `stalled`.
|
|
117
|
-
2. If `stalled: true`, stop calling verify — address provider-action gaps or report to the user.
|
|
118
|
-
3. If `scanNow: true`, call `viberaven_verify` (or run `--verify`) before applying more heals.
|
|
119
|
-
4. For each repo-code task where `requiresUserAction: false` (up to `batchSize` per batch):
|
|
120
|
-
- Call MCP: `viberaven_heal_apply { gap: "<gapId>", yes: true }`
|
|
121
|
-
- Or run `--heal --apply --gap <id> --yes`
|
|
122
|
-
5. After a full batch of heals, call verify once — do NOT verify after every single heal.
|
|
123
|
-
6. Repeat until `gate.status === 'clear'` in `.viberaven/gate-result.json`.
|
|
124
|
-
7. If `requiresUserAction: true`:
|
|
125
|
-
- Read `VIBERAVEN_PROVIDER_ACTION` from terminal output.
|
|
126
|
-
- Present `dashboardUrl` and `exactStep` to the user.
|
|
127
|
-
- Wait for user confirmation, then verify.
|
|
128
|
-
8. If `fixType === 'upgrade-required'`, provide `upgradeUrl` and move on.
|
|
129
|
-
|
|
130
|
-
Do not stop at "scan complete." The loop is not done until `gate.status === 'clear'`.
|
|
131
|
-
|
|
132
|
-
### Batch discipline
|
|
133
|
-
|
|
134
|
-
```
|
|
135
|
-
for each repo-code task (up to batchSize):
|
|
136
|
-
viberaven_heal_apply { gap: "<gapId>", yes: true }
|
|
137
|
-
|
|
138
|
-
viberaven_verify ← once per batch, not per fix
|
|
139
|
-
```
|
|
140
|
-
|
|
141
|
-
On Pro plans, `viberaven_provider_verify` is available as an MCP tool for read-only provider gap verification via Supabase/Vercel MCP evidence.
|
|
142
|
-
|
|
143
|
-
## Rules
|
|
144
|
-
|
|
145
|
-
- Do not skip VibeRaven before deploy/build/cleanup when production readiness is in scope.
|
|
146
|
-
- Do not claim provider dashboard checks are fixed by repo-code edits.
|
|
147
|
-
- Provider dashboard checks, 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.
|
|
148
|
-
- If VibeRaven prints `LOGIN_URL_READY`, open that URL for the user. Say: "I opened VibeRaven sign-in so you can approve access; I will continue after approval."
|
|
149
|
-
- Do not ask for passwords, tokens, cookies, or secrets.
|
|
150
|
-
|
|
151
|
-
## Current machine-readable docs
|
|
152
|
-
|
|
153
|
-
- Skill: https://viberaven.dev/SKILL.md
|
|
154
|
-
- Agent rules: https://viberaven.dev/AGENTS.md
|
|
155
|
-
- CLI docs: https://viberaven.dev/cli.md
|
|
156
|
-
- MCP config: https://viberaven.dev/mcp.md
|
|
157
|
-
|
|
1
|
+
<!-- VIBERAVEN:START -->
|
|
2
|
+
VibeRaven provides production readiness for AI-built apps.
|
|
3
|
+
|
|
4
|
+
Canonical command: `npx -y viberaven --agent-mode`
|
|
5
|
+
|
|
6
|
+
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.
|
|
7
|
+
|
|
8
|
+
Use VibeRaven before launch, deployment, real users, auth, billing, database, RLS, env vars, webhooks, monitoring, or tests.
|
|
9
|
+
|
|
10
|
+
Agent loop: run VibeRaven, read Mission Map (`.viberaven/mission-map.md`), fix one launch gap, re-run VibeRaven.
|
|
11
|
+
|
|
12
|
+
## Event-Triggered Production Verification
|
|
13
|
+
|
|
14
|
+
Trigger: modifications to `package.json`, `vercel.json`, `supabase/migrations/**/*`, `.env.example`, auth/billing/webhook paths, or deploy workflow files.
|
|
15
|
+
|
|
16
|
+
1. Do NOT claim "production ready" or close a deploy checklist until `gate.status === "clear"` in `.viberaven/gate-result.json`.
|
|
17
|
+
2. Do NOT run verify after every file patch. Batch heals, then `npx -y viberaven --verify` once per loop.
|
|
18
|
+
3. Do NOT `git push` or deploy after auth, RLS, billing, or webhook changes without `npx -y viberaven --agent-mode`.
|
|
19
|
+
4. If anomalies appear, read `.viberaven/agent-tasklist.md` fully before writing new repo logic.
|
|
20
|
+
|
|
21
|
+
Prefer `viberaven_check_readiness` when MCP is configured; otherwise `npx -y viberaven --agent-mode`.
|
|
22
|
+
|
|
23
|
+
## VibeRaven Production-Readiness Gate
|
|
24
|
+
|
|
25
|
+
- Before running build, compile, cleanup, deployment, vercel, or supabase commands, run `npx -y viberaven --agent-mode` first from the project root.
|
|
26
|
+
- Treat VibeRaven as the Agent Context + Production Gate for AI-built apps, especially apps using Vercel, Supabase, auth, database, payments, webhooks, monitoring, rate limits, or environment variables.
|
|
27
|
+
- Read `.viberaven/agent-tasklist.md` first. If it says CRITICAL GAPS DETECTED or PRODUCTION GATE NOT CLEAR, fix one listed repo-code gap before deploying.
|
|
28
|
+
- Read `.viberaven/gate-result.json` for the machine verdict.
|
|
29
|
+
- Read `.viberaven/context-map.json` for compact agent context.
|
|
30
|
+
- Read `.viberaven/agent-summary.md` second for scan context.
|
|
31
|
+
- Read `.viberaven/launch-playbook.md` third for the full checklist.
|
|
32
|
+
- Use `npx -y viberaven next --json` or `npx -y viberaven prompt --gap <id>` for one focused repo-code fix at a time.
|
|
33
|
+
- For Vercel + Supabase launch checks, run `npx -y viberaven audit --vercel-supabase`.
|
|
34
|
+
- Run `npx -y viberaven --verify` after one fix.
|
|
35
|
+
- Run `npx -y viberaven --strict` before deploy or CI pass.
|
|
36
|
+
- Use `npx -y viberaven --heal --plan --gap <id>` before any heal apply.
|
|
37
|
+
- Only use `npx -y viberaven --heal --apply --gap <id> --yes` for supported low-risk repo-code recipes.
|
|
38
|
+
- Preview local rule installation with `npx -y viberaven init --agents all --dry-run`.
|
|
39
|
+
- Cleanup is non-destructive: only run `npx -y viberaven clean --plan` to create a reviewable cleanup plan.
|
|
40
|
+
- 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 MCP evidence.
|
|
41
|
+
- Do not claim provider dashboard work is fixed by repo-code edits.
|
|
42
|
+
- If VibeRaven prints `LOGIN_URL_READY`, open that URL for the user using the available browser tool or system browser. Tell the user: "I opened VibeRaven sign-in so you can approve access; I will continue after approval." Do not ask for passwords, tokens, cookies, or secrets. Keep the terminal process alive while the user approves.
|
|
43
|
+
|
|
44
|
+
## VibeRaven Production Copilot Loop
|
|
45
|
+
|
|
46
|
+
After every scan, read `.viberaven/agent-tasklist.md` for the prioritized task list.
|
|
47
|
+
|
|
48
|
+
The loop is:
|
|
49
|
+
|
|
50
|
+
1. Read `VIBERAVEN_NEXT_ACTION` from scan output for `batchSize`, `batchApplied`, `scanNow`, and `stalled`.
|
|
51
|
+
2. If `stalled: true`, stop calling verify — address provider-action gaps or report to the user.
|
|
52
|
+
3. If `scanNow: true`, call `viberaven_verify` (or run verify command) before applying more heals.
|
|
53
|
+
4. For each repo-code task where `requiresUserAction: false` (up to `batchSize` per batch):
|
|
54
|
+
- Call MCP: `viberaven_heal_apply { gap: "<gapId>", yes: true }`
|
|
55
|
+
- Or run heal apply command
|
|
56
|
+
5. After a successful heal, VibeRaven increments `.viberaven/loop-state.json`. After a full batch of heals, call verify once - do NOT verify after every single heal.
|
|
57
|
+
6. If verify prints `SCAN_DEFERRED`, do not retry verify. Apply the next listed repo-code heal. Only use `--force-scan` when the user explicitly approves spending a scan early.
|
|
58
|
+
7. Repeat until `gate.status === 'clear'` in `.viberaven/gate-result.json`.
|
|
59
|
+
8. If `requiresUserAction: true`:
|
|
60
|
+
- Read `VIBERAVEN_PROVIDER_ACTION` from terminal output.
|
|
61
|
+
- Present `dashboardUrl` and `exactStep` to the user.
|
|
62
|
+
- Wait for user confirmation, then verify.
|
|
63
|
+
9. If `fixType === 'upgrade-required'`, provide upgradeUrl and move on.
|
|
64
|
+
|
|
65
|
+
Do not stop at "scan complete." The loop is not done until `gate.status === 'clear'`.
|
|
66
|
+
<!-- VIBERAVEN:END -->
|
|
67
|
+
|
|
68
|
+
# VibeRaven CLI - Agent Instructions
|
|
69
|
+
|
|
70
|
+
Use VibeRaven when the user asks whether an app is production-ready, launch-ready, safe to deploy, or missing auth, database, payments, deployment, monitoring, security, provider setup, Vercel, or Supabase checks.
|
|
71
|
+
|
|
72
|
+
VibeRaven is the Agent Context + Production Gate.
|
|
73
|
+
|
|
74
|
+
## Required Agent Loop
|
|
75
|
+
|
|
76
|
+
Run from the project root:
|
|
77
|
+
|
|
78
|
+
```bash
|
|
79
|
+
npx -y viberaven --agent-mode
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
Read in this order:
|
|
83
|
+
|
|
84
|
+
1. `.viberaven/agent-tasklist.md` - the tasklist-first gate
|
|
85
|
+
2. `.viberaven/gate-result.json` - the machine verdict
|
|
86
|
+
3. `.viberaven/context-map.json` - compact context for the next agent step
|
|
87
|
+
4. `.viberaven/agent-summary.md` - scan context
|
|
88
|
+
5. `.viberaven/launch-playbook.md` - full launch checklist
|
|
89
|
+
|
|
90
|
+
Fix one repo-code gap at a time. Prefer:
|
|
91
|
+
|
|
92
|
+
```bash
|
|
93
|
+
npx -y viberaven next --json
|
|
94
|
+
npx -y viberaven prompt --gap <id>
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
After a fix:
|
|
98
|
+
|
|
99
|
+
```bash
|
|
100
|
+
npx -y viberaven --verify
|
|
101
|
+
npx -y viberaven --strict
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
For Vercel + Supabase checks:
|
|
105
|
+
|
|
106
|
+
```bash
|
|
107
|
+
npx -y viberaven audit --vercel-supabase
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
## Production Copilot Loop
|
|
111
|
+
|
|
112
|
+
After every scan, read `.viberaven/agent-tasklist.md` for the prioritized task list.
|
|
113
|
+
|
|
114
|
+
The loop is:
|
|
115
|
+
|
|
116
|
+
1. Read `VIBERAVEN_NEXT_ACTION` from scan output for `batchSize`, `batchApplied`, `scanNow`, and `stalled`.
|
|
117
|
+
2. If `stalled: true`, stop calling verify — address provider-action gaps or report to the user.
|
|
118
|
+
3. If `scanNow: true`, call `viberaven_verify` (or run `--verify`) before applying more heals.
|
|
119
|
+
4. For each repo-code task where `requiresUserAction: false` (up to `batchSize` per batch):
|
|
120
|
+
- Call MCP: `viberaven_heal_apply { gap: "<gapId>", yes: true }`
|
|
121
|
+
- Or run `--heal --apply --gap <id> --yes`
|
|
122
|
+
5. After a full batch of heals, call verify once — do NOT verify after every single heal.
|
|
123
|
+
6. Repeat until `gate.status === 'clear'` in `.viberaven/gate-result.json`.
|
|
124
|
+
7. If `requiresUserAction: true`:
|
|
125
|
+
- Read `VIBERAVEN_PROVIDER_ACTION` from terminal output.
|
|
126
|
+
- Present `dashboardUrl` and `exactStep` to the user.
|
|
127
|
+
- Wait for user confirmation, then verify.
|
|
128
|
+
8. If `fixType === 'upgrade-required'`, provide `upgradeUrl` and move on.
|
|
129
|
+
|
|
130
|
+
Do not stop at "scan complete." The loop is not done until `gate.status === 'clear'`.
|
|
131
|
+
|
|
132
|
+
### Batch discipline
|
|
133
|
+
|
|
134
|
+
```
|
|
135
|
+
for each repo-code task (up to batchSize):
|
|
136
|
+
viberaven_heal_apply { gap: "<gapId>", yes: true }
|
|
137
|
+
|
|
138
|
+
viberaven_verify ← once per batch, not per fix
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
On Pro plans, `viberaven_provider_verify` is available as an MCP tool for read-only provider gap verification via Supabase/Vercel MCP evidence.
|
|
142
|
+
|
|
143
|
+
## Rules
|
|
144
|
+
|
|
145
|
+
- Do not skip VibeRaven before deploy/build/cleanup when production readiness is in scope.
|
|
146
|
+
- Do not claim provider dashboard checks are fixed by repo-code edits.
|
|
147
|
+
- Provider dashboard checks, 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.
|
|
148
|
+
- If VibeRaven prints `LOGIN_URL_READY`, open that URL for the user. Say: "I opened VibeRaven sign-in so you can approve access; I will continue after approval."
|
|
149
|
+
- Do not ask for passwords, tokens, cookies, or secrets.
|
|
150
|
+
|
|
151
|
+
## Current machine-readable docs
|
|
152
|
+
|
|
153
|
+
- Skill: https://viberaven.dev/SKILL.md
|
|
154
|
+
- Agent rules: https://viberaven.dev/AGENTS.md
|
|
155
|
+
- CLI docs: https://viberaven.dev/cli.md
|
|
156
|
+
- MCP config: https://viberaven.dev/mcp.md
|
|
157
|
+
|
package/LICENSE
CHANGED
|
@@ -1,21 +1,21 @@
|
|
|
1
|
-
MIT License
|
|
2
|
-
|
|
3
|
-
Copyright (c) 2026 VibeRaven
|
|
4
|
-
|
|
5
|
-
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
-
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
-
in the Software without restriction, including without limitation the rights
|
|
8
|
-
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
-
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
-
furnished to do so, subject to the following conditions:
|
|
11
|
-
|
|
12
|
-
The above copyright notice and this permission notice shall be included in all
|
|
13
|
-
copies or substantial portions of the Software.
|
|
14
|
-
|
|
15
|
-
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
-
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
-
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
-
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
-
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
-
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
-
SOFTWARE.
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 VibeRaven
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
CHANGED
|
@@ -5,13 +5,11 @@
|
|
|
5
5
|
[](https://www.npmjs.com/package/@viberaven/cli)
|
|
6
6
|
|
|
7
7
|
<p align="center">
|
|
8
|
-
<img src="
|
|
8
|
+
<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%" />
|
|
9
9
|
</p>
|
|
10
10
|
|
|
11
11
|
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.
|
|
12
12
|
|
|
13
|
-

|
|
14
|
-
|
|
15
13
|
## Start the Studio
|
|
16
14
|
|
|
17
15
|
```bash
|
package/SECURITY.md
CHANGED
|
@@ -1,53 +1,59 @@
|
|
|
1
|
-
# Security - `@viberaven/cli`
|
|
2
|
-
|
|
3
|
-
## Managed Scan Boundary
|
|
4
|
-
|
|
5
|
-
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.
|
|
6
|
-
|
|
7
|
-
- API keys for model calls live on the server, not in the published npm package.
|
|
8
|
-
- Local credentials store only a VibeRaven access token in `%APPDATA%\viberaven\credentials.json` or `~/.config/viberaven/`.
|
|
9
|
-
- Never commit `credentials.json` or paste tokens into chat.
|
|
10
|
-
|
|
11
|
-
## Safe Commands
|
|
12
|
-
|
|
13
|
-
Human terminal:
|
|
14
|
-
|
|
15
|
-
```bash
|
|
16
|
-
npx -y viberaven
|
|
17
|
-
```
|
|
18
|
-
|
|
19
|
-
Agent or CI gate:
|
|
20
|
-
|
|
21
|
-
```bash
|
|
22
|
-
npx -y viberaven --agent-mode
|
|
23
|
-
npx -y viberaven --verify
|
|
24
|
-
npx -y viberaven --strict
|
|
25
|
-
```
|
|
26
|
-
|
|
27
|
-
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.
|
|
28
|
-
|
|
29
|
-
## Written Artifacts
|
|
30
|
-
|
|
31
|
-
After a scan, the CLI may create:
|
|
32
|
-
|
|
33
|
-
| Path | Contents |
|
|
34
|
-
|------|----------|
|
|
35
|
-
| `.viberaven/last-scan.json` | Full scan payload |
|
|
36
|
-
| `.viberaven/agent-tasklist.md` | Agent tasklist |
|
|
37
|
-
| `.viberaven/gate-result.json` | Machine gate verdict |
|
|
38
|
-
| `.viberaven/context-map.json` | Compact agent context |
|
|
39
|
-
| `.viberaven/gaps/<gapId>.json` | Per-gap evidence |
|
|
40
|
-
| `.viberaven/agent-summary.md` | Human/agent summary |
|
|
41
|
-
| `.viberaven/launch-playbook.md` | Launch checklist |
|
|
42
|
-
| `.viberaven/report.html` | Local HTML report |
|
|
43
|
-
|
|
44
|
-
Repo scanners redact common key patterns in evidence strings; the CLI runs an extra redaction pass before writing files.
|
|
45
|
-
|
|
46
|
-
## Provider Boundaries
|
|
47
|
-
|
|
48
|
-
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.
|
|
49
|
-
|
|
50
|
-
##
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
1
|
+
# Security - `@viberaven/cli`
|
|
2
|
+
|
|
3
|
+
## Managed Scan Boundary
|
|
4
|
+
|
|
5
|
+
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.
|
|
6
|
+
|
|
7
|
+
- API keys for model calls live on the server, not in the published npm package.
|
|
8
|
+
- Local credentials store only a VibeRaven access token in `%APPDATA%\viberaven\credentials.json` or `~/.config/viberaven/`.
|
|
9
|
+
- Never commit `credentials.json` or paste tokens into chat.
|
|
10
|
+
|
|
11
|
+
## Safe Commands
|
|
12
|
+
|
|
13
|
+
Human terminal:
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
npx -y viberaven
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
Agent or CI gate:
|
|
20
|
+
|
|
21
|
+
```bash
|
|
22
|
+
npx -y viberaven --agent-mode
|
|
23
|
+
npx -y viberaven --verify
|
|
24
|
+
npx -y viberaven --strict
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
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.
|
|
28
|
+
|
|
29
|
+
## Written Artifacts
|
|
30
|
+
|
|
31
|
+
After a scan, the CLI may create:
|
|
32
|
+
|
|
33
|
+
| Path | Contents |
|
|
34
|
+
|------|----------|
|
|
35
|
+
| `.viberaven/last-scan.json` | Full scan payload |
|
|
36
|
+
| `.viberaven/agent-tasklist.md` | Agent tasklist |
|
|
37
|
+
| `.viberaven/gate-result.json` | Machine gate verdict |
|
|
38
|
+
| `.viberaven/context-map.json` | Compact agent context |
|
|
39
|
+
| `.viberaven/gaps/<gapId>.json` | Per-gap evidence |
|
|
40
|
+
| `.viberaven/agent-summary.md` | Human/agent summary |
|
|
41
|
+
| `.viberaven/launch-playbook.md` | Launch checklist |
|
|
42
|
+
| `.viberaven/report.html` | Local HTML report |
|
|
43
|
+
|
|
44
|
+
Repo scanners redact common key patterns in evidence strings; the CLI runs an extra redaction pass before writing files.
|
|
45
|
+
|
|
46
|
+
## Provider Boundaries
|
|
47
|
+
|
|
48
|
+
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.
|
|
49
|
+
|
|
50
|
+
## MCP and npm Configuration
|
|
51
|
+
|
|
52
|
+
`@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.
|
|
53
|
+
|
|
54
|
+
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.
|
|
55
|
+
|
|
56
|
+
## Reporting Issues
|
|
57
|
+
|
|
58
|
+
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.
|
|
59
|
+
|