@vfarcic/dot-ai 0.116.0 → 0.117.0

package/prompts/doc-testing-test-section.md

@@ -1,169 +0,0 @@
-# Documentation Testing - Section Test Phase (Functional + Semantic)
-
-You are testing a specific section of documentation to validate both functionality AND accuracy. You must verify that instructions work AND that the documentation text truthfully describes what actually happens.
-
-**Important**: 
-- Skip content that has ignore comments containing "dotai-ignore" (e.g., `<!-- dotai-ignore -->`, `.. dotai-ignore`, `// dotai-ignore`). Do not generate issues for ignored content.
-- Look for testing hints in comments containing "dotai-test-hint" (e.g., `<!-- dotai-test-hint: use mcp__dot-ai__prompts to verify slash commands -->`, `.. dotai-test-hint: run command X to test claim Y`, `// dotai-test-hint: check actual behavior with tool Z`). Follow these hints when testing the associated content.
-
-## CRITICAL MINDSET: User Behavior Simulation
-
-**You are simulating a real user following this documentation step-by-step.**
-
-### User Journey Testing Requirements
-
-**Follow documented workflows exactly as users would:**
-- If docs say "Run this command to test" → Actually execute that command and verify it works
-- If docs say "Navigate to Settings page" → Verify that page/option exists and is accessible  
-- If docs say "You should see output X" → Confirm you actually get output X
-- If docs say "Click the Install button" → Verify that button exists and functions
-- If docs say "This will automatically happen" → Test that it actually happens automatically
-
-**Key User Scenarios to Simulate:**
-1. **Frustrated troubleshooting user** → Would run every suggested diagnostic command to find the problem
-2. **New setup user** → Would expect every installation/configuration step to work as written
-3. **Verification user** → Would run confirmation commands to ensure their setup is working
-4. **Integration user** → Would follow workflow examples expecting them to produce stated results
-
-**Critical Testing Mindset Shifts:**
-- **From**: "This looks like an example command" → **To**: "A user would actually run this - does it work?"
-- **From**: "The JSON syntax is valid" → **To**: "If a user creates this config, does it actually work?"
-- **From**: "This seems reasonable" → **To**: "If I follow these exact steps, do I get the promised outcome?"
-
-## Section to Test
-**File**: {filePath}
-**Session**: {sessionId}
-**Section**: {sectionTitle} (ID: {sectionId})
-**Progress**: {sectionsRemaining} of {totalSections} sections remaining after this one
-
-## Your Task - Two-Phase Validation
-
-### Phase 1: Execute and Test (Functional Validation)
-Execute everything testable as a real user would:
-- Follow step-by-step instructions exactly as written
-- Execute commands, code examples, procedures (adapt for safety: use `./tmp/` for file operations, test endpoints for URLs, etc.)
-- Test interactive elements and verify file operations work
-- Validate that examples produce expected results
-
-### Phase 2: Analyze Claims vs Reality (Semantic Validation)  
-Check every claim in the documentation:
-□ **Difficulty/Time Claims**: Does "easy," "simple," "quickly," "automatically" match reality?
-□ **Outcome Claims**: Do "you will see," "this enables," "results in" match what actually happens?
-□ **Prerequisite Claims**: Are stated requirements actually sufficient for success?
-□ **User Experience Claims**: Would a typical user get the promised experience?
-□ **Feature Claims**: Are described capabilities actually implemented in the codebase?
-□ **Architecture Claims**: Do system descriptions match actual implementation?
-□ **Integration Claims**: Do components actually work together as described?
-□ **Status Claims**: Are features marked as "available" actually working vs. "planned"?
-
-### Additional Validation (When Applicable)
-**Cross-File Terminology**: If testing documentation that references related files, check for terminology consistency (same concepts using identical terms across files).
-
-**Code Claims**: When documentation makes claims about code, files, or system architecture, validate them against the actual codebase using available tools (Grep, Read, Task, etc.).
-
-## Testing Approach
-
-### EXECUTION REQUIREMENTS FOR TESTABLE CONTENT
-**When documentation contains executable examples, you MUST actually execute them:**
-
-**Types of executable content that require actual testing:**
-- **CLI Commands**: `kubectl get pods`, `npm install`, `docker run`
-- **API Calls**: HTTP requests, REST endpoints, GraphQL queries
-- **MCP Tool Calls**: `mcp__tool_name` with documented parameters
-- **Configuration Examples**: Creating files, environment variables, config files
-- **Web Navigation**: URLs, web interface interactions, form submissions
-- **Database Queries**: SQL commands, database operations
-- **Script Execution**: Shell scripts, Python scripts, automation workflows
-
-**Testing Protocol for Executable Content:**
-✅ REQUIRED: Execute each example exactly as documented
-✅ REQUIRED: Test with the exact parameters/inputs shown  
-✅ REQUIRED: Compare actual results with documented expected results
-❌ FORBIDDEN: Analyze implementation code instead of running examples
-❌ FORBIDDEN: Skip execution because "it looks similar to previous tests"
-❌ FORBIDDEN: Rely on testing from other sections of the documentation
-
-### NON-TESTABLE CONTENT (Testing Not Required)
-**These types of content should be analyzed but not executed:**
-- **Conceptual explanations**: Architecture descriptions, background theory
-- **Screenshots**: Visual examples that can't be directly executed
-- **Future roadmaps**: Planned features not yet implemented
-- **External dependencies**: Third-party services you don't control
-- **Destructive operations**: Commands that could damage systems
-- **Hardware-specific instructions**: When you lack the specific hardware
-- **Security credentials**: Examples containing sensitive information
-
-### CRITICAL: Section-Specific Testing Required (When Testable)
-**Each documentation section with executable content requires independent validation:**
-- Execute the specific testable examples shown in the current section
-- Previous successful tests cannot substitute for current section validation
-- Clearly distinguish between testable and non-testable content in your analysis
-
-### Functional Testing (Execute Documentation)
-**Execute documented examples first** - Always prioritize running the actual commands/procedures shown in the documentation, adapting for safety when needed. Use help commands only as supplements for understanding, not as substitutes for real testing.
-
-### Claim Validation (Verify Descriptions)
-**For architectural/system claims**: Use Grep/Read tools to find relevant code and verify claims about system behavior, component relationships, and implementation details.
-
-**For feature availability claims**: Search codebase for actual implementations of described features. Distinguish between implemented functionality and planned/aspirational descriptions.
-
-**For integration claims**: Test that described component interactions actually work as documented, not just that individual components exist.
-
-**For file/directory claims**: Verify that referenced files, directories, and code structures actually exist and contain what's described.
-
-**Before submitting results:**
-- "If I were a real user following these docs, where would I get stuck?"
-- "Did I test the actual user workflows, not just validate syntax?"
-- "Would a user following these steps get the experience the docs promise?"
-
-## Result Format
-
-Return your results as JSON in this exact format:
-
-```json
-{
-  "whatWasDone": "Brief summary of what you tested and executed in this section",
-  "issues": [
-    "In 'Section Name': Specific problem or issue you found while testing. Fix: Specific actionable solution to resolve this issue",
-    "Under 'Code Example': Another issue that prevents users from succeeding. Fix: Detailed steps to correct this problem"
-  ]
-}
-```
-
-**Guidelines:**
-
-**whatWasDone** (string): Concise summary covering BOTH functional testing AND semantic analysis - what commands/procedures you executed and what claims you analyzed.
-
-**issues** (array): Each issue must contain BOTH the problem AND its solution in a single string using this exact format:
-- **Location**: Start with precise location: "In 'Section Name':", "Under 'Heading':", "At line X:", etc.
-- **Problem**: Clear description of what's wrong, broken, or prevents user success
-- **Solution**: Follow with " Fix: " and provide specific actionable steps to resolve the issue
-
-**Format Requirements:**
-- **Include both critical problems AND optional improvements** - All actionable findings go in the issues array
-- **Location specificity**: Every issue must identify exactly where the problem is found
-- **Complete solutions**: Each fix must be detailed enough for implementation
-- **User impact focus**: Emphasize how problems affect user success and how fixes improve experience
-- **Consistent pattern**: "[Location]: [Problem description]. Fix: [Detailed solution]"
-
-**ACTIONABILITY REQUIREMENT**: Every issue must be actionable with a concrete fix. Avoid validation statements like "X is correct." If something is working correctly, don't mention it unless suggesting a specific enhancement.
-
-**Examples:**
-- "In 'Installation' section: Missing kubectl prerequisite causes setup failure. Fix: Add 'kubectl installation required' note before cluster setup steps"
-- "Under 'API Examples': Outdated endpoint URL returns 404 errors. Fix: Update endpoint from '/v1/api' to '/v2/api' throughout examples"
-
-## Instructions
-
-Complete BOTH phases for comprehensive testing:
-
-### Phase 1 Execution Checklist:
-1. Identify all testable content - discover commands, procedures, examples
-2. Execute everything - run commands, test procedures, verify examples  
-3. Document what actually happens - capture real outcomes vs expected
-
-### Phase 2 Analysis Checklist:  
-1. Find all claims - scan text for promises, expectations, descriptions
-2. Evaluate each claim - does reality match what's written?
-3. Check user perspective - would a typical user get the promised experience?
-
-Both phases are mandatory - functional testing without semantic analysis misses critical user experience gaps. Your goal is ensuring users get both working instructions AND accurate expectations about what will actually happen.

