How Configuration Works

What each configuration field does, and how it changes the behavior of scans and pipelines.

VCP Configuration Flow

.vcp/config.json
    |
    +-- scopes ──────────> Which standards are loaded
    +-- compliance ──────> Additional compliance standards
    +-- severity ────────> Which findings are reported
    +-- ignore ──────────> What gets suppressed (3 levels)
    +-- exclude ─────────> Which file paths are skipped
    +-- frameworks ──────> Package ecosystem for dependency checks
    +-- pluginRoot ──────> Where shared TypeScript modules live

Scopes: What Gets Checked

Scopes control which standards are loaded when skills run.

scopes.web-backend = true
    → loads: web-backend-security, web-backend-structure,
             web-backend-data-access, web-backend-api-design,
             web-backend-realtime, web-backend-caching
    → adds: ~35 additional rules to every scan

Core standards are always loaded regardless of scopes. These include security, architecture, code quality, error handling, testing, dependency management, and root cause analysis (~50 rules).

Scopes enabled	Approximate rules checked
None (core only)	~50 rules
+ web-backend	~85 rules
+ web-frontend	~70 rules (core + frontend)
+ web-backend + web-frontend	~105 rules
All scopes + all compliance	~150+ rules

More rules means more findings. Start with only the scopes that apply to your project.

Severity: What Gets Reported

The severity threshold is a filter on scan results. Findings below the threshold are dropped.

severity: "high"
    → /vcp-audit reports: critical + high findings
    → /vcp-pre-commit-review: only blocks on critical + high
    → /vcp-audit quick: only checks critical + high rules
    → medium and low findings: silently excluded

Threshold	Findings shown	Best for
`critical`	Only critical	Legacy codebases — focus on the worst issues first
`high`	Critical + high	Established projects — catch important issues without noise
`medium` (default)	Critical + high + medium	Most projects — good balance
`low`	Everything	New projects — maximum coverage from the start

The security gate (real-time blocking) ignores severity. It always blocks all matched patterns regardless of your threshold. Severity only affects skill-based scanning.

Compliance: Additional Standards

Each compliance framework adds one standard with regulation-specific rules.

compliance: ["gdpr"]
    → loads: compliance-gdpr standard
    → adds: data deletion, retention, consent, PII handling rules
    → /vcp-audit compliance gdpr: runs targeted compliance audit

Framework	Standard added	Rule focus
`gdpr`	compliance-gdpr	Data deletion, retention periods, consent management, PII handling
`pci-dss`	compliance-pci-dss	Card tokenization, masking, CDE isolation, encryption
`hipaa`	compliance-hipaa	PHI encryption, audit logging, minimum necessary principle

Only add compliance frameworks that legally apply to your project. They add a lot of rules and will produce irrelevant findings if the regulation doesn't apply.

Ignore: What Gets Suppressed

The ignore array works at three levels, depending on the entry format:

ignore: ["core-architecture"]
    → Level 1 (standard-level): Entire standard removed from applicable list
    → Effect: Zero rules from core-architecture are ever loaded
    → Where: resolve-config.ts, before any skill fetches standards

ignore: ["core-security/rule-3"]
    → Level 2 (rule-level): Specific rule filtered after standard loads
    → Effect: core-security loads, but rule 3 is excluded from results
    → Where: Skills and vcp-context-core.ts, after rules are extracted

ignore: ["CWE-798"]
    → Level 3 (CWE-level): Security gate pattern disabled
    → Effect: Real-time blocking for hardcoded secrets is turned off
    → Where: security-gate.ts, at pattern matching time

Global + project ignore lists are merged (union). If the global config ignores CWE-117 and the project ignores core-architecture, both are suppressed.

Security warning: Ignoring security-tagged standards or CWEs triggers a warning in skills:

WARNING: Critical security findings suppressed by ignore config.

Exclude: Path Filtering

Exclude patterns tell skills which files to skip.

exclude: ["dist/**", "migrations/**"]
    → /vcp-audit: skips files in dist/ and migrations/
    → /vcp-pre-commit-review: skips changed files in those dirs
    → /vcp-coverage-gaps: skips source files in those dirs

