@vfarcic/dot-ai 0.72.0 → 0.74.0

package/prompts/kyverno-generation.md

@@ -0,0 +1,317 @@
+# Kyverno Policy Generation from Policy Intent
+
+## Policy Intent Description
+{policy_description}
+
+## Policy Intent Details
+- **Rationale**: {policy_rationale}
+- **Triggers**: {policy_triggers}
+- **Intent ID**: {policy_id}
+
+## Available Resource Schemas
+{resource_schemas}
+
+## Namespace Scope Configuration
+{namespace_scope}
+
+## Previous Attempt Analysis
+{previous_attempt}
+
+## Error Details from Previous Attempt
+{error_details}
+
+## Instructions
+
+You are a Kubernetes governance expert specializing in Kyverno policy generation. Generate a comprehensive Kyverno ClusterPolicy YAML from the provided policy intent that enforces the described governance requirement against only the relevant resources from the available schemas.
+
+**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`
+- 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
+
+## 🛡️ 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
+- **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
+- **Descriptive Naming** - Generate clear, descriptive policy names with policy ID for uniqueness
+- **Enforcement Mode** - Use `validationFailureAction: Enforce` to actively prevent policy violations
+
+**Policy Structure Guidelines:**
+
+1. **Metadata Requirements**:
+   - **Name**: Generate descriptive slug from policy description (max 63 chars, e.g., `require-container-resource-limits`)
+   - **Labels**: Include `policy-intent/id: {policy_id}` for machine lookup
+   - **Annotations**: 
+     - `policy-intent/description: "{policy_description}"`
+     - `policy-intent/rationale: "{policy_rationale}"`
+
+2. **Name Generation Rules**:
+   - Convert policy description to lowercase slug format
+   - Use hyphens to separate words  
+   - Keep it concise but descriptive (e.g., "All containers must have resource limits" → "require-container-resource-limits")
+   - Ensure DNS compliance (lowercase alphanumeric + hyphens only)
+   - Must be 63 characters or less (Kubernetes naming limit)
+
+3. **Specification Requirements**:
+   - Set `background: false` to avoid processing existing resources
+   - Use `validationFailureAction: Enforce` to actively block non-compliant resources
+   - Include clear failure messages that reference the organizational policy
+   - Target only resources where the policy intent makes logical sense
+
+4. **Rule Design for Different Schemas**:
+   - **Separate rules** for resources with different field structures
+   - **Schema-specific validation** tailored to each resource type's field paths
+   - **Consistent governance intent** across all rules in the policy
+   - **Clear rule names** that indicate which resource types they target
+
+5. **Namespace Targeting Rules**:
+   - If namespace scope is 'Apply to all namespaces': No namespace restrictions needed
+   - If namespace scope starts with 'Apply ONLY to these namespaces': Add `match.any` with `resources.namespaces` list
+   - If namespace scope starts with 'Apply to all namespaces EXCEPT': Add `exclude.any` with `resources.namespaces` list
+   - Always use the exact namespace names provided in the scope configuration
+   - Never add namespace restrictions if scope indicates "all namespaces"
+
+## 🎯 MANDATORY PRE-GENERATION SCHEMA ANALYSIS
+
+**CRITICAL**: You MUST perform this systematic analysis BEFORE generating any Kyverno rules. This is NOT optional.
+
+**STEP 1: Policy Requirements Analysis**
+First, extract the exact validation requirements from the policy intent:
+- What specific field types, values, or patterns must be validated?
+- What conditions trigger a policy violation? 
+- What constitutes compliance vs non-compliance?
+
+**STEP 2: MANDATORY SCHEMA-BY-SCHEMA ANALYSIS**
+**REQUIREMENT**: You MUST analyze EVERY SINGLE provided schema individually. For each schema, you must:
+
+1. **Resource Identification**: Note the resource name, kind, and API version
+2. **Field Scanning**: Scan ALL fields in the schema for policy-relevant properties
+3. **Relevance Determination**: Does this resource have fields that match the policy requirements?
+4. **Field Path Mapping**: For relevant fields, identify the exact field paths
+5. **Rule Requirement**: If relevant fields exist, this resource REQUIRES a validation rule
+
+**STEP 3: COMPREHENSIVE COVERAGE VERIFICATION**
+Create a mental checklist for EVERY schema provided:
+- [ ] Schema analyzed: YES/NO
+- [ ] Policy-relevant fields found: YES/NO  
+- [ ] If YES: Field paths identified: [list paths]
+- [ ] If YES: Validation rule required: YES
+- [ ] If NO: Resource can be skipped: YES
+
+**STEP 4: FORCED RULE GENERATION**
+**ABSOLUTE REQUIREMENT**: Generate validation rules for EVERY resource that has policy-relevant fields.
+- NO EXCEPTIONS: If a resource has relevant fields, it gets a rule
+- NO ASSUMPTIONS: Don't assume certain resources are "not important"
+- 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.
+
+## 🔍 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`
+
+**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)
+
+**FAILURE TO ANALYZE = INVALID POLICY**: If you generate a policy without systematically considering every schema, 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.
+
+## 📋 SCHEMA-DRIVEN CEL EXPRESSIONS
+
+**Resource Schema Analysis:**
+- Examine each resource schema to understand field structure differences
+- Use exact field paths as documented in each schema
+- Handle nested objects and arrays correctly for each resource type
+- Account for optional vs required fields per schema
+
+**CEL Expression Patterns:**
+- **Field Existence**: `has(object.spec.fieldName)`
+- **Array Validation**: `object.spec.containers.all(c, condition)`
+- **String Patterns**: `object.metadata.name.matches('^[a-z][a-z0-9-]*$')`
+- **Resource Type Checking**: `request.kind.kind == 'Deployment'` (if needed in combined rules)
+- **Complex Logic**: Combine conditions with `&&`, `||`, `!`
+- **Previous Object (Updates)**: `oldObject.spec.fieldName` for comparing old vs new values
+
+**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'])`
+- ❌ **WRONG**: `has(request.object.metadata.labels['app'])`
+
+**KYVERNO MATCH SCHEMA RULES:**
+```yaml
+# ✅ CORRECT Kyverno match syntax:
+match:
+  any:
+  - resources:
+      kinds:
+      - Pod                        # Standard Kubernetes resource
+      - apps/v1/Deployment        # Group/Version/Kind format for apps group
+      operations:
+      - CREATE
+      - UPDATE
+      
+# ✅ For custom resources use Group/Version/Kind format:
+match:
+  any:
+  - resources:
+      kinds:
+      - example.com/v1/CustomResource
+      - example.com/v1beta1/CustomResource
+      operations:
+      - CREATE
+      - UPDATE
+
+# ❌ WRONG - Do NOT use 'apiGroups' or 'versions' fields:
+# apiGroups: [example.com]    # This field does not exist!
+# versions: [v1, v1beta1]     # This field does not exist!
+# apiVersions: [example.com/v1]  # This field does not exist!
+```
+
+## ✅ RESOURCE COVERAGE VALIDATION
+
+**Before finalizing the policy, verify complete coverage:**
+
+1. **Schema Analysis Completeness**: Every provided resource schema has been analyzed for policy-relevant fields
+2. **Rule Generation Coverage**: Every resource with policy-relevant fields has corresponding validation rules  
+3. **Field Path Accuracy**: All CEL expressions reference fields that actually exist in the target resource schemas
+4. **Validation Logic Correctness**: CEL expressions properly implement the governance rule for each resource's field structure
+5. **Message Clarity**: Error messages clearly explain the policy violation and reference the organizational requirement
+
+## 🧠 CUSTOM RESOURCE FIELD ANALYSIS
+
+**CRITICAL**: Custom resources often have different field structures than standard Kubernetes resources. Pay special attention to:
+
+**Image-Related Field Patterns:**
+- **Standard Pattern**: `spec.containers[].image` (includes tag like `nginx:1.21`)
+- **Separated Fields**: `spec.image` + `spec.tag` (image and tag in separate fields)
+- **Template Pattern**: `spec.template.spec.containers[].image` (for controller resources)
+
+**Field Analysis Rules:**
+1. **Look for both `image` and `tag` fields separately** - Some custom resources separate these
+2. **Check field descriptions** - Understand what each field represents
+3. **Generate appropriate validation** - For separate tag fields, check the tag field directly
+4. **Handle both patterns** - Some resources may have both patterns
+
+**Example Custom Resource Pattern:**
+```yaml
+# If custom resource has:
+spec:
+  image: nginx
+  tag: latest
+
+# Then validate:
+expression: >-
+  has(object.spec.tag) && object.spec.tag != '' ?
+  object.spec.tag != 'latest'
+  : true
+```
+
+## 🚀 OUTPUT REQUIREMENTS
+
+Generate a complete, valid Kyverno ClusterPolicy YAML that:
+
+1. **Uses Clean YAML Format** - Raw YAML with analysis as YAML comments, no markdown formatting
+2. **Uses Descriptive Naming** - Generate clear policy name from description + policy_id
+3. **Includes Machine-Readable Metadata** - Add policy-intent/id label for lookup
+4. **Enforces the Policy Intent** - Addresses the specific governance requirement described
+4. **Uses Multiple Rules Appropriately** - Creates separate rules for different resource schemas when needed
+5. **Targets Relevant Resources Only** - Includes only resource types where the policy logically applies
+6. **Uses Only CEL Expressions** - All validation logic must use CEL syntax exclusively
+7. **References Existing Fields** - Only uses fields that exist in the targeted resource schemas
+8. **Uses Enforcement Mode** - Set `validationFailureAction: Enforce` to actively block violations
+9. **New Resources Only** - Set `background: false` to target only new/updated resources
+10. **Provides Clear Feedback** - Descriptive error messages explaining the policy violation
+
+**CRITICAL ANALYSIS REQUIRED**:
+- **Generate appropriate policy name** - Create concise, descriptive slug from policy description
+- **Read the policy intent carefully** - Understand what governance rule needs enforcement
+- **Analyze available schemas** - Identify field structure differences across resource types
+- **Design appropriate rules** - Create separate rules when schemas require different validation approaches
+- **Validate field paths** - Ensure all referenced fields exist in the target resource schemas
+
+## 📋 NAMESPACE TARGETING EXAMPLES
+
+**For "Apply ONLY to these namespaces: production, staging":**
+```yaml
+spec:
+  rules:
+  - name: rule-name
+    match:
+      any:
+      - resources:
+          kinds: [Deployment]
+          namespaces:
+          - production
+          - staging
+```
+
+**For "Apply to all namespaces EXCEPT: kube-system, kube-public":**
+```yaml
+spec:
+  rules:
+  - name: rule-name
+    match:
+      any:
+      - resources:
+          kinds: [Deployment]
+    exclude:
+      any:
+      - resources:
+          namespaces:
+          - kube-system
+          - kube-public
+```
+
+**For "Apply to all namespaces (no restrictions)":**
+```yaml
+spec:
+  rules:
+  - name: rule-name
+    match:
+      any:
+      - resources:
+          kinds: [Deployment]
+    # No namespace restrictions - applies cluster-wide
+```
+
+**IMPORTANT**: Return only the YAML content with your mandatory schema analysis as concise YAML comments at the top, followed by the clean Kyverno policy manifest. The final policy YAML should be production-ready for `kubectl apply --dry-run=server` validation.
+
+**CRITICAL OUTPUT FORMAT REQUIREMENTS**:
+
+- **NO MARKDOWN FORMATTING**: Do not wrap the YAML in markdown code blocks (no ```yaml or ```)
+- **NO PROSE EXPLANATION**: Do not include any explanatory text before or after the YAML
+- **RAW YAML ONLY**: Return only the YAML content with analysis comments inside as YAML comments
+- **KUBECTL READY**: The output must be directly usable with kubectl apply
+
+**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
+# ConfigMap: NO relevant fields → Can skip
+#
+# RESOURCES REQUIRING VALIDATION RULES: StatefulSet, Pod
+#
+apiVersion: kyverno.io/v1
+kind: ClusterPolicy
+metadata:
+  name: policy-name
+# ... rest of policy