package/prompts/platform-operations-parse-script-help.md

@@ -1,68 +0,0 @@
-# Parse Nu Shell Script Operations
-
-You are a specialized parser that extracts available operations from Nushell script help output.
-
-## Task
-
-Parse the help output below and extract all available tools/resources with their operations into a structured JSON array.
-
-## Help Output
-
-{helpOutput}
-
-## Rules
-
-1. Group operations by tool/resource (e.g., ArgoCD, Kubernetes cluster, Crossplane)
-2. For each tool/resource, identify available operations (apply, delete, create, destroy, build, configure, etc.)
-3. Extract:
-   - `name`: Tool/resource name (e.g., "ArgoCD", "Kubernetes cluster", "Crossplane")
-   - `description`: Description of what this tool/resource does
-   - `operations`: Array of operation objects, each with:
-     - `name`: Operation name extracted from help (e.g., "apply", "delete", "create")
-     - `command`: Array of command parts from help output (e.g., ["apply", "argocd"])
-4. **CRITICAL**: Extract command arrays EXACTLY as they appear in help - "dot.nu apply argocd" → `["apply", "argocd"]`
-5. Do NOT include internal utility commands like "get", "print", "packages"
-
-## Examples
-
-From help output like:
-```sh
-dot.nu apply argocd - Installs ArgoCD with optional ingress
-dot.nu delete argocd - Removes ArgoCD
-dot.nu create kubernetes - Creates a Kubernetes cluster
-dot.nu destroy kubernetes - Destroys a Kubernetes cluster
-```
-
-Extract:
-```json
-[
-  {
-    "name": "ArgoCD",
-    "description": "GitOps continuous delivery tool for Kubernetes",
-    "operations": [
-      {"name": "apply", "command": ["apply", "argocd"]},
-      {"name": "delete", "command": ["delete", "argocd"]}
-    ]
-  },
-  {
-    "name": "Kubernetes cluster",
-    "description": "Kubernetes cluster management",
-    "operations": [
-      {"name": "create", "command": ["create", "kubernetes"]},
-      {"name": "destroy", "command": ["destroy", "kubernetes"]}
-    ]
-  }
-]
-```
-
-## Output Format
-
-Return ONLY a JSON array with no additional text, markdown formatting, or explanation.
-
-## Important
-
-- Return ONLY the JSON array
-- NO markdown code blocks (no ```json)
-- NO explanations
-- NO additional text
-- Just the raw JSON array starting with [ and ending with ]

package/scripts/ack.nu

@@ -1,195 +0,0 @@
-#!/usr/bin/env nu
-
-# Installs and configures AWS Controllers for Kubernetes (ACK)
-#
-# Examples:
-# > main apply ack --cluster_name my-cluster --region us-west-2
-def --env "main apply ack" [
-    --cluster_name = "dot"
-    --region = "us-east-1"
-    --apply_irsa = true
-    --aws-access-key-id: string,      # AWS Access Key ID (optional, falls back to AWS_ACCESS_KEY_ID env var)
-    --aws-secret-access-key: string   # AWS Secret Access Key (optional, falls back to AWS_SECRET_ACCESS_KEY env var)
-] {
-
-    print $"\nApplying (ansi yellow_bold)ACK Controllers(ansi reset)...\n"
-
-    mut access_key = $aws_access_key_id
-    if ($access_key | is-empty) and ("AWS_ACCESS_KEY_ID" in $env) {
-        $access_key = $env.AWS_ACCESS_KEY_ID
-    } else if ($access_key | is-empty) {
-        error make { msg: "AWS Access Key ID required via --aws-access-key-id parameter or AWS_ACCESS_KEY_ID environment variable" }
-    }
-    $env.AWS_ACCESS_KEY_ID = $access_key
-    $"export AWS_ACCESS_KEY_ID=($env.AWS_ACCESS_KEY_ID)\n"
-        | save --append .env
-
-    mut secret_key = $aws_secret_access_key
-    if ($secret_key | is-empty) and ("AWS_SECRET_ACCESS_KEY" in $env) {
-        $secret_key = $env.AWS_SECRET_ACCESS_KEY
-    } else if ($secret_key | is-empty) {
-        error make { msg: "AWS Secret Access Key required via --aws-secret-access-key parameter or AWS_SECRET_ACCESS_KEY environment variable" }
-    }
-    $env.AWS_SECRET_ACCESS_KEY = $secret_key
-    $"export AWS_SECRET_ACCESS_KEY=($env.AWS_SECRET_ACCESS_KEY)\n"
-        | save --append .env
-
-    let password = (
-        aws ecr-public get-login-password --region us-east-1
-    )
-
-    (
-        helm registry login --username AWS --password $password 
-            public.ecr.aws
-    )
-
-    mut aws_account_id = ""
-    mut oidc_provider = ""
-
-    if $apply_irsa {
-
-        if AWS_ACCOUNT_ID in $env {
-            $aws_account_id = $env.AWS_ACCOUNT_ID
-        } else {
-            $aws_account_id = (
-                aws sts get-caller-identity --query "Account"
-                    --output text
-            )
-        }
-
-        if OIDC_PROVIDER in $env {
-            $oidc_provider = $env.OIDC_PROVIDER
-        } else {
-            $oidc_provider = (
-                aws eks describe-cluster --name $cluster_name
-                    --region $region
-                    --query "cluster.identity.oidc.issuer"
-                    --output text | str replace "https://" ""
-            )
-        }
-
-    }
-
-    let controllers = [
-        {name: "ec2", version: "1.3.7"},
-        {name: "rds", version: "1.4.14"},
-    ]
-    for controller in $controllers {
-
-        let ack_controller_iam_role = $"ack-($controller.name)-controller"
-
-        (
-            helm upgrade --install $ack_controller_iam_role
-                oci://public.ecr.aws/aws-controllers-k8s/($controller.name)-chart
-                $"--version=($controller.version)"
-                --create-namespace --namespace ack-system
-                --set aws.region=us-east-1
-        )
-
-        if $apply_irsa {
-
-            {
-                Version: "2012-10-17",
-                Statement: [
-                    {
-                        Effect: "Allow",
-                        Principal: {
-                            Federated: $"arn:aws:iam::($aws_account_id):oidc-provider/($oidc_provider)"
-                        },
-                        "Action": "sts:AssumeRoleWithWebIdentity",
-                        "Condition": {
-                            "StringEquals": {
-                                $"($oidc_provider):sub": $"system:serviceaccount:ack-system:($ack_controller_iam_role)"
-                            }
-                        }
-                    }
-                ]
-            } | to json | save trust.json --force
-
-            do --ignore-errors {(
-                aws iam create-role
-                    --role-name $ack_controller_iam_role
-                    --assume-role-policy-document file://trust.json
-                    --description $"IRSA role for ACK ($controller.name) controller deployment on EKS cluster using Helm charts"
-            )}
-
-            let policy_arns = (
-                get policy_arns --controller $controller.name
-            )
-
-            for policy_arn in $policy_arns {(
-                aws iam attach-role-policy
-                    --role-name $ack_controller_iam_role
-                    --policy-arn $policy_arn
-            )}
-
-            let role_arn = (
-                aws iam get-role --role-name $ack_controller_iam_role
-                    --query Role.Arn --output text
-            )
-
-            (
-                kubectl --namespace ack-system
-                    annotate serviceaccount $ack_controller_iam_role
-                    $"eks.amazonaws.com/role-arn=($role_arn)"
-            )
-
-            (
-                kubectl --namespace ack-system
-                    rollout restart deployment
-                    $"($ack_controller_iam_role)-($controller.name)-chart"
-            )
-
-            (
-                kubectl --namespace ack-system wait
-                    --for=condition=ready pods
-                    --selector $"app.kubernetes.io/instance=($ack_controller_iam_role)"
-            )
-
-        }
-
-    }
-
-}
-
-# Removes AWS Controllers for Kubernetes (ACK) and deletes associated IAM roles
-def --env "main delete ack" [] {
-
-    let controllers = [
-        "ec2",
-        "rds"
-    ]
-    for controller in $controllers {
-
-        let ack_controller_iam_role = $"ack-($controller)-controller"
-
-        let policy_arns = (
-            get policy_arns --controller $controller
-        )
-
-        for policy_arn in $policy_arns {
-            
-        do --ignore-errors {(
-            aws iam detach-role-policy
-                --role-name ($ack_controller_iam_role)
-                --policy-arn ($policy_arn)
-            )}
-        }
-
-        aws iam delete-role --role-name $ack_controller_iam_role
-
-    }
-
-}
-
-def "get policy_arns" [
-    --controller = "ec2"
-] {
-    
-    let base_url = $"https://raw.githubusercontent.com/aws-controllers-k8s/($controller)-controller/main"
-
-    let policy_arn_url = $"($base_url)/config/iam/recommended-policy-arn"
-
-    http get $policy_arn_url | lines
-
-}

package/scripts/argo-workflows.nu

@@ -1,47 +0,0 @@
-#!/usr/bin/env nu
-
-# Installs Argo Workflows with container registry credentials
-#
-# Examples:
-# > main apply argoworkflows my-user my-password user@example.com --registry ghcr.io
-def "main apply argoworkflows" [
-    registry_user: string     # Container image registry user
-    registry_password: string # Container image registry password
-    registry_email: string    # Container image registry email
-    --registry = "ghcr.io"    # Container image registry
-] {
-
-    kubectl create namespace argo
-
-    (
-        kubectl --namespace argo apply 
-            --filename "https://github.com/argoproj/argo-workflows/releases/download/v3.6.0/quick-start-minimal.yaml"
-    )
-
-    let auth = ( $"($registry_user):($registry_password)" | base64 )
-
-    let json = {
-        "auths": {
-            $"($registry)": {
-                "auth": $"($auth)"
-            }
-        }
-    } | to json
-
-    (
-        kubectl --namespace argo create secret
-            docker-registry regcred
-            $"--docker-server=($registry)"
-            --docker-username=($registry_user)
-            --docker-password=($registry_password)
-            --docker-email=($registry_email)
-    )
-    
-    (
-        kubectl --namespace argo create secret
-            generic registry-creds
-            --from-literal $"password=($registry_password)"
-            --from-literal $"config.json=($json)"
-    )
-
-}

package/scripts/argocd.nu

@@ -1,85 +0,0 @@
-#!/usr/bin/env nu
-
-# Installs ArgoCD with optional ingress and applications setup
-#
-# Examples:
-# > main apply argocd --host_name argocd.example.com --ingress_class_name nginx
-def "main apply argocd" [
-    --host-name = "",
-    --apply-apps = true,
-    --ingress-class-name = "traefik"
-] {
-
-    let git_url = git config --get remote.origin.url
-
-    {
-        configs: {
-            secret: {
-                argocdServerAdminPassword: "$2a$10$m3eTlEdRen0nS86c5Zph5u/bDFQMcWZYdG3NVdiyaACCqoxLJaz16"
-                argocdServerAdminPasswordMtime: "2021-11-08T15:04:05Z"
-            }
-            cm: {
-                application.resourceTrackingMethod: annotation
-                timeout.reconciliation: 60s
-            }
-            params: { "server.insecure": true }
-        }
-        server: {
-            ingress: {
-                enabled: true
-                ingressClassName: $ingress_class_name
-                hostname: $host_name
-            }
-            extraArgs: [
-                --insecure
-            ]
-        }
-    } | save argocd-values.yaml --force
-
-    helm repo add argo https://argoproj.github.io/argo-helm
-
-    helm repo update
-  
-    (
-        helm upgrade --install argocd argo/argo-cd
-            --namespace argocd --create-namespace
-            --values argocd-values.yaml --wait
-    )
-
-    mkdir argocd
-
-    {
-        apiVersion: argoproj.io/v1alpha1
-        kind: Application
-        metadata: {
-            name: apps
-            namespace: argocd
-        }
-        spec: {
-            project: default
-            source: {
-                repoURL: $git_url
-                targetRevision: HEAD
-                path: apps
-            }
-            destination: {
-                server: "https://kubernetes.default.svc"
-                namespace: a-team
-            }
-            syncPolicy: {
-                automated: {
-                    selfHeal: true
-                    prune: true
-                    allowEmpty: true
-                }
-            }
-        }
-    } | save argocd/app.yaml --force
-
-    if $apply_apps {
-        
-        kubectl apply --filename argocd/app.yaml
-
-    }
-
-}

package/scripts/aso.nu

@@ -1,74 +0,0 @@
-#!/usr/bin/env nu
-
-def --env "main apply aso" [
-    --namespace = "default"
-    --apply_creds = true
-    --sync_period = "1h"
-    --azure-tenant: string  # Azure Tenant ID (optional, falls back to AZURE_TENANT env var)
-] {
-
-    (
-        helm upgrade --install aso2 azure-service-operator
-            --repo https://raw.githubusercontent.com/Azure/azure-service-operator/main/v2/charts
-            --namespace=azureserviceoperator-system
-            --create-namespace
-            --set crdPattern='resources.azure.com/*;dbforpostgresql.azure.com/*'
-            --wait
-    )
-
-    if $apply_creds {
-
-        mut tenant = $azure_tenant
-        if ($tenant | is-empty) and ("AZURE_TENANT" in $env) {
-            $tenant = $env.AZURE_TENANT
-        } else if ($tenant | is-empty) {
-            error make { msg: "Azure Tenant ID required via --azure-tenant parameter or AZURE_TENANT environment variable" }
-        }
-        $"export AZURE_TENANT=($tenant)\n" | save --append .env
-
-        az login --tenant $tenant
-
-        let subscription_id = (az account show --query id -o tsv)
-
-        let azure_data = (
-            az ad sp create-for-rbac --sdk-auth --role Owner
-                --scopes $"/subscriptions/($subscription_id)" | from json
-        )
-
-        {
-            apiVersion: "v1"
-            kind: "Secret"
-            metadata: {
-                name: "aso-credential"
-                namespace: $namespace
-            }
-            stringData: {
-                AZURE_SUBSCRIPTION_ID: $azure_data.subscriptionId
-                AZURE_TENANT_ID: $azure_data.tenantId
-                AZURE_CLIENT_ID: $azure_data.clientId
-                AZURE_CLIENT_SECRET: $azure_data.clientSecret
-            }
-        } | to yaml | kubectl apply --filename -
-
-        {
-            apiVersion: "v1"
-            kind: "Secret"
-            metadata: {
-                name: "aso-controller-settings"
-                namespace: "azureserviceoperator-system"
-            }
-            stringData: {
-                MAX_CONCURRENT_RECONCILES: "1"
-                AZURE_SYNC_PERIOD: $sync_period
-            }
-        } | to yaml | kubectl apply --filename -
-
-        (
-            kubectl --namespace azureserviceoperator-system
-                rollout restart deployment
-                azureserviceoperator-controller-manager
-        )
-
-    }
-
-}