node_modules/** and .git/** are always excluded, even if not listed.

Frameworks: Dependency Checks

The frameworks array tells /vcp-dependency-check which package ecosystem to inspect.

frameworks: ["react", "express", "postgresql"]
    → /vcp-dependency-check: looks for package.json + lockfile
    → Checks npm registry for package existence
    → Flags typosquatting candidates against npm package names

This field is informational for most skills — only /vcp-dependency-check uses it to determine which ecosystem to scan.

Dev Buddy Configuration Flow

Dev Buddy uses the Ralph loop architecture: 6 stages with two nested loops (build inner, UAT outer), multi-AI diversity at each stage, and plan files on disk for state management.

~/.vcp/ai-presets.json          → Defines available AI providers
~/.vcp/dev-buddy.json           → Defines stages, executors, and settings
~/.vcp/dev-buddy-chatroom.json  → Defines chatroom participants

Preset Type: How Stages Execute

The preset type controls how each stage executor runs:

Subscription preset ("anthropic-subscription")
    → Stage runs via: Claude Code Task tool (in-process subagent)
    → Cost: Your existing Claude Code subscription
    → Models available: sonnet, opus, haiku
    → Speed: Fast (no subprocess overhead)
    → Timeout: Managed by Claude Code itself

API preset ("openrouter")
    → Stage runs via: api-task-runner.ts (spawned subprocess)
    → Cost: API credits per token
    → Models available: Whatever the preset's models[] lists
    → Speed: Depends on provider latency
    → Timeout: Configurable via timeout_ms (default 5 min)
    → Enforcement: --allowed-tools structurally restricts tools

CLI preset ("codex-cli")
    → Stage runs via: CLI tool execution (spawned process)
    → Cost: Depends on the CLI tool (e.g., Codex uses OpenAI credits)
    → Models available: Whatever the preset's models[] lists
    → Speed: Variable (CLI overhead + model time)
    → Timeout: Configurable via timeout_ms (default 20 min)
    → Enforcement: Prompt-level only (full native access)

Model Selection: Quality vs Speed vs Cost

Model choice is a tradeoff between quality, speed, and cost:

Model	Strengths	Best for
`opus`	Deepest analysis, best at complex reasoning	Requirements, decomposition
`sonnet`	Fast, good quality, lower cost	Discovery, build, code review, UAT
`haiku`	Fastest, lowest cost	Quick tasks (rarely used in Ralph stages)

Use opus where depth matters (requirements, decomposition) and sonnet where speed matters (build, review, UAT).

For API presets, the model name must exactly match what the provider expects (case-sensitive) and can only contain letters, numbers, dots, underscores, and hyphens (no slashes). For example, claude-sonnet-4-5-20250514 or MiniMax-M2.5.

Ralph Loop Settings

The Ralph loop has three iteration controls:

max_iterations: 10 (default)
    → Maximum fix/re-review iterations across all stages
    → After 10 total re-reviews, the pipeline stops and asks you to intervene

max_build_attempts: 3 (default)
    → Maximum retry attempts per unit in the build stage
    → Each attempt reads the unit plan with fresh context
    → Failed attempts append error details for the next attempt

max_outer_iterations: 3 (default)
    → Maximum UAT → BUILD → CODE REVIEW → UAT outer loop cycles
    → After 3 outer loops, escalates to user

Stage Constraints

Constraint	Stages
Singleton (max 1 executor)	`ralph-build`, `ralph-uat`
Parallel executors allowed	`discovery`, `ralph-requirements`, `decomposition`, `ralph-code-review`

Chatroom: max_rounds and Participants

max_rounds: 3 (default)
    → Up to 3 deliberation rounds seeking consensus
    → More rounds = more chance of convergence, but slower

participants: [{ preset: "minimax", model: "MiniMax-M2.5" }]
    → Each participant receives the topic in parallel
    → Claude always participates (built-in, not in this array)
    → More participants = more diverse perspectives, but higher cost
    → CLI presets require one_shot_args_template to be configured

How VCP + Dev Buddy Interact

When both plugins are installed:

VCP .vcp/config.json exists + valid pluginRoot
    → VCP standards context is injected at session start
    → Dev Buddy's stage executors are VCP-aware (if context was injected)
    → Code reviewers can reference VCP-specific rules in their findings

Without VCP, Dev Buddy falls back to generic analysis. The Ralph loop still works, it just won't reference VCP-specific rules.

How Configuration Works

How Configuration Works

VCP Configuration Flow

Scopes: What Gets Checked

Severity: What Gets Reported

Compliance: Additional Standards

Ignore: What Gets Suppressed

Exclude: Path Filtering

Frameworks: Dependency Checks

Dev Buddy Configuration Flow

Preset Type: How Stages Execute

Model Selection: Quality vs Speed vs Cost

Ralph Loop Settings

Stage Constraints

Chatroom: max_rounds and Participants

How VCP + Dev Buddy Interact

See Also

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Clone this wiki locally