package/prompts/pattern-complete-error.md

@@ -0,0 +1 @@
+Error creating pattern: {error}

package/prompts/pattern-complete-success.md

@@ -0,0 +1,8 @@
+Pattern created successfully! 
+
+**Pattern ID**: {patternId}
+**Description**: {description}
+**Triggers**: {triggers}
+**Resources**: {resources}
+
+The pattern is now ready to enhance AI recommendations. When users ask for deployments matching your triggers, this pattern will suggest the specified Kubernetes resources.

package/prompts/pattern-created-by.md

@@ -0,0 +1 @@
+Ask the user: "What is your name or team identifier? This helps track pattern ownership and allows others to contact you with questions."

package/prompts/pattern-description.md

@@ -0,0 +1,7 @@
+Ask the user: "What deployment capability does this pattern provide? I need a capability name (2-4 words).
+
+Examples:
+- Specific: "Horizontal scaling", "Database persistence", "SSL termination"  
+- Broad/Organizational: "Application networking", "General security", "Basic monitoring"
+
+Both specific and broad patterns are fine. What capability describes your pattern?"

package/prompts/pattern-rationale.md

@@ -0,0 +1 @@
+Ask the user: "Why does this combination of resources work well together for {description}? This helps others understand when and why to use this pattern."

package/prompts/pattern-resources.md

