feat: add enableExecutePlan flag for Probe DSL engine

[buger]

Summary

• Add enableExecutePlan boolean flag to support Probe's execute_plan DSL orchestration tool
• Wired through all layers: config types, AI check provider (YAML parsing + known keys), AI review service (ProbeAgent passthrough), and enterprise policy input builder
• Follows the same pattern as the existing enableDelegate flag

Changes

• src/types/config.ts — New enableExecutePlan?: boolean field on AIProviderConfig
• src/providers/ai-check-provider.ts — Read from YAML config + add to known AI keys
• src/ai-review-service.ts — Add to config interface + pass through to ProbeAgent options
• src/enterprise/policy/policy-input-builder.ts — Add to both capability type definitions

YAML Usage

steps:
  deep-analysis:
    type: ai
    prompt: "Comprehensive codebase analysis"
    ai:
      enableExecutePlan: true

Test plan

• npm run build:cli — builds successfully
• npm run test:unit — all 267 suites / 2501 tests pass
• Pre-commit hooks pass (lint, format, build, integration tests)
• Grep confirms enableExecutePlan appears in all expected files

🤖 Generated with Claude Code

[probelabs]

PR Overview: Add enableExecutePlan Flag for Probe DSL Engine

Summary

This PR introduces a new enableExecutePlan boolean configuration flag that enables Probe's execute_plan DSL orchestration tool. The implementation follows the established pattern used for similar feature flags (enableDelegate, enableTasks), wiring the configuration through all relevant layers from YAML config to the ProbeAgent SDK.

Files Changed

• src/types/config.ts (+2): Added enableExecutePlan?: boolean field to AIProviderConfig interface with JSDoc documentation
• src/providers/ai-check-provider.ts (+4): Added YAML config parsing and known keys registration
• src/ai-review-service.ts (+7): Extended AIReviewConfig interface and passed flag to ProbeAgent options
• src/enterprise/policy/policy-input-builder.ts (+2): Added to OPA policy capability interfaces for enterprise enforcement
• tests/unit/providers/ai-check-provider.test.ts (+38): Added test coverage for the new flag

Architecture & Impact Assessment

What This PR Accomplishes

• Adds opt-in support for Probe's execute_plan DSL orchestration tool
• Enables enterprise policy enforcement for this capability via OPA
• Provides a clean configuration interface for users to enable the feature

Key Technical Changes

1. Configuration Layer: Extended AIProviderConfig with optional enableExecutePlan boolean
2. Provider Layer: Parses ai.enableExecutePlan from YAML and validates via known keys
3. Service Layer: Passes flag to ProbeAgent as options.enableExecutePlan
4. Policy Layer: Integrates with enterprise policy engine for capability-based access control

Affected System Components

graph LR
    A[YAML Config] --> B[AICheckProvider]
    B --> C[AIReviewConfig]
    C --> D[ProbeAgent Options]
    D --> E[Probe DSL Engine]
    
    F[Enterprise Policy] --> G[PolicyInputBuilder]
    G --> H[OPA Decision]
    H --> D

Loading

Data Flow:

1. User sets ai.enableExecutePlan: true in .visor.yaml
2. AICheckProvider parses YAML and assigns to AIReviewConfig
3. AIReviewService passes flag to ProbeAgent options
4. Enterprise policy engine can override via capability evaluation
5. ProbeAgent activates execute_plan DSL orchestration tool

Scope Discovery & Context Expansion

Direct Impact

• AI Check Execution: When enabled, activates comprehensive codebase analysis via execute_plan
• Enterprise Policy: Policy engine can control access to this capability
• Configuration: Users enable via YAML: ai.enableExecutePlan: true

Related Components

• ProbeAgent SDK: Receives enableExecutePlan option to activate DSL orchestration
• analyze_all tool: PR description indicates execute_plan "replaces analyze_all when enabled"
• Workspace Isolation: Works with existing allowedFolders and workspace path configuration

Testing Coverage

• Build succeeds: npm run build:cli
• All 267 test suites / 2501 unit tests pass
• New test added: should pass enableExecutePlan flag to service
• Pre-commit hooks pass (lint, format, build, integration tests)

Usage Example

steps:
  deep-analysis:
    type: ai
    prompt: "Comprehensive codebase analysis"
    ai:
      enableExecutePlan: true

Review Notes

