@vfarcic/dot-ai 0.19.0 → 0.21.0

package/dist/tools/version.d.ts

@@ -14,15 +14,12 @@ export declare const VERSION_TOOL_INPUT_SCHEMA: {
 };
 export interface VersionInfo {
     version: string;
-    gitCommit?: string;
-    gitBranch?: string;
-    buildTime: string;
     nodeVersion: string;
     platform: string;
     arch: string;
 }
 /**
- * Get version information from package.json and git
+ * Get version information from package.json
  */
 export declare function getVersionInfo(): VersionInfo;
 /**

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

@@ -1 +1 @@
-{"version":3,"file":"version.d.ts","sourceRoot":"","sources":["../../src/tools/version.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAKH,OAAO,EAAE,MAAM,EAAE,MAAM,wBAAwB,CAAC;AAEhD,eAAO,MAAM,iBAAiB,YAAY,CAAC;AAC3C,eAAO,MAAM,wBAAwB,iEAAiE,CAAC;AACvG,eAAO,MAAM,yBAAyB;;;;;CAKrC,CAAC;AAEF,MAAM,WAAW,WAAW;IAC1B,OAAO,EAAE,MAAM,CAAC;IAChB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,SAAS,EAAE,MAAM,CAAC;IAClB,WAAW,EAAE,MAAM,CAAC;IACpB,QAAQ,EAAE,MAAM,CAAC;IACjB,IAAI,EAAE,MAAM,CAAC;CACd;AAED;;GAEG;AACH,wBAAgB,cAAc,IAAI,WAAW,CAyB5C;AAED;;GAEG;AACH,wBAAsB,iBAAiB,CACrC,IAAI,EAAE,GAAG,EACT,MAAM,EAAE,MAAM,EACd,SAAS,EAAE,MAAM,GAChB,OAAO,CAAC,GAAG,CAAC,CAuBd"}
+{"version":3,"file":"version.d.ts","sourceRoot":"","sources":["../../src/tools/version.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAIH,OAAO,EAAE,MAAM,EAAE,MAAM,wBAAwB,CAAC;AAEhD,eAAO,MAAM,iBAAiB,YAAY,CAAC;AAC3C,eAAO,MAAM,wBAAwB,iEAAiE,CAAC;AACvG,eAAO,MAAM,yBAAyB;;;;;CAKrC,CAAC;AAEF,MAAM,WAAW,WAAW;IAC1B,OAAO,EAAE,MAAM,CAAC;IAChB,WAAW,EAAE,MAAM,CAAC;IACpB,QAAQ,EAAE,MAAM,CAAC;IACjB,IAAI,EAAE,MAAM,CAAC;CACd;AAED;;GAEG;AACH,wBAAgB,cAAc,IAAI,WAAW,CAqB5C;AAED;;GAEG;AACH,wBAAsB,iBAAiB,CACrC,IAAI,EAAE,GAAG,EACT,MAAM,EAAE,MAAM,EACd,SAAS,EAAE,MAAM,GAChB,OAAO,CAAC,GAAG,CAAC,CAuBd"}

package/dist/tools/version.js

@@ -10,7 +10,6 @@ exports.getVersionInfo = getVersionInfo;
 exports.handleVersionTool = handleVersionTool;
 const fs_1 = require("fs");
 const path_1 = require("path");
-const child_process_1 = require("child_process");
 exports.VERSION_TOOL_NAME = 'version';
 exports.VERSION_TOOL_DESCRIPTION = 'Get version information for the DevOps AI Toolkit MCP server';
 exports.VERSION_TOOL_INPUT_SCHEMA = {
@@ -20,27 +19,24 @@ exports.VERSION_TOOL_INPUT_SCHEMA = {
     additionalProperties: false
 };
 /**
- * Get version information from package.json and git
+ * Get version information from package.json
  */
 function getVersionInfo() {
-    // Read package.json version
-    const packageJsonPath = (0, path_1.join)(process.cwd(), 'package.json');
-    const packageJson = JSON.parse((0, fs_1.readFileSync)(packageJsonPath, 'utf8'));
-    // Get git information
-    let gitCommit;
-    let gitBranch;
+    // Find package.json relative to this module's location (MCP server's installation)
+    let packageJson;
     try {
-        gitCommit = (0, child_process_1.execSync)('git rev-parse HEAD', { encoding: 'utf8' }).trim();
-        gitBranch = (0, child_process_1.execSync)('git rev-parse --abbrev-ref HEAD', { encoding: 'utf8' }).trim();
+        // Get the directory where this module is installed
+        // __dirname points to the compiled JS location, go up to find package.json
+        const mcpServerDir = (0, path_1.join)(__dirname, '..');
+        const packageJsonPath = (0, path_1.join)(mcpServerDir, 'package.json');
+        packageJson = JSON.parse((0, fs_1.readFileSync)(packageJsonPath, 'utf8'));
     }
     catch (error) {
-        // Git info not available (e.g., not a git repo or git not installed)
+        // If package.json not found, use unknown version
+        packageJson = { version: 'unknown' };
     }
     return {
         version: packageJson.version,
-        gitCommit,
-        gitBranch,
-        buildTime: new Date().toISOString(),
         nodeVersion: process.version,
         platform: process.platform,
         arch: process.arch

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vfarcic/dot-ai",
-  "version": "0.19.0",
+  "version": "0.21.0",
   "description": "Universal Kubernetes application deployment agent with CLI and MCP interfaces",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/prompts/resource-selection.md

@@ -20,7 +20,7 @@ Select all resources that could be relevant for this intent. Consider:
 - Platform-specific resources (e.g., Crossplane, Knative, Istio, ArgoCD) that could simplify the deployment
 - **CRD Selection Priority**: If you see multiple CRDs from the same group with similar purposes (like "App" and "AppClaim"), include the namespace-scoped ones (marked as "Namespaced: true") rather than cluster-scoped ones, as they're more appropriate for application deployments
 
-Don't limit yourself - if the intent is complex, select as many resources as needed.
+Don't limit yourself - if the intent is complex, select as many resources as needed. **Be extra inclusive** - the detailed schema analysis phase will filter out inappropriate resources, so it's better to include more candidates initially.
 
 ## Response Format
 

package/prompts/resource-solution-ranking.md

@@ -29,16 +29,48 @@ Consider:
 - **Custom Resource Definitions (CRDs)** that may provide simpler, higher-level abstractions
 - Platform operators (Crossplane, Knative, etc.) that might offer better user experience
 - User experience - simpler declarative approaches often score higher than complex multi-resource solutions
+- **Schema-based capability analysis**: Examine the actual resource schema fields to determine what capabilities each resource truly supports
+
+## Schema-Based Capability Analysis
+
+**CRITICAL**: Before scoring any solution, analyze all resource schemas in that solution to determine actual capabilities:
+
+### Capability Detection Method
+For each resource schema in the solution, examine field patterns that indicate capabilities:
+- **Field names and types**: Look for schema fields whose names, descriptions, or types relate to the user's intent
+- **Nested structures**: Check for complex objects that suggest advanced functionality
+- **Reference patterns**: Identify fields that reference other resources or external systems
+- **Configuration options**: Note fields that allow customization relevant to the user's needs
+
+### Intent-Schema Matching Process
+1. **Extract keywords** from user intent (e.g., "storage", "network", "scale", "database", "monitor")
+2. **Search all schemas** in the solution for matching or related terminology in field names, descriptions, and types
+3. **Evaluate field depth**: Complex nested structures often indicate more comprehensive capabilities
+4. **Check for extension points**: Fields that allow custom configuration or references to external resources
+
+### Solution Scoring Based on Schema Analysis
+- **High relevance (80-100 points)**: Schemas contain multiple fields directly related to user intent
+- **Medium relevance (50-79 points)**: Schemas contain some fields that could support user intent
+- **Low relevance (20-49 points)**: Schemas have minimal or indirect support for user intent
+- **Reject (0-19 points)**: Schemas lack any fields related to user intent - DO NOT include these solutions
 
 ## CRD Preference Guidelines
 
 When evaluating CRDs vs standard Kubernetes resources:
-- **Prefer CRDs with matching capabilities**: If a CRD's listed capabilities directly address the user's specific needs, it should score higher than manually combining multiple standard resources
-- **Favor purpose-built solutions**: CRDs designed for specific use cases should score higher than generic resource combinations when the use case aligns
-- **Value comprehensive functionality**: A single CRD that handles multiple related concerns (deployment + networking + scaling) should score higher than manually orchestrating separate resources for the same outcome
+- **Prefer CRDs with matching capabilities**: If a CRD's schemas directly address the user's specific needs, it should score higher than manually combining multiple standard resources
+- **Favor purpose-built solutions**: CRDs designed for specific use cases should score higher than generic resource combinations when the use case aligns AND the schemas support the required capabilities
+- **Value comprehensive functionality**: A single CRD that handles multiple related concerns should score higher than manually orchestrating separate resources for the same outcome
 - **Consider operational simplicity**: CRDs that provide intuitive, domain-specific interfaces should be preferred over complex multi-resource configurations
 - **Give preference to platform abstractions**: For application deployment scenarios, purpose-built CRDs with comprehensive application platform features should be weighted more favorably than basic resources requiring manual orchestration
-- **Match scope to intent**: Only prefer CRDs when their documented capabilities genuinely align with what the user is trying to achieve
+- **Match scope to intent**: Only prefer CRDs when their schemas genuinely align with what the user is trying to achieve
+
+## Solution Filtering Rules
+
+**IMPORTANT**: To avoid rejecting all solutions:
+- **Be inclusive initially**: The resource selection phase should identify MORE potential candidates, not fewer
+- **Apply schema filtering here**: Only reject solutions where schemas completely lack relevant fields
+- **Provide alternatives**: If rejecting solutions, always provide at least 2-3 viable alternatives
+- **Explain rejections**: When scoring low, clearly explain which schema fields are missing
 
 ## Response Format