@@ -0,0 +1 @@
+Ask the user: "Which Kubernetes resources should be suggested for {description}? Please list the resource types you want this pattern to suggest, separated by commas. For example: Deployment, Service, ConfigMap or StatefulSet, PersistentVolumeClaim, Secret."

package/prompts/pattern-review.md

@@ -0,0 +1,9 @@
+Please review your pattern:
+
+**Description**: {description}
+**Triggers**: {triggers}
+**Suggested Resources**: {resources}
+**Rationale**: {rationale}
+**Created By**: {createdBy}
+
+Does this look correct? Type 'confirm' to create the pattern, or 'modify' to make changes.

package/prompts/policy-complete-apply.md

@@ -0,0 +1,12 @@
+🚀 **Policy Applied Successfully!**
+
+**Description**: {description}
+**Triggers**: {triggers}
+**Rationale**: {rationale}
+
+**Applied Kyverno Policy:**
+```yaml
+{kyvernoPolicy}
+```
+
+The policy intent has been saved and the Kyverno policy has been applied to your cluster. The policy is now active and will enforce the defined rules on new and updated resources.

package/prompts/policy-complete-discard.md

@@ -0,0 +1,5 @@
+❌ **Policy Creation Cancelled**
+
+**Description**: {description}
+
+The policy intent creation has been cancelled and no data has been stored.