• Pattern Consistency: Implementation follows exact same pattern as enableDelegate
• Type Safety: Properly typed as optional boolean throughout the stack
• Policy Integration: Enterprise policy enforcement properly wired
• No Breaking Changes: Feature is opt-in via configuration flag
• Documentation: JSDoc comments explain purpose clearly

Recommendation: This is a straightforward feature addition with minimal risk. The implementation is consistent with existing patterns and includes appropriate test coverage.

Metadata

• Review Effort: 1 / 5
• Primary Label: feature

---

Powered by Visor from Probelabs

Last updated: 2026-02-16T09:01:54.035Z | Triggered by: pr_updated | Commit: fca13e7

💡 TIP: You can chat with Visor using /visor ask <your question>

[probelabs]

✅ Security Check Passed

No security issues found – changes LGTM.

✅ Architecture Check Passed

No architecture issues found – changes LGTM.

✅ Performance Check Passed

No performance issues found – changes LGTM.

Quality Issues (7)

Severity	Location	Issue
🟢 Info	tests/unit/providers/ai-check-provider.test.ts:247	Test uses magic number 0 for totalIssues and criticalIssues. While zero may be semantically valid, using named constants like EXPECTED_NO_ISSUES would improve test clarity and intent. 💡 Suggestion Use named constants: const EXPECTED_NO_ISSUES = 0; const EXPECTED_NO_CRITICAL_ISSUES = 0; to make test assertions self-documenting.
🟢 Info	src/ai-review-service.ts:1844	Using '(options as any)' bypasses TypeScript type checking. This pattern is repeated throughout the codebase and reduces type safety. 💡 Suggestion Define a proper interface for ProbeAgent options that includes enableExecutePlan, enableDelegate, enableTasks, and other optional flags. This would improve type safety and make the API contract explicit.
🟡 Warning	tests/unit/providers/ai-check-provider.test.ts:247	Test uses magic number 90 for overallScore without semantic meaning. The value appears arbitrary and may be reverse-engineered from implementation rather than derived from requirements. 💡 Suggestion Define a named constant or derive the expected value from test inputs. For example: const EXPECTED_PERFECT_SCORE = 100; or use a meaningful variable name that explains why this specific value is expected.
🟡 Warning	tests/unit/providers/ai-check-provider.test.ts:244	Test suite only covers positive case (enableExecutePlan: true). Missing negative test cases for invalid inputs, undefined values, false values, and error conditions. 💡 Suggestion Add test cases for: 1) enableExecutePlan: false (explicitly disabled), 2) enableExecutePlan: undefined (not set), 3) enableExecutePlan with invalid type (string, number, object), 4) enableExecutePlan combined with conflicting flags (e.g., disableTools: true).
🟡 Warning	tests/unit/providers/ai-check-provider.test.ts:244	Test does not verify edge cases or error scenarios. The test only validates the happy path where the flag is passed through correctly. 💡 Suggestion Add tests for edge cases: 1) enableExecutePlan with null/undefined values, 2) enableExecutePlan with conflicting configuration (disableTools: true), 3) enableExecutePlan behavior when policy engine denies the capability, 4) Type coercion tests (string 'true' vs boolean true).
🟡 Warning	src/providers/ai-check-provider.ts:836	Using 'aiAny.enableExecutePlan as boolean' without validation. If the YAML config contains a non-boolean value (e.g., string 'true'), it will be incorrectly cast. 💡 Suggestion Add proper type validation: if (typeof aiAny.enableExecutePlan === 'boolean') { aiConfig.enableExecutePlan = aiAny.enableExecutePlan; } else if (aiAny.enableExecutePlan !== undefined) { throw new Error('ai.enableExecutePlan must be a boolean'); }
🟡 Warning	src/enterprise/policy/policy-input-builder.ts:235	The enableExecutePlan field was added to OpaInput capability interfaces but there are no tests to verify policy enforcement for this new capability. 💡 Suggestion Add integration tests to verify that: 1) Policy engine correctly evaluates enableExecutePlan capability, 2) Policy can deny execute_plan when enableExecutePlan: true in config, 3) Policy can allow execute_plan when configured, 4) Policy decision is properly passed to ProbeAgent.

---

Powered by Visor from Probelabs

Last updated: 2026-02-16T09:01:56.884Z | Triggered by: pr_updated | Commit: fca13e7

💡 TIP: You can chat with Visor using /visor ask <your question>