@vfarcic/dot-ai 0.178.0 → 0.180.0

package/scripts/dot-ai.nu

@@ -6,7 +6,7 @@
 # > main apply dot-ai-controller
 # > main apply dot-ai-controller --controller-version 0.17.0
 def "main apply dot-ai-controller" [
-    --controller-version = "0.37.0"
+    --controller-version = "0.39.0"
 ] {
 
     (
@@ -16,7 +16,38 @@ def "main apply dot-ai-controller" [
             --wait
     )
 
+    # Create CapabilityScanConfig for autonomous capability discovery
+    "apiVersion: dot-ai.devopstoolkit.live/v1alpha1
+kind: CapabilityScanConfig
+metadata:
+  name: default-scan
+  namespace: dot-ai
+spec:
+  mcp:
+    endpoint: http://dot-ai-mcp.dot-ai.svc.cluster.local:3456/api/v1/tools/manageOrgData
+    authSecretRef:
+      name: dot-ai-secrets
+      key: auth-token
+" | kubectl apply --filename -
+
+    # Create ResourceSyncConfig for semantic search across cluster resources
+    "apiVersion: dot-ai.devopstoolkit.live/v1alpha1
+kind: ResourceSyncConfig
+metadata:
+  name: default-sync
+  namespace: dot-ai
+spec:
+  mcpEndpoint: http://dot-ai-mcp.dot-ai.svc.cluster.local:3456/api/v1/resources/sync
+  mcpAuthSecretRef:
+    name: dot-ai-secrets
+    key: auth-token
+  debounceWindowSeconds: 10
+  resyncIntervalMinutes: 60
+" | kubectl apply --filename -
+
     print $"DevOps AI Controller (ansi yellow_bold)($controller_version)(ansi reset) installed in (ansi yellow_bold)dot-ai(ansi reset) namespace"
+    print $"CapabilityScanConfig created for autonomous capability discovery"
+    print $"ResourceSyncConfig created for semantic search across cluster resources"
 
 }
 
@@ -29,13 +60,14 @@ def "main apply dot-ai-controller" [
 def "main apply dot-ai" [
     --anthropic-api-key = "",
     --openai-api-key = "",
+    --auth-token = "my-secret-token",
     --provider = "anthropic",
     --model = "claude-haiku-4-5-20251001",
     --ingress-enabled = true,
     --ingress-class = "nginx",
     --host = "dot-ai.127.0.0.1.nip.io",
-    --version = "0.171.0",
-    --controller-version = "0.37.0",
+    --version = "0.179.0",
+    --controller-version = "0.39.0",
     --enable-tracing = false
 ] {
 
@@ -64,13 +96,13 @@ def "main apply dot-ai" [
         []
     }
 
-    main apply dot-ai-controller --controller-version $controller_version
-
+    # Install MCP first (creates service and secrets needed by controller's CapabilityScanConfig)
     (
         helm upgrade --install dot-ai-mcp
             $"oci://ghcr.io/vfarcic/dot-ai/charts/dot-ai:($version)"
             --set $"secrets.anthropic.apiKey=($anthropic_key)"
             --set $"secrets.openai.apiKey=($openai_key)"
+            --set $"secrets.auth.token=($auth_token)"
             --set $"ai.provider=($provider)"
             --set $"ai.model=($model)"
             --set $"ingress.enabled=($ingress_enabled)"
@@ -82,8 +114,14 @@ def "main apply dot-ai" [
             --wait
     )
 
+    # Install controller after MCP (CapabilityScanConfig references MCP service and secrets)
+    main apply dot-ai-controller --controller-version $controller_version
+
     print $"DevOps AI Toolkit is available at (ansi yellow_bold)http://($host)(ansi reset)"
 
+    # Update .env with auth token for MCP clients
+    $"DOT_AI_AUTH_TOKEN=($auth_token)\n" | save --force .env
+
     if $enable_tracing {
         print $"Tracing enabled: Traces will be sent to (ansi yellow_bold)Jaeger in observability namespace(ansi reset)"
     }

package/prompts/visualize-query.md

@@ -1,113 +0,0 @@
-# Query Visualization Generator
-
-You are a Kubernetes cluster visualization expert. Analyze the query results and generate visualizations that reveal relationships and patterns in the data.
-
-## User Query
-
-{{{intent}}}
-
-## Query Results
-
-{{{toolCallsData}}}
-
-## Your Task
-
-Thoroughly analyze the query results and surface everything valuable you can find. This includes but is not limited to:
-- Relationships between resources
-- Resource status and health
-- Patterns and architectural insights
-- Anything else worth knowing about these resources
-
-If the provided data isn't sufficient for deep analysis, use the available tools to gather additional information. Don't limit yourself to what's already in the context - investigate further if it would produce more valuable insights.
-
-## Analysis Approach
-
-Include both obvious and non-obvious findings:
-
-### Level 1: Obvious Relationships (include these)
-- `metadata.ownerReferences` links
-- Label selectors matching labels
-- Explicit name references in spec fields
-
-### Level 2: Deep Analysis (this is where you add unique value)
-Go beyond the obvious. Analyze the data thoroughly. Here are some examples - but don't limit yourself to these:
-
-- Inferred dependencies from env vars, config names, port numbers, mount paths
-- Architectural patterns like sidecars, init containers, deployment strategies
-- Potential issues: missing limits, no health checks, security concerns, single points of failure
-- Implicit relationships from naming patterns, shared labels, operator conventions
-- Capacity and scaling considerations
-
-These are just examples. Analyze EVERYTHING in the data - annotations, labels, all spec fields, status conditions, anything. Surface whatever is valuable. The non-obvious insights are what make this worthwhile.
-
-Do NOT assume what resources exist. Analyze only what's in the data.
-
-## Output Format
-
-Respond with ONLY a JSON object (no markdown code fences, no extra text):
-
-{
-  "title": "Descriptive title based on what was found",
-  "visualizations": [...],
-  "insights": [...]
-}
-
-## Visualization Types
-
-Generate as many or as few visualizations as add value. You can:
-- Include multiple visualizations of the same type (e.g., several mermaid diagrams for different aspects)
-- Skip any type entirely if it doesn't add value for this data
-- Use whatever combination best represents what you found
-
-Each visualization:
-
-```
-{
-  "id": "unique-id",
-  "label": "Tab Label",
-  "type": "mermaid" | "table" | "cards" | "code",
-  "content": <type-specific-content>
-}
-```
-
-### mermaid
-For showing relationships between resources.
-- `content`: Valid Mermaid diagram string
-- Use `graph TD` or `graph LR` depending on relationship type
-- Use subgraphs to group by namespace or logical grouping
-- Arrows: `-->` for ownership/direct, `-.->` for inferred/indirect
-- Keep readable - summarize similar resources rather than showing every instance
-
-### table
-For listing resources with their properties.
-- `content`: `{ "headers": ["Col1", "Col2"], "rows": [["val1", "val2"]] }`
-- Choose columns relevant to the resource types present
-- Include status/condition information when available
-
-### cards
-For highlighting individual resources with status.
-- `content`: `[{ "id": "unique", "title": "Name", "description": "Status info", "tags": ["tag1"] }]`
-- Use for resources where individual status matters
-- Tags should reflect actual state from the data
-
-### code
-For showing raw data or configurations.
-- `content`: `{ "language": "yaml" | "json", "code": "..." }`
-- Use sparingly - only when raw output adds value
-
-## Insights
-
-Generate insights that add value beyond what someone could see by just reading the raw data. Prioritize non-obvious findings over summaries of what's there.
-
-Each insight should:
-- Reference specific resource names from the data
-- Explain WHY it matters, not just WHAT you found
-- Be actionable when highlighting issues
-
-## Rules
-
-1. **Data-driven only** - Generate visualizations based on actual resources present
-2. **Skip empty visualizations** - Don't include a topology diagram if there are no relationships
-3. **Valid output** - Ensure Mermaid syntax is correct and JSON is valid
-4. **Resource-agnostic** - Handle any Kubernetes resource type (core, CRDs, operators)
-5. **JSON only** - No markdown fences, no explanations outside the JSON structure