package/prompts/policy-complete-error.md

@@ -0,0 +1 @@
+Error creating policy intent: {error}

package/prompts/policy-complete-save.md

@@ -0,0 +1,12 @@
+💾 **Policy Saved Successfully!**
+
+**Description**: {description}
+**Triggers**: {triggers}
+**Rationale**: {rationale}
+
+**Generated Kyverno Policy:**
+```yaml
+{kyvernoPolicy}
+```
+
+The policy intent has been saved and the Kyverno YAML should be saved to your local file system. The policy is ready for manual deployment when needed.

package/prompts/policy-complete-success.md

@@ -0,0 +1,7 @@
+✅ **Policy Intent Created Successfully!**
+
+**Description**: {description}
+**Triggers**: {triggers}
+**Rationale**: {rationale}
+
+**Action**: {deploymentAction}

package/prompts/policy-created-by.md

@@ -0,0 +1 @@
+Ask the user: "Who should be credited as the creator of this policy intent? (This can be your name, team name, or organization.)"

package/prompts/policy-description.md

@@ -0,0 +1,9 @@
+Ask the user: "Please describe the policy intent you want to create. What should this policy enforce or ensure in your Kubernetes deployments?
+
+Examples:
+- "All containers must have resource limits defined"
+- "Images must be from trusted registries only"
+- "Pods must not run as root user"
+- "All services must have network policies"
+
+What policy requirement do you want to enforce?"

package/prompts/policy-namespace-scope.md

