@vfarcic/dot-ai 0.80.0 → 0.82.0

package/dist/core/schema.js

@@ -821,7 +821,7 @@ class ResourceRecommender {
             if (this.policyService) {
                 try {
                     const resourceContext = solution.resources.map(r => `${r.kind} ${r.description}`).join(' ');
-                    const policyResults = await this.policyService.searchPolicyIntents(`${intent} ${resourceContext}`, { limit: 25 });
+                    const policyResults = await this.policyService.searchPolicyIntents(`${intent} ${resourceContext}`, { limit: 50 });
                     relevantPolicyResults = policyResults.map(result => ({
                         policy: result.data,
                         score: result.score,

package/dist/core/unified-creation-session.js

@@ -839,7 +839,7 @@ Please try again or modify your policy description.`,
         const capabilityService = new capability_vector_service_1.CapabilityVectorService();
         // Use existing searchCapabilities function - no fallback, let it throw if it fails
         const searchResults = await capabilityService.searchCapabilities(searchQuery, {
-            limit: 25 // Higher limit to get more relevant resources
+            limit: 50 // Higher limit to get more relevant resources - aligns with recommendation tool
         });
         if (searchResults.length === 0) {
             throw new Error(`No relevant capabilities found for policy description: "${policyDescription}"`);

package/dist/tools/recommend.d.ts

@@ -5,7 +5,7 @@ import { z } from 'zod';
 import { DotAI } from '../core/index';
 import { Logger } from '../core/error-handling';
 export declare const RECOMMEND_TOOL_NAME = "recommend";
-export declare const RECOMMEND_TOOL_DESCRIPTION = "Deploy, create, setup, install, or run applications, infrastructure, and services on Kubernetes with AI recommendations. Describe what you want to deploy.";
+export declare const RECOMMEND_TOOL_DESCRIPTION = "Deploy, create, setup, install, or run applications, infrastructure, and services on Kubernetes with AI recommendations. Describe what you want to deploy. Does NOT handle policy creation, organizational patterns, or resource capabilities - use manageOrgData for those.";
 export declare const RECOMMEND_TOOL_INPUT_SCHEMA: {
     intent: z.ZodString;
     final: z.ZodOptional<z.ZodBoolean>;

package/dist/tools/recommend.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"recommend.d.ts","sourceRoot":"","sources":["../../src/tools/recommend.ts"],"names":[],"mappings":"AAAA;;GAEG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAIxB,OAAO,EAAE,KAAK,EAAE,MAAM,eAAe,CAAC;AACtC,OAAO,EAAE,MAAM,EAAE,MAAM,wBAAwB,CAAC;AAQhD,eAAO,MAAM,mBAAmB,cAAc,CAAC;AAC/C,eAAO,MAAM,0BAA0B,+JAA+J,CAAC;AAGvM,eAAO,MAAM,2BAA2B;;;CAGvC,CAAC;AA2EF;;GAEG;AACH,wBAAsB,mBAAmB,CACvC,IAAI,EAAE;IAAE,MAAM,EAAE,MAAM,CAAC;IAAC,KAAK,CAAC,EAAE,OAAO,CAAA;CAAE,EACzC,KAAK,EAAE,KAAK,EACZ,MAAM,EAAE,MAAM,EACd,SAAS,EAAE,MAAM,GAChB,OAAO,CAAC;IAAE,OAAO,EAAE;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAA;KAAE,EAAE,CAAA;CAAE,CAAC,CAoQxD"}
+{"version":3,"file":"recommend.d.ts","sourceRoot":"","sources":["../../src/tools/recommend.ts"],"names":[],"mappings":"AAAA;;GAEG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAIxB,OAAO,EAAE,KAAK,EAAE,MAAM,eAAe,CAAC;AACtC,OAAO,EAAE,MAAM,EAAE,MAAM,wBAAwB,CAAC;AAQhD,eAAO,MAAM,mBAAmB,cAAc,CAAC;AAC/C,eAAO,MAAM,0BAA0B,iRAAiR,CAAC;AAGzT,eAAO,MAAM,2BAA2B;;;CAGvC,CAAC;AA2EF;;GAEG;AACH,wBAAsB,mBAAmB,CACvC,IAAI,EAAE;IAAE,MAAM,EAAE,MAAM,CAAC;IAAC,KAAK,CAAC,EAAE,OAAO,CAAA;CAAE,EACzC,KAAK,EAAE,KAAK,EACZ,MAAM,EAAE,MAAM,EACd,SAAS,EAAE,MAAM,GAChB,OAAO,CAAC;IAAE,OAAO,EAAE;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAA;KAAE,EAAE,CAAA;CAAE,CAAC,CAoQxD"}

package/dist/tools/recommend.js

@@ -49,7 +49,7 @@ const crypto = __importStar(require("crypto"));
 const session_utils_1 = require("../core/session-utils");
 // Tool metadata for direct MCP registration
 exports.RECOMMEND_TOOL_NAME = 'recommend';
-exports.RECOMMEND_TOOL_DESCRIPTION = 'Deploy, create, setup, install, or run applications, infrastructure, and services on Kubernetes with AI recommendations. Describe what you want to deploy.';
+exports.RECOMMEND_TOOL_DESCRIPTION = 'Deploy, create, setup, install, or run applications, infrastructure, and services on Kubernetes with AI recommendations. Describe what you want to deploy. Does NOT handle policy creation, organizational patterns, or resource capabilities - use manageOrgData for those.';
 // Zod schema for MCP registration
 exports.RECOMMEND_TOOL_INPUT_SCHEMA = {
     intent: zod_1.z.string().min(1).max(1000).describe('What the user wants to deploy, create, setup, install, or run on Kubernetes. Examples: "deploy web application", "create PostgreSQL database", "setup Redis cache", "install Prometheus monitoring", "configure Ingress controller", "provision storage volumes", "launch MongoDB operator", "run Node.js API", "setup CI/CD pipeline", "create load balancer", "install Grafana dashboard", "deploy React frontend"'),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vfarcic/dot-ai",
-  "version": "0.80.0",
+  "version": "0.82.0",
   "description": "AI-powered development productivity platform that enhances software development workflows through intelligent automation and AI-driven assistance",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/prompts/kyverno-generation.md

@@ -27,18 +27,72 @@ You are a Kubernetes governance expert specializing in Kyverno policy generation
 **RETRY CONTEXT**: If this is a retry attempt (indicated by previous attempt details above), analyze the validation errors carefully and fix the specific issues identified. Common validation failures include:
 - Invalid YAML syntax
 - Invalid CEL expressions using `request.object` instead of `object`
+- **Invalid message template variables** - Kyverno has strict limits on variable substitution in messages
 - References to non-existent fields in resource schemas
 - Incorrect resource kind/apiVersion combinations
 - Using invalid Kyverno match fields like `apiGroups`, `versions`, or `apiVersions` (use Group/Version/Kind format in kinds array)
 - kubectl dry-run server-side validation failures
 - CEL compilation errors at runtime due to undefined fields
 
+## ⚠️ **CRITICAL MESSAGE TEMPLATE RULES**
+
+**IMPORTANT**: Kyverno message templates have strict variable validation requirements. Follow these rules to avoid validation failures:
+
+**❌ NEVER use these patterns in messages:**
+```yaml
+# These will cause validation failures:
+message: "Current region: {{ object.spec.forProvider.region || 'not specified' }}"
+message: "Field value: {{ object.spec.field || 'missing' }}"
+message: "Invalid image: {{ object.spec.container.image }}"
+```
+
+**✅ ALWAYS use static descriptive messages:**
+```yaml
+# These will work correctly:
+message: "Resources must be deployed in the us-east1 region for compliance"
+message: "Container images must not use the 'latest' tag"  
+message: "All pods must define resource limits"
+```
+
+**Rule**: Keep error messages **static and descriptive** without dynamic field references. Focus on explaining the policy requirement clearly rather than showing current values.
+
+## 🔧 **CEL EXPRESSION BEST PRACTICES**
+
+**Critical patterns for robust CEL expressions:**
+
+**✅ Always check field existence before accessing:**
+```yaml
+# CORRECT - Check field exists first
+expression: >-
+  has(object.spec) && has(object.spec.forProvider) && 
+  has(object.spec.forProvider.region) && 
+  object.spec.forProvider.region == 'us-east1'
+
+# CORRECT - Alternative safe pattern  
+expression: >-
+  !has(object.spec.forProvider.region) || 
+  object.spec.forProvider.region == 'us-east1'
+```
+
+**❌ Never access fields without checking existence:**
+```yaml
+# WRONG - Will fail if fields don't exist
+expression: object.spec.forProvider.region == 'us-east1'
+expression: object.spec.initProvider.region == 'us-east1'
+```
+
+**Field Existence Patterns:**
+- **Required fields**: Use `has(object.spec.field) && object.spec.field == 'value'`
+- **Optional fields**: Use `!has(object.spec.field) || object.spec.field == 'value'`
+- **Nested fields**: Check each level: `has(object.spec) && has(object.spec.nested) && has(object.spec.nested.field)`
+
 ## 🛡️ KYVERNO POLICY GENERATION PRINCIPLES
 
 **Core Requirements:**
 - **Single ClusterPolicy** - Generate one ClusterPolicy with multiple rules if needed to handle different resource schemas
 - **CEL Expressions Only** - Use CEL (Common Expression Language) for all validation logic, never JMESPath patterns
 - **Intelligent Resource Selection** - Only target resource types where the policy intent logically applies
+- **Provider-Aware Filtering** - Only include resources matching the provider context from the policy intent
 - **Schema-Accurate Targeting** - Only reference fields that actually exist in the targeted resource schemas
 - **Multiple Rules for Different Schemas** - Use separate rules when different resource types have different field structures
 - **New Resource Targeting** - Set `background: false` to apply only to new/updated resources
@@ -114,22 +168,63 @@ Create a mental checklist for EVERY schema provided:
 - NO SHORTCUTS: Don't skip resources because they're custom or unfamiliar
 - FIELD-BASED DECISIONS ONLY: Base inclusion solely on presence of relevant fields
 
-**VALIDATION CHECK**: Before finalizing the policy, verify that you have generated rules for ALL resources with policy-relevant fields. If any resource with relevant fields lacks a rule, the policy is INCOMPLETE and INVALID.
+**VALIDATION CHECK**: Before finalizing the policy, verify that you have generated rules for ALL resources with policy-relevant fields AND matching provider context. If any resource with relevant fields and matching provider lacks a rule, the policy is INCOMPLETE and INVALID.
+
+## 🌐 UNIVERSAL PROVIDER FILTERING
+
+**CRITICAL**: If the policy intent mentions ANY provider context (cloud providers, deployment targets), you MUST filter resources to include ONLY those matching the specified context.
+
+### Provider Context Extraction
+
+**Extract provider/deployment context from policy intent:**
+
+- **Cloud Providers**: "AWS", "GCP", "Azure", "UpCloud", "DigitalOcean", etc.
+- **Multi-Cloud**: "multi-cloud", "AWS and Azure", "across providers"  
+- **Kubernetes-Native**: "in Kubernetes", "Kubernetes cluster", "native", "in-cluster"
+- **External Services**: "cloud services", "managed services"
+
+### Resource Provider Detection
+
+**Analyze each resource schema to determine provider affiliation:**
+
+1. **CRD Description**: Look for provider names in main description
+2. **Field Descriptions**: Check field docs for provider mentions/regions/limitations
+3. **Provider Sections**: Look for `spec.aws`, `spec.gcp`, `spec.upcloud` etc.
+4. **API Groups**: Use domain patterns as fallback (`*.gcp.`, `*.upcloud.com`)
+5. **Core Resources**: Pod, Service, etc. are always Kubernetes-native
+
+### Resource Classification
+
+- **External Cloud Services**: Provision services in cloud providers (RDS, Cloud SQL, etc.)
+- **Kubernetes-Native**: Run workloads inside cluster (CNPG, core resources, etc.)  
+- **Multi-Cloud**: Support multiple providers
+
+### Provider Filtering Rules
+
+- **Cloud Provider Intent**: Include resources that support the specified provider
+- **Kubernetes-Native Intent**: Include resources that run in-cluster
+- **Provider-Agnostic Intent**: Include all relevant resources
 
 ## 🔍 EXPLICIT RESOURCE ANALYSIS REQUIREMENT
 
 **MANDATORY SCHEMA ACCOUNTING**: Before generating the policy, you MUST explicitly account for EVERY schema provided. Include this analysis as YAML comments at the top of the generated policy.
 
 **For EVERY schema in the "Available Resource Schemas" section above:**
-Include a concise comment line in format: `ResourceName: HAS field.path → MUST generate rule` or `ResourceName: NO relevant fields → Can skip`
+Include a concise comment line explaining why each resource is included or skipped, considering BOTH field relevance AND provider context.
+
+**Comment Format Examples:**
+- `ResourceName: HAS field.path + supports GCP → MUST generate rule`
+- `ResourceName: NO relevant fields → Can skip`  
+- `ResourceName: HAS field.path but UpCloud only → Can skip (provider mismatch)`
+- `ResourceName: HAS field.path + Kubernetes-native → Can skip (cloud services intent)`
+- `ResourceName: HAS field.path + multi-cloud → MUST generate rule`
 
-**CRITICAL EXAMPLES** (adapt to your actual policy):
-- If analyzing a resource with `spec.image` field → MUST generate rule
-- If analyzing a resource with `spec.containers[].image` field → MUST generate rule  
-- If analyzing a resource with `spec.template.spec.containers[].image` field → MUST generate rule
-- If analyzing a resource with only networking fields → Can skip (for non-networking policies)
+**CRITICAL ANALYSIS** (adapt to your actual policy and intent):
+- **Field Relevance**: Does the resource have fields matching the policy requirements?
+- **Provider Context**: Does the resource support the providers/deployment targets mentioned in the intent?
+- **Both Required**: Resource needs BOTH relevant fields AND matching provider context to require a rule
 
-**FAILURE TO ANALYZE = INVALID POLICY**: If you generate a policy without systematically considering every schema, the policy is incomplete and violates the requirements.
+**FAILURE TO ANALYZE = INVALID POLICY**: If you generate a policy without systematically considering every schema for both field relevance and provider context, the policy is incomplete and violates the requirements.
 
 **OUTPUT FORMAT**: Include your systematic schema analysis as YAML comments at the beginning of the policy file, followed by the clean YAML manifest.
 
@@ -152,7 +247,7 @@ Include a concise comment line in format: `ResourceName: HAS field.path → MUST
 **CRITICAL CEL SYNTAX RULES:**
 - ✅ **CORRECT**: `object.spec.containers` - Use `object` to reference the resource being validated
 - ❌ **WRONG**: `request.object.spec.containers` - Do NOT use `request.object` prefix  
-- ✅ **CORRECT**: `has(object.metadata.labels['app'])`
+- ✅ **CORRECT**: `'app' in object.metadata.labels`
 - ❌ **WRONG**: `has(request.object.metadata.labels['app'])`
 
 **KYVERNO MATCH SCHEMA RULES:**
@@ -304,11 +399,12 @@ spec:
 **OUTPUT FORMAT EXAMPLE**:
 # MANDATORY SCHEMA-BY-SCHEMA ANALYSIS
 #
-# StatefulSet: HAS spec.template.spec.containers[].image → MUST generate rule  
-# Pod: HAS spec.containers[].image → MUST generate rule
+# sqls.devopstoolkit.live: HAS spec.region + supports GCP → MUST generate rule
+# manageddatabasemysqls.database.upcloud.com: HAS spec.region but UpCloud only → Can skip (provider mismatch)  
+# Pod: HAS spec.containers[].image + Kubernetes-native → Can skip (cloud services intent)
 # ConfigMap: NO relevant fields → Can skip
 #
-# RESOURCES REQUIRING VALIDATION RULES: StatefulSet, Pod
+# RESOURCES REQUIRING VALIDATION RULES: sqls.devopstoolkit.live
 #
 apiVersion: kyverno.io/v1
 kind: ClusterPolicy