@@ -0,0 +1,43 @@
+# Policy Namespace Scope
+
+Your policy can be applied cluster-wide or limited to specific namespaces.
+
+## Available Namespaces in Your Cluster:
+{namespaces}
+
+## Choose the scope for your policy:
+
+1. **Apply to all namespaces** (cluster-wide enforcement)
+   - Type: `all` or `1`
+
+2. **Apply only to specific namespaces** (inclusive list)
+   - Type: `include: namespace1, namespace2, namespace3`
+   - Example: `include: production, staging`
+
+3. **Apply to all namespaces EXCEPT specific ones** (exclusion list)
+   - Type: `exclude: namespace1, namespace2`
+   - Example: `exclude: kube-system, kube-public`
+
+**Your choice**: [Type your selection]
+
+---
+
+## Examples:
+
+**For cluster-wide policy:**
+```
+all
+```
+
+**To apply only to production and staging:**
+```
+include: production, staging
+```
+
+**To exclude system namespaces:**
+```
+exclude: kube-system, kube-public, kube-node-lease
+```
+
+## Note
+System namespaces (kube-system, kube-public, kube-node-lease) are often excluded from policies to prevent conflicts with Kubernetes core functionality. Consider whether your policy should apply to these system namespaces.

package/prompts/policy-rationale.md

@@ -0,0 +1 @@
+Ask the user: "Why is this policy important for your organization? Please explain the rationale behind this policy requirement - what risks does it mitigate or what benefits does it provide?"

package/prompts/question-generation.md

@@ -12,8 +12,35 @@
 ## Available Cluster Options
 {cluster_options}
 
+## Organizational Policies
+{policy_context}
+
 ## Instructions
 
+## 🛡️ POLICY-AWARE QUESTION GENERATION (HIGHEST PRIORITY)
+
+**Policy Requirements Integration:**
+- **Policy-driven questions** represent organizational governance requirements and must be enforced through configuration
+- **Conditional applicability** - Only apply policies when their rationale matches the selected resources
+- **REQUIRED question promotion** - Applicable policy requirements should become REQUIRED questions with helpful defaults
+- **Compliance indicators** - Mark policy-driven questions with "⚠️ required by [policy description]" in question text
+- **Policy rationale** - Include policy rationale as question hints to help users understand WHY they're required
+
+**POLICY APPLICATION APPROACH:**
+
+1. **Analyze Resource Match**: Review each policy's rationale to determine if it applies to the selected resources
+2. **Extract Requirements**: Identify what configuration properties the policy requires
+3. **Create REQUIRED Questions**: Convert applicable policy requirements into REQUIRED questions
+4. **Add Compliance Context**: Include policy context in question text and hints
+5. **Set Sensible Defaults**: Provide policy-compliant defaults when possible
+
+**CRITICAL: Policy Conditional Logic**
+- **Read each policy's "Rationale" field carefully** - it specifies WHEN and TO WHAT the policy applies  
+- **Apply policies selectively** - only convert policy requirements to questions when the policy technically applies to the selected resource types
+- **Resource type matching** - If a policy rationale mentions specific resource types (e.g., "All Deployments must..."), only apply when Deployment resources are selected
+- **Field-specific requirements** - Match policy requirements to actual resource schema fields available in the "Resources in Solution" section
+- **Policy compliance increases user success** - policy-driven questions help users create compliant configurations from the start
+
 Based on the user's intent and the Kubernetes resources in this solution, generate appropriate questions to gather the information needed to create working manifests.
 
 **IMPORTANT**: Only ask questions about properties that are explicitly listed in the "Resources in Solution" section below. Do not ask about common Kubernetes properties unless they appear in the actual resource schema.

package/prompts/resource-selection.md

@@ -58,6 +58,8 @@ Create multiple alternative solutions. Consider:
 
 Respond with ONLY a JSON object containing an array of complete solutions. Each solution should include resources, description, scoring, and pattern compliance:
 
+**CRITICAL**: For each resource in your solutions, you MUST include the `resourceName` field. This field contains the correct plural, lowercase resource name used for kubectl explain calls. Extract this from the Available Resources list - each resource shows its `resourceName` field that you should copy exactly.
+
 ```json
 {
   "solutions": [
@@ -67,12 +69,14 @@ Respond with ONLY a JSON object containing an array of complete solutions. Each
         {
           "kind": "Deployment",
           "apiVersion": "apps/v1",
-          "group": "apps"
+          "group": "apps",
+          "resourceName": "deployments.apps"
         },
         {
           "kind": "Service",
           "apiVersion": "v1",
-          "group": ""
+          "group": "",
+          "resourceName": "services"
         }
       ],
       "score": 95,

package/shared-prompts/manage-org-data.md

@@ -1,6 +1,6 @@
 ---
 name: manage-org-data
-description: Manage organizational patterns and cluster resource capabilities
+description: Manage organizational patterns, policy intents, and cluster resource capabilities
 category: administration
 ---
 
@@ -13,19 +13,30 @@ category: administration
 2. List existing patterns
 3. Get pattern details
 4. Search patterns
+5. Delete a specific pattern
+6. Delete all patterns
+
+### Policy Intents:
+7. Create a new policy intent
+8. List existing policy intents
+9. Get policy intent details
+10. Search policy intents
+11. Delete a specific policy intent
+12. Delete all policy intents
 
 ### Resource Capabilities:
-5. Scan cluster for resource capabilities
-6. List discovered capabilities
-7. Get capability details
-8. Delete capability data
-9. Delete all capabilities
-10. Check scan progress
+13. Scan cluster for resource capabilities
+14. List discovered capabilities
+15. Get capability details
+16. Delete specific capability data
+17. Delete all capabilities
+18. Check scan progress
+19. Analyze capabilities
 
-**Your choice**: [Type the number (1-10) or describe what you want to do]
+**Your choice**: [Type the number (1-19) or describe what you want to do]
 
 ---
 
-Examples: Type "1" or "Create a new organizational pattern" or "5" or "Scan cluster"
+Examples: Type "1" or "Create a new organizational pattern" or "7" or "Create a new policy intent" or "13" or "Scan cluster"
 
 Once you make your choice, I'll call the `manageOrgData` tool with the appropriate parameters.

package/dist/core/pattern-creation-session.d.ts

@@ -1,43 +0,0 @@
-/**
- * Pattern Creation Session Manager
- *
- * Handles step-by-step pattern creation workflow with context-aware questions
- * and AI-powered trigger expansion.
- */
-import { PatternCreationSession, PatternWorkflowStep } from './pattern-creation-types';
-export declare class PatternCreationSessionManager {
-    /**
-     * Create a new pattern creation session
-     */
-    createSession(args: any): PatternCreationSession;
-    /**
-     * Load existing session
-     */
-    loadSession(sessionId: string, args: any): PatternCreationSession | null;
-    /**
-     * Save session to disk
-     */
-    private saveSession;
-    /**
-     * Process user response and move to next step
-     */
-    processResponse(sessionId: string, response: string, args: any): PatternWorkflowStep | null;
-    /**
-     * Get the next workflow step for the session
-     */
-    getNextStep(sessionId: string, args: any): PatternWorkflowStep | null;
-    /**
-     * Generate trigger expansion step with AI suggestions
-     */
-    private generateTriggerExpansionStep;
-    /**
-     * Generate review prompt showing complete pattern
-     */
-    private generateReviewPrompt;
-    /**
-     * Complete pattern creation and return success result
-     */
-    private completePattern;
-    private generateSessionId;
-}
-//# sourceMappingURL=pattern-creation-session.d.ts.map

package/dist/core/pattern-creation-session.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"pattern-creation-session.d.ts","sourceRoot":"","sources":["../../src/core/pattern-creation-session.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAMH,OAAO,EACL,sBAAsB,EACtB,mBAAmB,EACpB,MAAM,0BAA0B,CAAC;AAIlC,qBAAa,6BAA6B;IAExC;;OAEG;IACH,aAAa,CAAC,IAAI,EAAE,GAAG,GAAG,sBAAsB;IAiBhD;;OAEG;IACH,WAAW,CAAC,SAAS,EAAE,MAAM,EAAE,IAAI,EAAE,GAAG,GAAG,sBAAsB,GAAG,IAAI;IAgBxE;;OAEG;IACH,OAAO,CAAC,WAAW;IAcnB;;OAEG;IACH,eAAe,CAAC,SAAS,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,EAAE,IAAI,EAAE,GAAG,GAAG,mBAAmB,GAAG,IAAI;IA+D3F;;OAEG;IACH,WAAW,CAAC,SAAS,EAAE,MAAM,EAAE,IAAI,EAAE,GAAG,GAAG,mBAAmB,GAAG,IAAI;IAwErE;;OAEG;IACH,OAAO,CAAC,4BAA4B;IAiCpC;;OAEG;IACH,OAAO,CAAC,oBAAoB;IAa5B;;OAEG;IACH,OAAO,CAAC,eAAe;IAyCvB,OAAO,CAAC,iBAAiB;CAG1B"}