diff --git a/cli/azd/.vscode/cspell.yaml b/cli/azd/.vscode/cspell.yaml index 327795bc69d..19e3c4fc461 100644 --- a/cli/azd/.vscode/cspell.yaml +++ b/cli/azd/.vscode/cspell.yaml @@ -1,11 +1,15 @@ import: ../../../.vscode/cspell.global.yaml words: + - appcode - azcloud - azdext - azurefd - backoff + - bestpractices + - bicepschema - Canonicalize - chinacloudapi + - cloudarchitect - Codespace - Codespaces - devcontainers diff --git a/cli/azd/cmd/init.go b/cli/azd/cmd/init.go index 95045b8843d..8e104d3a449 100644 --- a/cli/azd/cmd/init.go +++ b/cli/azd/cmd/init.go @@ -437,26 +437,18 @@ Do not stop until all tasks are complete and fully resolved. } } - // Run Step + // Run Step with retry logic i.console.Message(ctx, color.MagentaString(step.Name)) fullTaskInput := fmt.Sprintf(taskInput, strings.Join([]string{ step.Description, "Provide a very brief summary in markdown format that includes any files generated during this step.", }, "\n")) - agentOutput, err := azdAgent.SendMessage(ctx, fullTaskInput) - if err != nil { - if agentOutput != "" { - i.console.Message(ctx, output.WithMarkdown(agentOutput)) - } - + if err := i.sendMessageWithRetry(ctx, azdAgent, fullTaskInput); err != nil { return err } i.console.Message(ctx, "") - i.console.Message(ctx, fmt.Sprintf("%s:", output.AzdAgentLabel())) - i.console.Message(ctx, output.WithMarkdown(agentOutput)) - i.console.Message(ctx, "") } // Post-completion feedback loop @@ -467,6 +459,29 @@ Do not stop until all tasks are complete and fully resolved. return nil } +// handleErrorWithRetryPrompt displays an error and prompts user for retry +func (i *initAction) handleErrorWithRetryPrompt(ctx context.Context, err error) bool { + // Display error in error format + i.console.Message(ctx, "") + i.console.Message(ctx, output.WithErrorFormat("Error occurred: %s", err.Error())) + i.console.Message(ctx, "") + + // Prompt user if they want to try again + retryPrompt := uxlib.NewConfirm(&uxlib.ConfirmOptions{ + Message: "Would you like to try again?", + DefaultValue: uxlib.Ptr(true), + HelpMessage: "Choose 'yes' to retry the current step, or 'no' to stop the initialization.", + }) + + shouldRetry, promptErr := retryPrompt.Ask(ctx) + if promptErr != nil { + // If we can't prompt, don't retry + return false + } + + return shouldRetry != nil && *shouldRetry +} + // collectAndApplyFeedback prompts for user feedback and applies it using the agent in a loop func (i *initAction) collectAndApplyFeedback( ctx context.Context, @@ -508,24 +523,41 @@ func (i *initAction) collectAndApplyFeedback( if userInput != "" { i.console.Message(ctx, color.MagentaString("Feedback")) - feedbackOutput, err := azdAgent.SendMessage(ctx, userInput) - if err != nil { - if feedbackOutput != "" { - i.console.Message(ctx, output.WithMarkdown(feedbackOutput)) - } + // Apply feedback with retry logic + if err := i.sendMessageWithRetry(ctx, azdAgent, userInput); err != nil { return err } - - i.console.Message(ctx, "") - i.console.Message(ctx, fmt.Sprintf("%s:", output.AzdAgentLabel())) - i.console.Message(ctx, output.WithMarkdown(feedbackOutput)) - i.console.Message(ctx, "") } } return nil } +// sendMessageWithRetry sends a message to the agent with retry logic for error recovery +func (i *initAction) sendMessageWithRetry(ctx context.Context, azdAgent agent.Agent, input string) error { + for { + agentOutput, err := azdAgent.SendMessage(ctx, input) + if err != nil { + if agentOutput != "" { + i.console.Message(ctx, output.WithMarkdown(agentOutput)) + } + + // Display error and ask if user wants to retry + if shouldRetry := i.handleErrorWithRetryPrompt(ctx, err); shouldRetry { + continue // Retry the same operation + } + return err // User chose not to retry, return original error + } + + // Success - display output and return + i.console.Message(ctx, "") + i.console.Message(ctx, fmt.Sprintf("%s:", output.AzdAgentLabel())) + i.console.Message(ctx, output.WithMarkdown(agentOutput)) + i.console.Message(ctx, "") + return nil + } +} + // postCompletionFeedbackLoop provides a final opportunity for feedback after all steps complete func (i *initAction) postCompletionFeedbackLoop( ctx context.Context, diff --git a/cli/azd/cmd/mcp.go b/cli/azd/cmd/mcp.go index 332448e1d94..25619b0eb6d 100644 --- a/cli/azd/cmd/mcp.go +++ b/cli/azd/cmd/mcp.go @@ -154,11 +154,20 @@ func (a *mcpStartAction) Run(ctx context.Context) (*actions.ActionResult, error) allTools := []server.ServerTool{ tools.NewAzdPlanInitTool(), + tools.NewAzdIdentifyUserIntentTool(), + tools.NewAzdSelectStackTool(), + tools.NewAzdListStackResourcesTool(), + tools.NewAzdNewProjectTool(), + tools.NewAzdModernizeProjectTool(), tools.NewAzdDiscoveryAnalysisTool(), tools.NewAzdArchitecturePlanningTool(), + tools.NewAzdArtifactGenerationTool(), + tools.NewAzdAppCodeGenerationTool(), + tools.NewGenerateProjectSpecTemplateTool(), tools.NewAzdAzureYamlGenerationTool(), tools.NewAzdDockerGenerationTool(), tools.NewAzdInfrastructureGenerationTool(), + tools.NewAzdGenerateInfraModuleTool(), tools.NewAzdIacGenerationRulesTool(), tools.NewAzdProjectValidationTool(), tools.NewAzdYamlSchemaTool(), diff --git a/cli/azd/internal/agent/agent_factory.go b/cli/azd/internal/agent/agent_factory.go index 532c3ef31ad..6623c3aadd2 100644 --- a/cli/azd/internal/agent/agent_factory.go +++ b/cli/azd/internal/agent/agent_factory.go @@ -91,7 +91,17 @@ func (f *AgentFactory) Create(opts ...AgentCreateOption) (Agent, error) { // Add more excluded tools here as needed } - allTools := []common.AnnotatedTool{} + includedTools := map[string]bool{ + "bestpractices": true, + "bicepschema": true, + "cloudarchitect": true, + "documentation": true, + "group": true, + "role": true, + "subscription": true, + } + + filteredTools := []common.AnnotatedTool{} for _, toolLoader := range toolLoaders { categoryTools, err := toolLoader.LoadTools() @@ -102,14 +112,18 @@ func (f *AgentFactory) Create(opts ...AgentCreateOption) (Agent, error) { // Filter out excluded tools for _, tool := range categoryTools { - if !excludedTools[tool.Name()] { - allTools = append(allTools, tool) + if excludedTools[tool.Name()] { + continue + } + + if tool.Server() == "azd" || tool.Server() == "built-in" || includedTools[tool.Name()] { + filteredTools = append(filteredTools, tool) } } } // Wraps all tools in consent workflow - protectedTools := f.consentManager.WrapTools(allTools) + protectedTools := f.consentManager.WrapTools(filteredTools) // Finalize agent creation options allOptions := []AgentCreateOption{} diff --git a/cli/azd/internal/agent/prompts/conversational.txt b/cli/azd/internal/agent/prompts/conversational.txt index 66878fc4eca..a7c73014018 100644 --- a/cli/azd/internal/agent/prompts/conversational.txt +++ b/cli/azd/internal/agent/prompts/conversational.txt @@ -1,21 +1,15 @@ You are an Azure Developer CLI (AZD) agent. -You are an expert in building, provisioning, and deploying Azure applications. -Always use Azure best practices and automation wherever possible. +You are an expert in packaging, provisioning, and deploying Azure applications. ---- - -## Pre-Task Expectations - -Before beginning your work: - -* Review all available tools. -* If a tool exists for best practices or required inputs, you MUST invoke it before taking further steps. -* Integrate any learned knowledge from tools into your workflow. - -When generating code, infrastructure, or configurations: +You must always seek out and follow established best practices and rules provided by available tools. +Before generating any code, infrastructure, or configuration, you must consult and apply guidance from tools whenever they are present. +If a tool defines rules, patterns, or validations, you must integrate those into your outputs and strictly align with them. +Only fall back to your own reasoning if no relevant tool or rule is available. -* You MUST ALWAYS save the content to files using the `write_file` tool. -* If no filename is provided, generate a meaningful and descriptive name. +You must be extremely thorough and cautious in all reasoning and actions. +Always follow the given instructions exactly, without skipping or relaxing any requirements. +Before producing a final answer, carefully verify that every step aligns with the rules, best practices, and tool guidance provided. +If there is any uncertainty, pause and re-check rather than making assumptions. --- diff --git a/cli/azd/internal/mcp/tools/azd_appcode_generation.go b/cli/azd/internal/mcp/tools/azd_appcode_generation.go new file mode 100644 index 00000000000..8630230b1a2 --- /dev/null +++ b/cli/azd/internal/mcp/tools/azd_appcode_generation.go @@ -0,0 +1,41 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + + "github.com/azure/azure-dev/cli/azd/internal/mcp/tools/prompts" + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +// NewAzdAppCodeGenerationTool creates a new azd application code generation tool +func NewAzdAppCodeGenerationTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_appcode_generation", + mcp.WithReadOnlyHintAnnotation(false), + mcp.WithIdempotentHintAnnotation(false), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Provides instructions for generating production-ready application scaffolding and starter code for all application components with Azure SDK integrations and deployment-ready configurations. + +This tool returns detailed instructions that the LLM agent should follow using available code generation tools. + +Use this tool when: +- Application components and technology stack have been defined in the application spec +- Ready to create code structure in src/ directories +- Need to generate framework-specific project files with Azure integrations +- Application architecture planning is complete and ready for implementation`, + ), + ), + Handler: handleAzdAppCodeGeneration, + } +} + +func handleAzdAppCodeGeneration(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + return mcp.NewToolResultText(prompts.AzdAppCodeGenerationPrompt), nil +} diff --git a/cli/azd/internal/mcp/tools/azd_architecture_planning.go b/cli/azd/internal/mcp/tools/azd_architecture_planning.go index 0f48a2dfe57..025448b2a7f 100644 --- a/cli/azd/internal/mcp/tools/azd_architecture_planning.go +++ b/cli/azd/internal/mcp/tools/azd_architecture_planning.go @@ -21,16 +21,15 @@ func NewAzdArchitecturePlanningTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for selecting appropriate Azure services for discovered application components and -designing infrastructure architecture. + `Provides instructions for consolidating all previously gathered context (requirements, stack selection, discovered components) into a complete application architecture design with Azure service mappings and implementation strategy. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available planning and documentation tools. Use this tool when: -- Discovery analysis has been completed and azd-arch-plan.md exists -- Application components have been identified and classified -- Need to map components to Azure hosting services -- Ready to plan containerization and database strategies`, +- Discovery analysis has been completed and application components are identified +- Technology stack selection is complete +- Ready to map components to Azure hosting services and design infrastructure +- Need to create comprehensive architecture documentation in the application spec`, ), ), Handler: handleAzdArchitecturePlanning, diff --git a/cli/azd/internal/mcp/tools/azd_artifact_generation.go b/cli/azd/internal/mcp/tools/azd_artifact_generation.go new file mode 100644 index 00000000000..e30eac75d5b --- /dev/null +++ b/cli/azd/internal/mcp/tools/azd_artifact_generation.go @@ -0,0 +1,41 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + + "github.com/azure/azure-dev/cli/azd/internal/mcp/tools/prompts" + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +// NewAzdArtifactGenerationTool creates a new azd artifact generation orchestration tool +func NewAzdArtifactGenerationTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_artifact_generation", + mcp.WithReadOnlyHintAnnotation(false), + mcp.WithIdempotentHintAnnotation(false), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Provides instructions for orchestrating the complete artifact generation process for AZD projects, generating infrastructure templates, application scaffolding, Docker configurations, and azure.yaml in the correct order with proper dependencies. + +This tool returns detailed instructions that the LLM agent should follow using available generation tools. + +Use this tool when: +- Application architecture design is complete with all service mappings +- Ready to generate all project artifacts (infrastructure, code, Docker, azure.yaml) +- Need to coordinate multiple generation processes in proper dependency order +- Project specification contains complete requirements for artifact generation`, + ), + ), + Handler: handleAzdArtifactGeneration, + } +} + +func handleAzdArtifactGeneration(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + return mcp.NewToolResultText(prompts.AzdArtifactGenerationPrompt), nil +} diff --git a/cli/azd/internal/mcp/tools/azd_azure_yaml_generation.go b/cli/azd/internal/mcp/tools/azd_azure_yaml_generation.go index 1fb8f334bc4..a4fb897f019 100644 --- a/cli/azd/internal/mcp/tools/azd_azure_yaml_generation.go +++ b/cli/azd/internal/mcp/tools/azd_azure_yaml_generation.go @@ -21,10 +21,9 @@ func NewAzdAzureYamlGenerationTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for generating the azure.yaml configuration file with proper service hosting, -build, and deployment settings for AZD projects. + `Provides instructions for creating a complete and valid azure.yaml file in the root directory that maps all application services to their Azure hosting services with proper build and deployment configurations. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available file creation and validation tools. Use this tool when: - Architecture planning has been completed and Azure services selected diff --git a/cli/azd/internal/mcp/tools/azd_discovery_analysis.go b/cli/azd/internal/mcp/tools/azd_discovery_analysis.go index 7d36397cf9d..588cccafff3 100644 --- a/cli/azd/internal/mcp/tools/azd_discovery_analysis.go +++ b/cli/azd/internal/mcp/tools/azd_discovery_analysis.go @@ -21,16 +21,15 @@ func NewAzdDiscoveryAnalysisTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for performing comprehensive discovery and analysis of application components -to prepare for Azure Developer CLI (AZD) initialization. + `Provides instructions for scanning and analyzing the current workspace to identify all application components, technologies, dependencies, and communication patterns, documenting findings in the application specification. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available analysis and documentation tools. Use this tool when: - Starting Phase 1 of AZD migration process - Need to identify all application components and dependencies - Codebase analysis required before architecture planning -- azd-arch-plan.md does not exist or needs updating`, +- Application spec does not exist or needs updating`, ), ), Handler: handleAzdDiscoveryAnalysis, diff --git a/cli/azd/internal/mcp/tools/azd_docker_generation.go b/cli/azd/internal/mcp/tools/azd_docker_generation.go index a63825d69c3..689faf1de7a 100644 --- a/cli/azd/internal/mcp/tools/azd_docker_generation.go +++ b/cli/azd/internal/mcp/tools/azd_docker_generation.go @@ -21,16 +21,15 @@ func NewAzdDockerGenerationTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for generating optimized Dockerfiles and container configurations for containerizable -services in AZD projects. + `Provides instructions for generating optimized Dockerfiles and .dockerignore files for all containerizable services based on the Docker File Generation Checklist from the application spec. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available file creation tools. Use this tool when: -- Architecture planning identified services requiring containerization -- azd-arch-plan.md shows Container Apps or AKS as selected hosting platform -- Need Dockerfiles for microservices, APIs, or containerized web applications -- Ready to implement containerization strategy`, +- Application components requiring containerization have been identified +- Docker File Generation Checklist exists in the application spec +- Ready to create production-ready Dockerfiles with multi-stage builds and security best practices +- Need to generate .dockerignore files for build optimization`, ), ), Handler: handleAzdDockerGeneration, diff --git a/cli/azd/internal/mcp/tools/azd_generate_infra_module.go b/cli/azd/internal/mcp/tools/azd_generate_infra_module.go new file mode 100644 index 00000000000..eb3cc207e4d --- /dev/null +++ b/cli/azd/internal/mcp/tools/azd_generate_infra_module.go @@ -0,0 +1,154 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + "encoding/json" + "fmt" + "strings" + + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +// NewAzdGenerateInfraModuleTool creates a new tool for generating Bicep infrastructure modules +func NewAzdGenerateInfraModuleTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_generate_infra_module", + mcp.WithReadOnlyHintAnnotation(false), + mcp.WithIdempotentHintAnnotation(false), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Generates a new Bicep infrastructure module for a specified Azure resource type. +This tool takes resource type, API version, and optional requirements as input and returns +a complete Bicep module using MCP sampling.`, + ), + mcp.WithString("resourceType", + mcp.Description("The Azure resource type for the module (e.g., Microsoft.Storage/storageAccounts, Microsoft.Web/sites)"), + mcp.Required(), + ), + mcp.WithString("apiVersion", + mcp.Description("The API version to use for the resource. Defaults to 'latest' if not specified"), + ), + mcp.WithString("requirements", + mcp.Description("Optional specific requirements or configurations for the module"), + ), + ), + Handler: handleAzdGenerateInfraModule, + } +} + +func handleAzdGenerateInfraModule(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + // Validate required parameters + resourceType, err := request.RequireString("resourceType") + if err != nil { + return createErrorResult("resourceType", "Resource type is required"), nil + } + + if strings.TrimSpace(resourceType) == "" { + return createErrorResult("resourceType", "Resource type cannot be empty"), nil + } + + // Get optional parameters + apiVersion := request.GetString("apiVersion", "latest") + requirements := request.GetString("requirements", "") + + // Construct the prompt for Bicep module generation + prompt := buildBicepModulePrompt(resourceType, apiVersion, requirements) + + // Make MCP sampling request + serverFromCtx := server.ServerFromContext(ctx) + samplingRequest := mcp.CreateMessageRequest{ + CreateMessageParams: mcp.CreateMessageParams{ + Messages: []mcp.SamplingMessage{ + { + Role: mcp.RoleUser, + Content: mcp.TextContent{ + Type: "text", + Text: prompt, + }, + }, + }, + SystemPrompt: `You are an expert Bicep Code Generator that can generate production-ready Bicep modules that follow Azure Well-Architected Framework principles.`, + Temperature: 0.3, // Lower temperature for more consistent code generation + }, + } + + samplingResult, err := serverFromCtx.RequestSampling(ctx, samplingRequest) + if err != nil { + return mcp.NewToolResultErrorFromErr("Error during Bicep module generation", err), nil + } + + // Extract the generated Bicep code + if textContent, ok := samplingResult.Content.(mcp.TextContent); ok { + bicepCode := textContent.Text + + // Format the response - construct without backticks in the format string + response := "# Generated Bicep Module\n\n" + response += "## Resource Information\n" + response += fmt.Sprintf("- **Resource Type**: %s\n", resourceType) + response += fmt.Sprintf("- **API Version**: %s\n", apiVersion) + response += fmt.Sprintf("- **Requirements**: %s\n\n", getRequirementsDisplay(requirements)) + response += "## Generated Bicep Code\n\n" + response += "```bicep\n" + response += bicepCode + response += "\n```" + + return mcp.NewToolResultText(response), nil + } + + return mcp.NewToolResultError("Failed to extract Bicep code from sampling response"), nil +} + +func buildBicepModulePrompt(resourceType, apiVersion, requirements string) string { + prompt := fmt.Sprintf(`Generate a complete Bicep module for the Azure resource type: %s + +Requirements: +- Use API version: %s +- Include proper parameter definitions with descriptions and validation +- Add meaningful variable declarations where appropriate +- Include comprehensive outputs for important resource properties +- Follow Azure naming conventions and best practices +- Add resource tags for governance +- Include proper documentation comments`, resourceType, apiVersion) + + if requirements != "" { + prompt += fmt.Sprintf(` +- Additional specific requirements: %s`, requirements) + } + + prompt += ` + +The module should be production-ready and include: +1. Parameter section with proper types, descriptions, and validation +2. Variable section for computed values +3. Resource definition with all necessary properties +4. Output section exposing key resource properties +5. Inline comments explaining key configurations + +Please provide only the Bicep code without additional explanations or markdown formatting.` + + return prompt +} + +func getRequirementsDisplay(requirements string) string { + if requirements == "" { + return "None specified" + } + return requirements +} + +func createErrorResult(parameterName, message string) *mcp.CallToolResult { + fullMessage := fmt.Sprintf("Parameter '%s': %s", parameterName, message) + errorData := ErrorResponse{ + Error: true, + Message: fullMessage, + } + + errorJSON, _ := json.Marshal(errorData) + return mcp.NewToolResultText(string(errorJSON)) +} diff --git a/cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go b/cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go new file mode 100644 index 00000000000..93a3202156e --- /dev/null +++ b/cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go @@ -0,0 +1,102 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + _ "embed" + "fmt" + "os" + "strings" + "time" + + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +//go:embed resources/app-spec-template.md +var appSpecTemplateContent string + +// NewGenerateProjectSpecTemplateTool creates a new MCP tool for generating project specification templates +func NewGenerateProjectSpecTemplateTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_generate_project_spec_template", + mcp.WithReadOnlyHintAnnotation(false), + mcp.WithIdempotentHintAnnotation(true), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Generate a project specification template file (app-spec.md) in the current workspace. +This tool creates the initial template file that other tools will populate with actual +project information during the planning and implementation process. + +The template will be created at 'app-spec.md' in the current directory if it doesn't +already exist. No parameters required.`, + ), + ), + Handler: handleGenerateProjectSpecTemplate, + } +} + +func handleGenerateProjectSpecTemplate(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + const outputPath = "app-spec.md" + + // Check if file already exists + if _, err := os.Stat(outputPath); err == nil { + return mcp.NewToolResultText( + fmt.Sprintf("Template file '%s' already exists in the workspace. No action taken.", outputPath), + ), nil + } + + // Generate current timestamp + currentTime := time.Now() + generatedDate := currentTime.Format("2006-01-02 15:04:05 MST") + + // Create the template with placeholder project name and current timestamp + templateContent := strings.ReplaceAll(appSpecTemplateContent, "{{.ProjectName}}", "[PROJECT_NAME]") + templateContent = strings.ReplaceAll(templateContent, "{{.GeneratedDate}}", generatedDate) + templateContent = strings.ReplaceAll(templateContent, "{{.LastUpdated}}", generatedDate) + + // Write the template file to the workspace + if err := os.WriteFile(outputPath, []byte(templateContent), 0600); err != nil { + return mcp.NewToolResultText(fmt.Sprintf("Error writing template file: %v", err)), nil + } + + // Create success response + response := fmt.Sprintf(`# Project Specification Template Created + +✅ **Template File Successfully Created** + +**File Path**: %s +**Generated**: %s + +## Template Overview + +A comprehensive project specification template has been created in your workspace with the following structure: + +- **Project Overview**: Basic project information and classification +- **Project Requirements**: Sections for requirements discovery findings +- **Technology Stack Selection**: Documentation of stack decisions and rationale +- **Application Architecture**: Component definitions and data architecture +- **Azure Service Mapping**: Infrastructure and service configurations +- **Implementation Plan**: Development approach and deployment strategy +- **Security and Compliance**: Security architecture and requirements +- **Monitoring and Operations**: Operational procedures and monitoring +- **Project Status and Next Steps**: Implementation roadmap and success criteria + +## Next Steps + +The template is ready! Other tools will now populate the template sections as they discover and plan project details: + +1. User intent discovery will fill the "Project Requirements" section +2. Stack selection will complete the "Technology Stack Selection" section +3. Architecture planning will populate the "Application Architecture" and "Azure Service Mapping" sections +4. Implementation planning will complete the remaining sections + +The template serves as the living documentation for your AZD project throughout the planning and " + + "implementation process.`, outputPath, generatedDate) + + return mcp.NewToolResultText(response), nil +} diff --git a/cli/azd/internal/mcp/tools/azd_iac_generation_rules.go b/cli/azd/internal/mcp/tools/azd_iac_generation_rules.go index 028e5555839..8e03cf43206 100644 --- a/cli/azd/internal/mcp/tools/azd_iac_generation_rules.go +++ b/cli/azd/internal/mcp/tools/azd_iac_generation_rules.go @@ -21,16 +21,15 @@ func NewAzdIacGenerationRulesTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns comprehensive rules and guidelines for generating Bicep Infrastructure as Code files and modules -for AZD projects. + `Provides authoritative rules and standards for generating Bicep infrastructure templates that follow Azure Well-Architected Framework principles and AZD conventions. -The LLM agent should reference these rules when generating infrastructure code. +This tool returns detailed rules and guidelines that the LLM agent should follow when generating infrastructure code. Use this tool when: - Generating any Bicep infrastructure templates for AZD projects - Need compliance rules and naming conventions for Azure resources - Creating modular, reusable Bicep files -- Ensuring security and operational best practices"`, +- Ensuring security and operational best practices`, ), ), Handler: handleAzdIacGenerationRules, diff --git a/cli/azd/internal/mcp/tools/azd_identify_user_intent.go b/cli/azd/internal/mcp/tools/azd_identify_user_intent.go new file mode 100644 index 00000000000..818e7154423 --- /dev/null +++ b/cli/azd/internal/mcp/tools/azd_identify_user_intent.go @@ -0,0 +1,41 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + + "github.com/azure/azure-dev/cli/azd/internal/mcp/tools/prompts" + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +// NewAzdIdentifyUserIntentTool creates a new azd identify user intent tool +func NewAzdIdentifyUserIntentTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_identify_user_intent", + mcp.WithReadOnlyHintAnnotation(true), + mcp.WithIdempotentHintAnnotation(true), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Provides instructions for engaging users with conversational questions to understand project purpose, scale requirements, budget constraints, and architectural preferences, then classify and document findings. + +This tool returns detailed instructions that the LLM agent should follow using available user interaction and documentation tools. + +Use this tool when: +- Starting a new project and need to understand user requirements +- Beginning the discovery phase for project planning +- Need to classify project type, scale, and budget constraints +- Ready to gather architectural and technology preferences from the user`, + ), + ), + Handler: handleAzdIdentifyUserIntent, + } +} + +func handleAzdIdentifyUserIntent(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + return mcp.NewToolResultText(prompts.AzdIdentifyUserIntentPrompt), nil +} diff --git a/cli/azd/internal/mcp/tools/azd_infrastructure_generation.go b/cli/azd/internal/mcp/tools/azd_infrastructure_generation.go index c29eff36f5c..584f0042e8f 100644 --- a/cli/azd/internal/mcp/tools/azd_infrastructure_generation.go +++ b/cli/azd/internal/mcp/tools/azd_infrastructure_generation.go @@ -21,15 +21,15 @@ func NewAzdInfrastructureGenerationTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for generating modular Bicep infrastructure templates following Azure security and -operational best practices for AZD projects. + `Provides instructions for generating complete Bicep infrastructure templates in ./infra directory based on the Infrastructure as Code File Checklist, using latest schema versions and following IaC generation rules. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available infrastructure generation tools. Use this tool when: -- Architecture planning completed with Azure services selected -- Need to create Bicep infrastructure templates -- Ready to implement infrastructure as code for deployment`, +- Application architecture planning is complete with Azure service mappings +- Ready to generate Bicep templates for all required Azure resources +- Infrastructure as Code File Checklist exists in the application spec +- Need to create modular, reusable infrastructure templates following best practices`, ), ), Handler: handleAzdInfrastructureGeneration, diff --git a/cli/azd/internal/mcp/tools/azd_list_stack_resources.go b/cli/azd/internal/mcp/tools/azd_list_stack_resources.go new file mode 100644 index 00000000000..e48f11fbe88 --- /dev/null +++ b/cli/azd/internal/mcp/tools/azd_list_stack_resources.go @@ -0,0 +1,113 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + _ "embed" + "fmt" + + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +//go:embed prompts/azd_list_stack_resources.md +var azdListStackResourcesPrompt string + +//go:embed resources/baseline_resources.md +var baselineResourcesDoc string + +//go:embed resources/containers_stack_resources.md +var containersStackResourcesDoc string + +//go:embed resources/serverless_stack_resources.md +var serverlessStackResourcesDoc string + +//go:embed resources/logic_apps_stack_resources.md +var logicAppsStackResourcesDoc string + +func NewAzdListStackResourcesTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_list_stack_resources", + mcp.WithReadOnlyHintAnnotation(true), + mcp.WithIdempotentHintAnnotation(true), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Provides the definitive list of Azure resources required for each technology stack (baseline and stack-specific) to guide architecture planning and infrastructure generation. + +This tool returns detailed resource definitions that the LLM agent should use for architecture planning and infrastructure generation. + +Use this tool when: +- Need to understand what Azure resources are available for each technology stack +- Planning infrastructure architecture and need resource type identifiers +- Ready to map application components to appropriate Azure services +- Generating infrastructure templates and need resource specifications`, + ), + mcp.WithString("stack", + mcp.Description("The technology stack to list resources for"), + mcp.Enum("containers", "serverless", "logic_apps"), + mcp.Required(), + ), + ), + Handler: handleAzdListStackResources, + } +} + +func handleAzdListStackResources(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + stack, err := request.RequireString("stack") + if err != nil { + return mcp.NewToolResultError(fmt.Sprintf("Invalid arguments: %v", err)), nil + } + + // Validate stack parameter + validStacks := map[string]bool{ + "containers": true, + "serverless": true, + "logic_apps": true, + } + + if !validStacks[stack] { + return mcp.NewToolResultError( + fmt.Sprintf("Invalid stack '%s'. Must be one of: containers, serverless, logic_apps", stack), + ), nil + } + + // Build response with baseline resources and stack-specific resources + var stackSpecificDoc string + var stackDisplayName string + + switch stack { + case "containers": + stackSpecificDoc = containersStackResourcesDoc + stackDisplayName = "Containers" + case "serverless": + stackSpecificDoc = serverlessStackResourcesDoc + stackDisplayName = "Serverless" + case "logic_apps": + stackSpecificDoc = logicAppsStackResourcesDoc + stackDisplayName = "Logic Apps" + } + + response := fmt.Sprintf(`%s + +# Azure Resources for %s Stack + +## Baseline Resources (All Stacks) + +%s + +## %s Stack-Specific Resources + +%s`, + azdListStackResourcesPrompt, + stackDisplayName, + baselineResourcesDoc, + stackDisplayName, + stackSpecificDoc, + ) + + return mcp.NewToolResultText(response), nil +} diff --git a/cli/azd/internal/mcp/tools/azd_modernize_project.go b/cli/azd/internal/mcp/tools/azd_modernize_project.go new file mode 100644 index 00000000000..50bb68f781b --- /dev/null +++ b/cli/azd/internal/mcp/tools/azd_modernize_project.go @@ -0,0 +1,41 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + + "github.com/azure/azure-dev/cli/azd/internal/mcp/tools/prompts" + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +// NewAzdModernizeProjectTool creates a new azd project modernization tool +func NewAzdModernizeProjectTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_modernize_project", + mcp.WithReadOnlyHintAnnotation(true), + mcp.WithIdempotentHintAnnotation(true), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Provides instructions for modernizing existing applications to be AZD-compatible by conducting analysis, requirements discovery, stack selection, architecture planning, and artifact generation while preserving existing functionality. + +This tool returns detailed instructions that the LLM agent should follow using available analysis, planning, and generation tools. + +Use this tool when: +- Working with an existing application that needs Azure deployment capabilities +- Ready to modernize a project to be AZD-compatible while preserving functionality +- Need to conduct comprehensive analysis and generate Azure deployment artifacts +- Application workspace contains existing code that should be preserved`, + ), + ), + Handler: handleAzdModernizeProject, + } +} + +func handleAzdModernizeProject(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + return mcp.NewToolResultText(prompts.AzdModernizeProjectPrompt), nil +} diff --git a/cli/azd/internal/mcp/tools/azd_new_project.go b/cli/azd/internal/mcp/tools/azd_new_project.go new file mode 100644 index 00000000000..05084b7dc88 --- /dev/null +++ b/cli/azd/internal/mcp/tools/azd_new_project.go @@ -0,0 +1,41 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + + "github.com/azure/azure-dev/cli/azd/internal/mcp/tools/prompts" + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +// NewAzdNewProjectTool creates a new azd new project creation orchestration tool +func NewAzdNewProjectTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_new_project", + mcp.WithReadOnlyHintAnnotation(true), + mcp.WithIdempotentHintAnnotation(true), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Provides instructions for orchestrating complete new project creation from scratch through requirements discovery, stack selection, architecture planning, and file generation guidance to create a ready-to-implement project specification. + +This tool returns detailed instructions that the LLM agent should follow using available discovery, planning, and generation tools. + +Use this tool when: +- Creating a brand new AZD project from an empty or minimal workspace +- Ready to guide user through complete project setup from requirements to implementation +- Need systematic workflow for new project creation with all planning phases +- Starting fresh without existing application code or infrastructure`, + ), + ), + Handler: handleAzdNewProject, + } +} + +func handleAzdNewProject(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + return mcp.NewToolResultText(prompts.AzdNewProjectPrompt), nil +} diff --git a/cli/azd/internal/mcp/tools/azd_plan_init.go b/cli/azd/internal/mcp/tools/azd_plan_init.go index 23a78e823eb..bdc95b143da 100644 --- a/cli/azd/internal/mcp/tools/azd_plan_init.go +++ b/cli/azd/internal/mcp/tools/azd_plan_init.go @@ -21,16 +21,15 @@ func NewAzdPlanInitTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for orchestrating complete AZD application initialization using structured phases -with specialized tools. + `Provides instructions for analyzing workspace contents to determine project state, classify as "new project" or "existing application", route users to appropriate workflow, and execute the selected workflow with proper tool orchestration. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available analysis and orchestration tools. Use this tool when: -- Starting new AZD project initialization or migration -- Need structured approach to transform application into AZD-compatible project -- Want to ensure proper sequencing of discovery, planning, and file generation -- Require complete project orchestration guidance`, +- Starting AZD project initialization and need to determine the right workflow +- Workspace contains mixed or unclear content requiring analysis +- Need to route between new project creation vs application modernization +- Beginning any AZD project setup and need proper workflow guidance`, ), ), Handler: handleAzdPlanInit, diff --git a/cli/azd/internal/mcp/tools/azd_project_validation.go b/cli/azd/internal/mcp/tools/azd_project_validation.go index e8b62641298..1a0820ec7ac 100644 --- a/cli/azd/internal/mcp/tools/azd_project_validation.go +++ b/cli/azd/internal/mcp/tools/azd_project_validation.go @@ -21,16 +21,15 @@ func NewAzdProjectValidationTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for validating AZD project by running comprehensive checks on azure.yaml schema, -Bicep templates, environment setup, packaging, and deployment preview. + `Provides instructions for executing comprehensive validation of AZD project components including azure.yaml schema, Bicep templates, environment configuration, packaging, and deployment preview to ensure deployment readiness. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available validation and testing tools. Use this tool when: -- All AZD configuration files have been generated -- Ready to validate complete project before deployment +- All AZD configuration files and artifacts have been generated +- Ready to validate complete project before deployment with azd up - Need to ensure azure.yaml, Bicep templates, and environment are properly configured -- Final validation step before running azd up`, +- Final validation step to confirm deployment readiness`, ), ), Handler: handleAzdProjectValidation, diff --git a/cli/azd/internal/mcp/tools/azd_select_stack.go b/cli/azd/internal/mcp/tools/azd_select_stack.go new file mode 100644 index 00000000000..a0c25b586c2 --- /dev/null +++ b/cli/azd/internal/mcp/tools/azd_select_stack.go @@ -0,0 +1,41 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + + "github.com/azure/azure-dev/cli/azd/internal/mcp/tools/prompts" + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +// NewAzdSelectStackTool creates a new azd stack selection tool +func NewAzdSelectStackTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_select_stack", + mcp.WithReadOnlyHintAnnotation(true), + mcp.WithIdempotentHintAnnotation(true), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Provides instructions for assessing team expertise, application characteristics, and project requirements through targeted questions to select the optimal single technology stack (Containers, Serverless, or Logic Apps) with clear rationale. + +This tool returns detailed instructions that the LLM agent should follow using available user interaction and documentation tools. + +Use this tool when: +- User intent and project requirements have been discovered +- Ready to determine the optimal technology stack for the project +- Need to assess team capabilities and application characteristics +- Project requirements are understood and ready for technology decisions`, + ), + ), + Handler: handleAzdSelectStack, + } +} + +func handleAzdSelectStack(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + return mcp.NewToolResultText(prompts.AzdSelectStackPrompt), nil +} diff --git a/cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md new file mode 100644 index 00000000000..751531676cf --- /dev/null +++ b/cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md @@ -0,0 +1,54 @@ +# AZD Application Code Generation Instructions + +**TASK:** Generate production-ready application scaffolding and starter code for all application components with Azure SDK integrations and deployment-ready configurations. + +**SUCCESS CRITERIA:** + +- Complete application scaffolding created in `src/` directories for all identified components +- Framework-specific project files and dependency configurations generated +- Azure SDK integrations implemented for all required services +- Health checks, logging, and monitoring infrastructure included +- Configuration management and environment variable handling implemented +- Application spec updated with generated code structure + +**VALIDATION REQUIRED:** + +- All generated code compiles without errors for the target language/framework +- Azure SDK connections can be established (connection strings validate) +- Health check endpoints respond correctly +- Configuration follows security best practices (no hardcoded secrets) +- Generated code follows language-specific style guidelines + +**COMPLETION CHECKLIST:** + +- [ ] Read application specification for component requirements and stack decisions +- [ ] Generate scaffolding for each component in `src/` structure +- [ ] Implement Azure SDK integrations for all mapped services +- [ ] Add health checks, logging, and monitoring to each component +- [ ] Update application spec with generated code documentation + +## Critical Implementation Requirements + +**Standard Directory Structure:** + +```text +src/ +├── / # One directory per application component +└── shared/ # Shared libraries and utilities (if needed) +``` + +**Essential Scaffolding Elements:** + +- **Entry Points**: Main application files with proper startup configuration +- **Health Checks**: `/health` endpoint for all services (Container Apps requirement) +- **Configuration**: Environment-based config (no hardcoded values) +- **Azure SDK Integration**: Connection code for all mapped Azure services +- **Error Handling**: Proper exception handling and logging +- **Build Scripts**: Language-appropriate build and dependency management + +**Security Requirements:** + +- No secrets or connection strings in code +- Use environment variables for all configuration +- Implement proper authentication integration points +- Follow language-specific security best practices diff --git a/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md b/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md index 904f75ffa95..8789706288a 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md @@ -1,133 +1,49 @@ # AZD Architecture Planning Instructions -✅ **Agent Task List** +**TASK:** Consolidate all previously gathered context (requirements, stack selection, discovered components) into a complete application architecture design with Azure service mappings and implementation strategy. -1. Read `azd-arch-plan.md` to understand discovered components -2. For each component, select optimal Azure service using selection criteria below -3. Plan containerization strategy for applicable services -4. Select appropriate database and messaging services -5. Design resource group organization and networking approach -6. Generate IaC file checklist based on selected Azure services -7. Generate Docker file checklist based on containerization strategy -8. Create `azd-arch-plan.md` if it doesn't exist, or update existing file with service mapping table, architecture decisions, IaC checklist, and Docker checklist while preserving existing content +**SUCCESS CRITERIA:** -📄 **Required Outputs** +- Application architecture section populated with all component details and relationships +- Azure service mapping completed with specific service assignments and rationale +- Implementation plan updated with concrete infrastructure and deployment strategy +- All previously gathered context properly integrated into existing application spec structure -- Create `azd-arch-plan.md` if missing, or update existing file with Azure Service Mapping Table showing Component | Current Tech | Azure Service | Rationale -- Hosting strategy summary documenting decisions for each component (preserve existing content) -- Containerization plans for applicable services (preserve existing content) -- Infrastructure architecture design including resource organization and networking (preserve existing content) -- **IaC File Generation Checklist** listing all Bicep files that need to be created based on selected services (add to existing file) -- **Docker File Generation Checklist** listing all Docker files needed for containerized services (add to existing file) +**VALIDATION REQUIRED:** -🧠 **Execution Guidelines** +- All discovered components are properly mapped to Azure services +- Component dependencies and communication patterns are documented +- Azure service selections align with chosen technology stack and requirements +- Implementation plan provides clear next steps for infrastructure generation -**Azure Service Selection Criteria:** +**COMPLETION CHECKLIST:** -**Azure Container Apps (PREFERRED)** - Use for microservices, containerized applications, event-driven workloads with auto-scaling needs +- [ ] Read complete application spec to understand previously collected information +- [ ] Populate "Application Architecture" section with component details and relationships +- [ ] Complete "Azure Service Mapping" section with service assignments and rationale +- [ ] Update "Implementation Plan" section with infrastructure and deployment strategy +- [ ] Ensure all gathered context is documented in appropriate existing sections +- [ ] User has confirmed application specification -**Azure Kubernetes Service (AKS)** - Use for complex containerized applications requiring full Kubernetes control, advanced networking, custom operators +## Critical Planning Requirements -**Azure App Service** - Use for web applications, REST APIs needing specific runtime versions or Windows-specific features +**Component Architecture Documentation:** -**Azure Functions** - Use for event processing, scheduled tasks, lightweight APIs with pay-per-execution model +- Map each discovered component to its type (API/SPA/Worker/Function) +- Document component dependencies and communication patterns +- Define data architecture and access patterns +- Identify external integrations and requirements -**Azure Static Web Apps** - Use for frontend SPAs, static sites, JAMstack applications with minimal backend needs +**Azure Service Mapping:** -**Database Service Selection:** +- Assign appropriate Azure hosting services based on component types and stack selection +- Map data requirements to Azure data services (SQL, Cosmos DB, etc.) +- Select integration services for messaging and events +- Configure monitoring and security services -- Azure SQL Database: SQL Server compatibility, complex queries, ACID compliance -- Azure Database for PostgreSQL/MySQL: Specific engine compatibility required -- Azure Cosmos DB: NoSQL requirements, global scale, flexible schemas -- Azure Cache for Redis: Application caching, session storage, real-time analytics +**Implementation Strategy:** -**Messaging Service Selection:** - -- Azure Service Bus: Enterprise messaging, guaranteed delivery, complex routing -- Azure Event Hubs: High-throughput event streaming, telemetry ingestion -- Azure Event Grid: Event-driven architectures, reactive programming - -**IaC File Checklist Generation:** - -Based on selected Azure services, generate a checklist of required Bicep files to be created: - -**Always Required:** - -- [ ] `./infra/main.bicep` - Primary deployment template (subscription scope) -- [ ] `./infra/main.parameters.json` - Parameter defaults -- [ ] `./infra/modules/monitoring.bicep` - Log Analytics and Application Insights - -**Service-Specific Modules (include based on service selection):** - -- [ ] `./infra/modules/container-apps.bicep` - If Container Apps selected -- [ ] `./infra/modules/app-service.bicep` - If App Service selected -- [ ] `./infra/modules/functions.bicep` - If Azure Functions selected -- [ ] `./infra/modules/static-web-app.bicep` - If Static Web Apps selected -- [ ] `./infra/modules/aks.bicep` - If AKS selected -- [ ] `./infra/modules/database.bicep` - If SQL/PostgreSQL/MySQL selected -- [ ] `./infra/modules/cosmosdb.bicep` - If Cosmos DB selected -- [ ] `./infra/modules/storage.bicep` - If Storage Account needed -- [ ] `./infra/modules/keyvault.bicep` - If Key Vault needed (recommended) -- [ ] `./infra/modules/servicebus.bicep` - If Service Bus selected -- [ ] `./infra/modules/eventhub.bicep` - If Event Hubs selected -- [ ] `./infra/modules/redis.bicep` - If Redis Cache selected -- [ ] `./infra/modules/container-registry.bicep` - If container services selected - -**Example IaC Checklist Output:** - -```markdown -## Infrastructure as Code File Checklist - -Based on the selected Azure services, the following Bicep files need to be generated: - -### Core Files (Always Required) -- [ ] `./infra/main.bicep` - Primary deployment template -- [ ] `./infra/main.parameters.json` - Parameter defaults -- [ ] `./infra/modules/monitoring.bicep` - Observability stack - -### Service-Specific Modules -- [ ] `./infra/modules/container-apps.bicep` - For web API hosting -- [ ] `./infra/modules/database.bicep` - For PostgreSQL database -- [ ] `./infra/modules/keyvault.bicep` - For secrets management -- [ ] `./infra/modules/container-registry.bicep` - For container image storage - -Total files to generate: 7 -``` - -**Docker File Checklist Generation:** - -Based on selected Azure services and containerization strategy, generate a checklist of required Docker files: - -**Container-Based Services (include based on service selection):** - -- [ ] `{service-path}/Dockerfile` - If Container Apps, AKS, or containerized App Service selected -- [ ] `{service-path}/.dockerignore` - For each containerized service - -**Example Docker Checklist Output:** - -```markdown -## Docker File Generation Checklist - -Based on the containerization strategy, the following Docker files need to be generated: - -### Service Dockerfiles -- [ ] `./api/Dockerfile` - For Node.js API service (Container Apps) -- [ ] `./api/.dockerignore` - Exclude unnecessary files from API container -- [ ] `./frontend/Dockerfile` - For React frontend (containerized App Service) -- [ ] `./frontend/.dockerignore` - Exclude unnecessary files from frontend container - -Total Docker files to generate: 4 -``` - -📌 **Completion Checklist** - -- [ ] Azure service selected for each discovered component with documented rationale -- [ ] Hosting strategies defined and documented in `azd-arch-plan.md` -- [ ] Containerization plans documented for applicable services -- [ ] Data storage strategies planned and documented -- [ ] Resource group organization strategy defined -- [ ] Integration patterns between services documented -- [ ] **IaC file checklist generated** and added to `azd-arch-plan.md` based on selected services -- [ ] **Docker file checklist generated** and added to `azd-arch-plan.md` based on containerization strategy -- [ ] `azd-arch-plan.md` created or updated while preserving existing content -- [ ] Ready to proceed to infrastructure generation phase +- Define infrastructure generation requirements +- Plan deployment sequencing and dependencies +- Identify configuration and environment management needs +- Document next steps for artifact generation diff --git a/cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md new file mode 100644 index 00000000000..e0aabaf2074 --- /dev/null +++ b/cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md @@ -0,0 +1,52 @@ +# AZD Artifact Generation Orchestration Instructions + +**TASK:** Orchestrate the complete artifact generation process for AZD projects, generating infrastructure templates, application scaffolding, Docker configurations, and azure.yaml in the correct order with proper dependencies. + +**SUCCESS CRITERIA:** + +- Application scaffolding and starter code generated for new project components +- Docker configurations created for containerizable services +- Complete Bicep infrastructure templates generated in `./infra` directory +- Valid `azure.yaml` configuration file created mapping all services and resources +- All artifacts validated for syntax correctness and deployment compatibility + +**VALIDATION REQUIRED:** + +- All generated artifacts compile and validate without errors +- Infrastructure templates follow IaC generation rules and best practices +- Docker configurations are optimized and include health checks +- azure.yaml file validates against AZD schema +- Generated code is consistent with architecture planning decisions + +**COMPLETION CHECKLIST:** + +- [ ] Review application spec for complete project architecture and service specifications +- [ ] Generate infrastructure templates using IaC generation rules +- [ ] Generate application scaffolding for new project components +- [ ] Generate Docker configuration for containerizable services +- [ ] Generate azure.yaml configuration for AZD deployment +- [ ] Validate all generated artifacts for consistency and deployment readiness +- [ ] Update application spec with artifact generation status + +## Critical Generation Requirements + +**Generation Order:** + +1. Infrastructure templates first (foundation) +2. Application scaffolding second (code structure) +3. Docker configurations third (containerization) +4. azure.yaml configuration last (deployment orchestration) + +**Artifact Dependencies:** + +- Infrastructure generation requires architecture planning and IaC rules +- Application scaffolding requires component definitions and technology stack +- Docker generation requires application code and containerization requirements +- azure.yaml requires all service definitions and hosting decisions + +**Quality Requirements:** + +- Preserve existing user customizations where possible +- Follow security best practices (no hardcoded secrets) +- Ensure deployment readiness and Azure compatibility +- Maintain consistency across all generated artifacts diff --git a/cli/azd/internal/mcp/tools/prompts/azd_azure_yaml_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_azure_yaml_generation.md index 7496351c81e..d991d4af570 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_azure_yaml_generation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_azure_yaml_generation.md @@ -1,101 +1,51 @@ # AZD Azure.yaml Generation Instructions -✅ **Agent Task List** +**TASK:** Create a complete and valid `azure.yaml` file in the root directory that maps all application services to their Azure hosting services with proper build and deployment configurations. -1. Check if `azd-arch-plan.md` exists and review architecture decisions -2. Identify all application services (frontend, backend, functions, etc.) -3. Determine hosting requirements for each service based on Azure service selections -4. Analyze build requirements (language, package manager, build commands) -5. Create complete `azure.yaml` file in root directory following required patterns -6. Validate file against AZD schema using available tools -7. Update existing `azd-arch-plan.md` with generated configuration details while preserving existing content - -📄 **Required Outputs** +**SUCCESS CRITERIA:** - Valid `azure.yaml` file created in root directory -- Service configurations matching Azure service selections from architecture planning -- Build and deployment instructions for all services -- Configuration validated against AZD schema -- Update existing `azd-arch-plan.md` with configuration details while preserving existing content - -🧠 **Execution Guidelines** - -**Service Analysis Requirements:** - -Identify and configure these service types: - -- **Frontend applications:** React, Angular, Vue.js, static sites -- **Backend services:** REST APIs, microservices, GraphQL, gRPC -- **Function-based services:** Azure Functions for event-driven workloads -- **Background services:** Workers and long-running processes +- Service configurations match Azure service selections from architecture planning +- Build and deployment instructions complete for all services +- All service paths and Docker configurations reference existing files correctly -**Hosting Configuration Patterns:** +**VALIDATION REQUIRED:** -**Azure Container Apps** (for microservices, APIs, containerized apps): +- File validates against AZD schema using available tools +- All `project` paths point to existing directories +- All `docker.path` references point to existing Dockerfiles relative to service project path +- Host types match architecture decisions (containerapp, appservice, function, staticwebapp) +- Service names are alphanumeric with hyphens only -```yaml -services: - api: - project: ./src/api - language: js - host: containerapp - docker: - path: ./Dockerfile -``` +**COMPLETION CHECKLIST:** -**Azure App Service** (for traditional web apps): +- [ ] Check if application spec exists and review architecture decisions +- [ ] Identify all application services and their hosting requirements +- [ ] Create complete `azure.yaml` file with service configurations +- [ ] Validate file against AZD schema +- [ ] Update application spec with configuration details -```yaml -services: - webapp: - project: ./src/webapp - language: js - host: appservice -``` +## Critical Configuration Requirements -**Azure Functions** (for serverless workloads): +**Service Type Mappings:** -```yaml -services: - functions: - project: ./src/functions - language: js - host: function -``` +- **Azure Container Apps**: `host: containerapp` (for APIs, microservices, containerized apps) +- **Azure App Service**: `host: appservice` (for traditional web apps) +- **Azure Functions**: `host: function` (for serverless workloads) +- **Azure Static Web Apps**: `host: staticwebapp` (for SPAs, static sites) +- **Azure Kubernetes Service**: `host: aks` (for Kubernetes) -**Azure Static Web Apps** (for SPAs, static sites): +**Path Configuration Rules:** -```yaml -services: - frontend: - project: ./src/frontend - language: js - host: staticwebapp - dist: build -``` - -**Critical Configuration Requirements:** - -- Service names must be alphanumeric with hyphens only -- All `project` paths must point to existing directories -- All `docker.path` references must point to existing Dockerfiles **relative to the service project path** -- Host types must be: `containerapp`, `appservice`, `function`, or `staticwebapp` +- Service `project` paths must point to existing directories +- Docker `path` is relative to the service's project directory, not repository root - Language must match detected programming language -- `dist` paths must match build output directories - -**Important Note:** For Container Apps with Docker configurations, the `docker.path` is relative to the service's `project` directory, not the repository root. For example, if your service project is `./src/api` and the Dockerfile is located at `./src/api/Dockerfile`, the `docker.path` should be `./Dockerfile`. - -**Advanced Configuration Options:** - -- Environment variables using `${VARIABLE_NAME}` syntax -- Custom commands using hooks (prebuild, postbuild, prepackage, postpackage, preprovision, postprovision) -- Service dependencies and startup order +- `dist` paths must match build output directories for static apps -📌 **Completion Checklist** +**Required Configuration Elements:** -- [ ] Valid `azure.yaml` file created in root directory -- [ ] All discovered services properly configured with correct host types -- [ ] Service hosting configurations match Azure service selections from architecture planning -- [ ] Build and deployment instructions complete for all services -- [ ] File validates against any available AZD schema tools -- [ ] `azd-arch-plan.md` updated with configuration details while preserving existing content +- Service names (alphanumeric with hyphens only) +- Project paths (relative to repository root) +- Language specification +- Host type selection +- Build and deployment configurations diff --git a/cli/azd/internal/mcp/tools/prompts/azd_discovery_analysis.md b/cli/azd/internal/mcp/tools/prompts/azd_discovery_analysis.md index d14f99ca52e..cf402f32d14 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_discovery_analysis.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_discovery_analysis.md @@ -1,66 +1,52 @@ # AZD Application Discovery and Analysis Instructions -✅ **Agent Task List** +**TASK:** Scan and analyze the current workspace to identify all application components, technologies, dependencies, and communication patterns, documenting findings in the application specification. -1. Check if `azd-arch-plan.md` exists and review previous analysis if present -2. Scan current directory recursively for all files and document structure -3. Identify programming languages, frameworks, and configuration files -4. Classify discovered components by type (web apps, APIs, databases, etc.) -5. Map dependencies and communication patterns between components -6. Create `azd-arch-plan.md` if it doesn't exist, or update existing file with complete discovery report while preserving existing content +**SUCCESS CRITERIA:** -📄 **Required Outputs** +- Complete file system inventory documented in application specification +- All application components identified and classified by type +- Component technologies and frameworks documented with file locations +- Dependencies mapped and communication patterns understood +- External services and APIs catalogued with requirements -- Complete file system inventory documented in `azd-arch-plan.md` (create file if missing, update existing while preserving content) -- Component classification table with Type | Technology | Location | Purpose (add to existing file) -- Dependency map showing inter-component communication (add to existing file) -- External dependencies list with required environment variables (add to existing file) -- Discovery report ready for architecture planning phase +**VALIDATION REQUIRED:** -🧠 **Execution Guidelines** +- All major application artifacts discovered and documented +- Component classification is accurate and complete +- Dependencies and communication patterns are correctly identified +- Application specification is created or updated with comprehensive findings -**File System Analysis - Document:** +**COMPLETION CHECKLIST:** -- Programming languages and frameworks detected -- Configuration files (package.json, requirements.txt, pom.xml, Dockerfile, docker-compose.yml) +- [ ] Check if application specification exists and review previous analysis +- [ ] Scan workspace recursively for all application files and configurations +- [ ] Identify programming languages, frameworks, and configuration files +- [ ] Classify discovered components by type (web apps, APIs, databases, etc.) +- [ ] Map dependencies and communication patterns between components +- [ ] Create or update application specification with discovery findings + +## Critical Discovery Requirements + +**File System Analysis:** + +- Programming languages and frameworks +- Configuration files (package.json, requirements.txt, Dockerfile, etc.) - API endpoints, service definitions, application entry points -- Database configurations and connection strings -- CI/CD pipeline files (.github/workflows, azure-pipelines.yml) -- Documentation files and existing architecture docs +- Database configurations and connection patterns +- CI/CD pipeline files and deployment configurations -**Component Classification Categories:** +**Component Classification:** -- **Web Applications:** React/Angular/Vue.js apps, static sites, server-rendered apps -- **API Services:** REST APIs, GraphQL endpoints, gRPC services, microservices -- **Background Services:** Message queue processors, scheduled tasks, data pipelines -- **Databases:** SQL/NoSQL databases, caching layers, migration scripts -- **Messaging Systems:** Message queues, event streaming, pub/sub systems -- **AI/ML Components:** Models, inference endpoints, training pipelines -- **Supporting Services:** Authentication, logging, monitoring, configuration +- **Web Applications**: React/Angular/Vue.js apps, static sites, server-rendered apps +- **API Services**: REST APIs, GraphQL endpoints, gRPC services, microservices +- **Background Services**: Message processors, scheduled tasks, data pipelines +- **Databases**: SQL/NoSQL databases, caching layers, migration scripts +- **Supporting Services**: Authentication, logging, monitoring, configuration -**Dependency Analysis - Identify:** +**Dependency Analysis:** - Internal dependencies (component-to-component communication) - External dependencies (third-party APIs, SaaS services) - Data dependencies (shared databases, file systems, caches) - Configuration dependencies (shared settings, secrets, environment variables) -- Runtime dependencies (required services for startup) - -**Communication Patterns to Document:** - -- Synchronous HTTP/HTTPS calls -- Asynchronous messaging patterns -- Database connections and data access -- File system access patterns -- Caching patterns and session management -- Authentication and authorization flows - -📌 **Completion Checklist** - -- [ ] Complete inventory of all discoverable application artifacts documented -- [ ] All major application components identified and classified by type -- [ ] Component technologies and frameworks documented with file locations -- [ ] Dependencies mapped and communication patterns understood -- [ ] External services and APIs catalogued with requirements -- [ ] `azd-arch-plan.md` created or updated with comprehensive findings while preserving existing content -- [ ] Ready to proceed to architecture planning phase using `azd_architecture_planning` tool diff --git a/cli/azd/internal/mcp/tools/prompts/azd_docker_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_docker_generation.md index b09aee91625..45fcdff1a75 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_docker_generation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_docker_generation.md @@ -1,115 +1,56 @@ # AZD Docker Generation Instructions -✅ **Agent Task List** +**TASK:** Generate optimized Dockerfiles and .dockerignore files for all containerizable services based on the Docker File Generation Checklist from the application spec. -1. Read the **Docker File Generation Checklist** from `azd-arch-plan.md` -2. Identify containerizable services and required Docker files from the checklist -3. Detect programming language and framework for each containerizable service -4. Generate each Docker file specified in the checklist following language-specific best practices -5. Create .dockerignore files for build optimization -6. Implement health checks and security configurations -7. Update the Docker checklist section in existing `azd-arch-plan.md` by marking completed items as [x] while preserving existing content +**SUCCESS CRITERIA:** -📄 **Required Outputs** +- All Docker files listed in the application spec checklist are generated +- Dockerfiles follow language-specific best practices with multi-stage builds +- .dockerignore files created for build optimization +- Health check endpoints implemented for Container Apps compatibility +- Security configurations and non-root users implemented -- All Docker files listed in the Docker File Generation Checklist from `azd-arch-plan.md` -- Dockerfiles created for all containerizable services -- .dockerignore files generated for each service -- Health check endpoints implemented -- Multi-stage builds with security best practices -- Update existing `azd-arch-plan.md` Docker checklist by marking completed items as [x] while preserving existing content +**VALIDATION REQUIRED:** -🧠 **Execution Guidelines** +- All generated Dockerfiles build successfully without errors +- Health check endpoints respond correctly +- Docker images follow security best practices (non-root users, minimal base images) +- .dockerignore patterns exclude unnecessary files for efficient builds +- Application spec Docker checklist is updated with completion status -**Read Docker Checklist:** +**COMPLETION CHECKLIST:** -- Read the "Docker File Generation Checklist" section from `azd-arch-plan.md` -- This checklist specifies exactly which Docker files need to be generated -- Use this as the authoritative source for what to create -- Follow the exact file paths specified in the checklist +- [ ] Read Docker File Generation Checklist from application spec +- [ ] Identify containerizable services and required Docker files +- [ ] Generate Dockerfiles following language-specific best practices +- [ ] Create .dockerignore files for build optimization +- [ ] Implement health checks and security configurations +- [ ] Update Docker checklist in application spec marking completed items -**Generate Files in Order:** - -- Create service Dockerfiles first (e.g., `{service-path}/Dockerfile`) -- Create corresponding .dockerignore files for each service (e.g., `{service-path}/.dockerignore`) -- Follow the exact file paths specified in the checklist from `azd-arch-plan.md` +## Critical Docker Requirements **Containerization Candidates:** -- **Include:** Microservices, REST APIs, GraphQL services, web applications, background workers -- **Exclude:** Static websites (use Static Web Apps), Azure Functions (serverless), databases (use managed services) - -**Language-Specific Dockerfile Patterns:** - -**Node.js Applications:** - -- Base image: `node:18-alpine` -- Multi-stage build (build + runtime) -- Copy package*.json first for layer caching -- Use `npm ci --only=production` -- Non-root user: `nodejs` -- Expose port 3000, health check `/health` - -**Python Applications:** - -- Base image: `python:3.11-slim` -- Environment: `PYTHONDONTWRITEBYTECODE=1`, `PYTHONUNBUFFERED=1` -- Copy requirements.txt first -- Use `pip install --no-cache-dir` -- Non-root user: `appuser` -- Expose port 8000, health check `/health` - -**.NET Applications:** - -- Build: `mcr.microsoft.com/dotnet/sdk:8.0` -- Runtime: `mcr.microsoft.com/dotnet/aspnet:8.0` -- Multi-stage: restore → build → publish → runtime -- Non-root user: `appuser` -- Expose port 8080, health check `/health` - -**Java/Spring Boot:** - -- Build: `openjdk:17-jdk-slim`, Runtime: `openjdk:17-jre-slim` -- Copy dependency files first for caching -- Non-root user: `appuser` -- Expose port 8080, actuator health check - -**Security and Optimization Requirements:** - -- Always use non-root users in production stage -- Use minimal base images (alpine, slim variants) -- Implement multi-stage builds to reduce size -- Include health check endpoints for Container Apps -- Set proper working directories and file permissions -- Use layer caching by copying dependency files first -- Never include secrets in container images - -**.dockerignore Patterns:** - -- Universal: `.git`, `README.md`, `.vscode/`, `.DS_Store`, `Dockerfile*` -- Node.js: `node_modules/`, `npm-debug.log*`, `coverage/` -- Python: `__pycache__/`, `*.pyc`, `venv/`, `.pytest_cache/` -- .NET: `bin/`, `obj/`, `*.user`, `packages/` -- Java: `target/`, `*.class`, `.mvn/repository` - -**Health Check Implementation:** - -- Endpoint: `/health` (standard convention) -- Response: JSON with status and timestamp -- HTTP Status: 200 for healthy, 503 for unhealthy -- Timeout: 3 seconds maximum -- Content: `{"status": "healthy", "timestamp": "ISO-8601"}` - -📌 **Completion Checklist** - -- [ ] **Docker File Generation Checklist read** from `azd-arch-plan.md` -- [ ] **All files from Docker checklist generated** in the correct locations -- [ ] Dockerfiles created for all containerizable services identified in architecture planning -- [ ] .dockerignore files generated with appropriate exclusions for each language -- [ ] Multi-stage builds implemented to reduce image size -- [ ] Non-root users configured for security -- [ ] Health check endpoints implemented for all services -- [ ] Container startup optimization applied (dependency file caching) -- [ ] All Dockerfiles build successfully (`docker build` test) -- [ ] Security best practices followed (minimal images, no secrets) -- [ ] **Docker checklist in `azd-arch-plan.md` updated** by marking completed items as [x] while preserving existing content +- **Include**: Microservices, REST APIs, GraphQL services, web applications, background workers +- **Exclude**: Static websites (use Static Web Apps), Azure Functions (serverless), databases (use managed services) + +**Essential Dockerfile Elements:** + +- Multi-stage builds (build + runtime stages) +- Minimal base images (alpine, slim variants) +- Non-root users in production stage +- Health check endpoints (`/health` for Container Apps) +- Proper layer caching (copy dependency files first) +- Security hardening and file permissions + +**Language-Specific Patterns:** + +- **Node.js**: `node:18-alpine` base, npm ci, port 3000 +- **Python**: `python:3.11-slim` base, pip install, port 8000 +- **.NET**: Multi-stage with SDK/runtime separation, port 8080 +- **Java**: OpenJDK slim variants, dependency optimization + +**.dockerignore Requirements:** + +- Universal exclusions: `.git`, `README.md`, `.vscode/`, `Dockerfile*` +- Language-specific: `node_modules/`, `__pycache__/`, `bin/obj/`, `target/` diff --git a/cli/azd/internal/mcp/tools/prompts/azd_generate_infra_module.md b/cli/azd/internal/mcp/tools/prompts/azd_generate_infra_module.md new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/prompts/azd_iac_generation_rules.md b/cli/azd/internal/mcp/tools/prompts/azd_iac_generation_rules.md index d472440046c..a0159b9bd11 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_iac_generation_rules.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_iac_generation_rules.md @@ -1,164 +1,83 @@ # Infrastructure as Code (IaC) Generation Rules -✅ **Agent Task List** +**TASK:** Provide authoritative rules and standards for generating Bicep infrastructure templates that follow Azure Well-Architected Framework principles and AZD conventions. -1. Reference these rules when generating any IaC files -2. Follow file structure and organization requirements -3. Implement naming conventions and tagging strategies -4. Apply security and compliance best practices -5. Validate all generated code against these requirements +**SUCCESS CRITERIA:** -📄 **Required Outputs** - -- IaC files following all specified rules and conventions -- Proper file structure in `./infra` directory +- IaC files follow all specified rules and conventions +- Proper file structure in `./infra` directory with modular organization - Compliance with Azure Well-Architected Framework principles -- Security best practices implemented -- Validation passing without errors +- Security best practices implemented throughout +- Latest Bicep schema versions used for all resource types -🧠 **Execution Guidelines** +**VALIDATION REQUIRED:** -**File Structure and Organization:** +- All generated Bicep templates compile without errors or warnings +- Naming conventions follow required patterns with unique hash generation +- Security requirements are met (no hardcoded secrets, proper permissions) +- Resource specifications follow container and service requirements +- Tagging strategy is properly implemented -- **REQUIRED:** Place all IaC files in `./infra` folder -- **REQUIRED:** Name main deployment file `main.bicep` -- **REQUIRED:** Create `main.parameters.json` with parameter defaults -- **REQUIRED:** Main.bicep must use `targetScope = 'subscription'` -- **REQUIRED:** Create resource group as primary container -- **REQUIRED:** Pass resource group scope to all child modules -- **REQUIRED:** Create modular, reusable Bicep files +**COMPLETION CHECKLIST:** -**Naming Conventions:** +- [ ] Use these rules when generating any IaC files +- [ ] Follow file structure and organization requirements +- [ ] Implement naming conventions and tagging strategies +- [ ] Apply security and compliance best practices +- [ ] Validate all generated code against these requirements -- **REQUIRED:** Use pattern `{resourcePrefix}-{name}-{uniqueHash}` -- **REQUIRED:** Generate unique hash from environment name, subscription ID, and resource group name -- **EXAMPLE:** `app-myservice-h3x9k2` where `h3x9k2` is generated -- **FORBIDDEN:** Hard-code tenant IDs, subscription IDs, or resource group names +## Critical IaC Standards -**Module Parameters (All modules must accept):** +**File Structure Requirements:** -- `name` (string): Base name for the resource -- `location` (string): Azure region for deployment -- `tags` (object): Resource tags for governance -- **REQUIRED:** Modules use `targetScope = 'resourceGroup'` -- **REQUIRED:** Provide intelligent defaults for optional parameters -- **REQUIRED:** Use parameter decorators for validation +- **REQUIRED**: All IaC files in `./infra` folder +- **REQUIRED**: Modular, reusable Bicep files with `targetScope = 'resourceGroup'` +- **REQUIRED**: Main deployment file named `main.bicep` with `targetScope = 'subscription'` and references all required modules +- **REQUIRED**: `main.parameters.json` referencing environment variables -**Tagging Strategy:** +**Naming Conventions:** -- **REQUIRED:** Tag resource groups with `azd-env-name: {environment-name}` -- **REQUIRED:** Tag hosting resources with `azd-service-name: {service-name}` -- **RECOMMENDED:** Include governance tags (cost center, owner, etc.) +- **REQUIRED**: Pattern `{resourcePrefix}-{name}-{uniqueHash}` +- **REQUIRED**: Use naming conventions compatible for each Azure resource type +- **REQUIRED**: Generate unique hash from environment name, subscription ID, and resource group name +- **FORBIDDEN**: Hard-code tenant IDs, subscription IDs, or resource group names **Security and Compliance:** -- **FORBIDDEN:** Hard-code secrets, connection strings, or sensitive values -- **REQUIRED:** Use latest API versions and schema for all bicep resource types using available tools -- **REQUIRED:** Use Key Vault references for secrets -- **REQUIRED:** Enable diagnostic settings and logging where applicable -- **REQUIRED:** Follow principle of least privilege for managed identities -- **REQUIRED:** Follow Azure Well-Architected Framework principles +- **FORBIDDEN**: Hard-code secrets, connection strings, or sensitive values +- **REQUIRED**: Use latest API versions and schemas for all resource types +- **REQUIRED**: Key Vault references for secrets +- **REQUIRED**: Diagnostic settings and logging where applicable +- **REQUIRED**: Principle of least privilege for managed identities -**Container Resource Specifications:** +**Resource Specifications:** -- **REQUIRED:** Wrap partial CPU values in `json()` function (e.g., `json('0.5')` for 0.5 CPU cores) -- **REQUIRED:** Memory values should be strings with units (e.g., `'0.5Gi'`, `'1Gi'`, `'2Gi'`) -- **EXAMPLE:** Container Apps resource specification: - - ```bicep - resources: { - cpu: json('0.25') // Correct: wrapped in json() - memory: '0.5Gi' // Correct: string with units - } - ``` +- **REQUIRED**: Wrap partial CPU values in `json()` function (e.g., `json('0.5')`) +- **REQUIRED**: Memory values as strings with units (e.g., `'0.5Gi'`, `'1Gi'`) +- **REQUIRED**: Proper tagging with `azd-env-name` and `azd-service-name` **Supported Azure Services:** -**Primary Hosting Resources (Choose One):** - -- **Azure Container Apps** (PREFERRED): Containerized applications, built-in scaling -- **Azure App Service:** Web applications and APIs, multiple runtime stacks -- **Azure Function Apps:** Serverless and event-driven workloads -- **Azure Static Web Apps:** Frontend applications, built-in CI/CD -- **Azure Kubernetes Service (AKS):** Complex containerized workloads - -**Essential Supporting Resources (REQUIRED for most applications):** - -- **Log Analytics Workspace:** Central logging and monitoring -- **Application Insights:** Application performance monitoring -- **Azure Key Vault:** Secure storage for secrets and certificates - -**Conditional Resources (Include based on requirements):** - -- Azure Container Registry (for container-based apps) -- Azure Service Bus (for messaging scenarios) -- Azure Cosmos DB (for NoSQL data storage) -- Azure SQL Database (for relational data storage) -- Azure Storage Account (for blob/file storage) -- Azure Cache for Redis (for caching scenarios) - -**Main.bicep Structure Template:** - -```bicep -targetScope = 'subscription' -@description('Name of the environment') -param environmentName string -@description('Location for all resources') -param location string -@description('Tags to apply to all resources') -param tags object = {} - -// Generate unique suffix for resource names -var resourceSuffix = take(uniqueString(subscription().id, environmentName, location), 6) -var resourceGroupName = 'rg-${environmentName}-${resourceSuffix}' - -// Create the resource group -resource resourceGroup 'Microsoft.Resources/resourceGroups@2021-04-01' = { - name: resourceGroupName - location: location - tags: union(tags, { - 'azd-env-name': environmentName - }) -} - -// Example module deployment with resource group scope -module appService 'modules/app-service.bicep' = { - name: 'app-service' - scope: resourceGroup - params: { - name: 'myapp' - location: location - tags: tags +- **Primary Hosting**: Container Apps (preferred), App Service, Function Apps, Static Web Apps, AKS +- **Essential Supporting**: Log Analytics Workspace, Application Insights, Key Vault +- **Conditional**: Container Registry, Service Bus, Cosmos DB, SQL Database, Storage Account, Cache for Redis + +**Example main.parameters.json:** + +```json +{ + "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#", + "contentVersion": "1.0.0.0", + "parameters": { + "environmentName": { + "value": "${AZURE_ENV_NAME}" + }, + "location": { + "value": "${AZURE_LOCATION}" + }, + "principalId": { + "value": "${AZURE_PRINCIPAL_ID}" + } } } ``` - -**Child Module Structure Template:** - -```bicep -targetScope = 'resourceGroup' -@description('Base name for all resources') -param name string -@description('Location for all resources') -param location string = resourceGroup().location -@description('Tags to apply to all resources') -param tags object = {} - -// Generate unique suffix for resource names -var resourceSuffix = take(uniqueString(subscription().id, resourceGroup().name, name), 6) -var resourceName = '${name}-${resourceSuffix}' - -// Resource definitions here... -``` - -📌 **Completion Checklist** - -- [ ] All files placed in `./infra` folder with correct structure -- [ ] `main.bicep` exists with subscription scope and resource group creation -- [ ] `main.parameters.json` exists with parameter defaults -- [ ] All child modules use `targetScope = 'resourceGroup'` and receive resource group scope -- [ ] Consistent naming convention applied: `{resourcePrefix}-{name}-{uniqueHash}` -- [ ] Required tags applied: `azd-env-name` and `azd-service-name` -- [ ] No hard-coded secrets, tenant IDs, or subscription IDs -- [ ] Parameters have appropriate validation decorators -- [ ] Security best practices followed (Key Vault, managed identities, diagnostics) diff --git a/cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md b/cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md new file mode 100644 index 00000000000..1a92b51ae83 --- /dev/null +++ b/cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md @@ -0,0 +1,55 @@ +# AZD Project Intent and Requirements Discovery Instructions + +**TASK:** Engage users with conversational questions to understand project purpose, scale requirements, budget constraints, and architectural preferences, then classify and document findings. + +**SUCCESS CRITERIA:** + +- Project classification determined (POC, Development Tool, or Production Application) +- Scale category identified for production applications (Small, Medium, or Large) +- Budget constraint level established (Cost-Optimized, Balanced, or Performance-Focused) +- Architectural preference documented (Containers, Serverless, Hybrid, or No Preference) +- Comprehensive requirements summary documented in application specification + +**VALIDATION REQUIRED:** + +- All critical requirements gathered through conversational questions +- Project classification aligns with user responses about purpose and audience +- Scale and budget preferences are clearly documented +- Technology and architectural preferences are captured +- Requirements are properly documented in application specification + +**COMPLETION CHECKLIST:** + +- [ ] Engage user with conversational questions about project purpose and stage +- [ ] Determine application scale requirements and production readiness +- [ ] Identify budget and cost constraint considerations +- [ ] Understand architectural and technology stack preferences +- [ ] Classify project into appropriate categories +- [ ] Document findings in application specification under "Project Requirements" + +## Critical Discovery Questions + +**Project Purpose and Stage:** + +- Main purpose of the application and intended audience +- Project stage (POC/prototype, development tool, or production application) +- Problem the application solves and success criteria + +**Scale and Performance (Production Applications):** + +- Expected user base at launch and growth projections +- Geographic distribution and availability requirements +- Performance criticality and response time needs + +**Budget and Cost Considerations:** + +- Budget constraints and cost targets +- Priority between cost optimization vs performance +- Preference for predictable vs consumption-based pricing + +**Architectural and Technology Preferences:** + +- Team experience with containers, serverless, or infrastructure management +- Programming language and framework preferences +- Technology constraints from organization or existing systems +- Control vs managed services preference diff --git a/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md index b44f63962d8..70227a59489 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md @@ -1,166 +1,52 @@ # AZD Infrastructure Generation Instructions -✅ **Agent Task List** +**TASK:** Generate complete Bicep infrastructure templates in `./infra` directory based on the Infrastructure as Code File Checklist, using latest schema versions and following IaC generation rules. -1. Strictly follow Azure and Bicep best practices in all code generation -2. Strictly follow AZD IaC generation rules during all code generation -3. **Inventory existing IaC files** - scan current working directory for all `.bicep` files -4. Read `azd-arch-plan.md` to get the **IaC File Generation Checklist** -5. Create directory structure in `./infra` following IaC rules -6. During code generation always use the latest version for each resource type using the bicep schema tool -7. For each file in the IaC checklist: - - **If file exists**: Intelligently update to match requirements, preserve user customizations where possible - - **If file missing**: Generate new file following templates and best practices - - **Flag conflicts**: Note any incompatible configurations but proceed with updates -8. Validate all generated bicep templates compile without errors or warnings -9. Update the IaC checklist section in existing `azd-arch-plan.md` by marking completed files as [x] while preserving existing content +**SUCCESS CRITERIA:** -📄 **Required Outputs** +- Complete Bicep template structure created in `./infra` directory +- All files from IaC checklist generated or updated intelligently +- Generic resource modules and service-specific modules created +- All templates validated and compile without errors +- Application spec IaC checklist updated with completion status -- **Existing IaC inventory** documenting all current `.bicep` files found -- Complete Bicep template structure in `./infra` directory based on the IaC checklist -- All files listed in the IaC File Generation Checklist from `azd-arch-plan.md` (created or updated) -- Main.bicep file with subscription scope and modular deployment -- Service-specific modules for each Azure service from the checklist -- Parameter files with sensible defaults -- **Conflict report** highlighting any incompatible configurations that were updated -- All templates validated and error-free -- Update existing `azd-arch-plan.md` IaC checklist by marking completed files as [x] while preserving existing content +**VALIDATION REQUIRED:** -🧠 **Execution Guidelines** +- All Bicep templates compile without errors or warnings +- Latest schema versions used for all Azure resource types +- IaC generation rules followed for naming, security, and structure +- Existing user customizations preserved where compatible +- Infrastructure templates are deployment-ready -**Use Tools:** +**COMPLETION CHECKLIST:** -- Use AZD IaC generation rules tool first to get complete file structure, naming conventions, and compliance requirements. -- Use Bicep Schema tool get get the latest API version and bicep schema for each resource type +- [ ] Inventory existing IaC files and scan workspace for current templates +- [ ] Read application spec Infrastructure as Code File Checklist +- [ ] Get IaC generation rules and latest Bicep schema versions +- [ ] Create directory structure in `./infra` following IaC rules +- [ ] Generate or update each file from the checklist intelligently +- [ ] Create generic resource modules and service-specific modules +- [ ] Validate all templates compile without errors +- [ ] Update IaC checklist in application spec marking completed files -**Inventory Existing IaC Files:** +## Critical Generation Requirements -- Scan current working directory recursively for all `.bicep` files -- Document existing files, their locations, and basic structure -- Note any existing modules, parameters, and resource definitions -- Identify which checklist files already exist vs. need to be created +**Generation Strategy:** -**Read IaC Checklist:** +- **Existing Files**: Preserve user customizations, add missing components, update outdated patterns +- **New Files**: Create from templates following IaC generation rules with using latest Bicep schema versions +- **Conflict Resolution**: Document conflicts, prioritize AZD compatibility, preserve architectural intent -- Read the "Infrastructure as Code File Checklist" section from `azd-arch-plan.md` -- This checklist specifies exactly which Bicep files need to be generated -- Cross-reference with existing file inventory to determine update vs. create strategy +**Module Architecture:** -**Smart File Generation Strategy:** +- **Generic Resource Modules**: Reusable patterns (`modules/containerapp.bicep`, `modules/storage.bicep`) +- **Service-Specific Modules**: Business logic with specific configurations (`modules/user-api.bicep`) +- **Main Template**: Subscription scope deployment orchestrating all modules -**For Existing Files:** - -- **Preserve user customizations**: Keep existing resource configurations, naming, and parameters where compatible -- **Add missing components**: Inject required modules, resources, or configurations that are missing -- **Update outdated patterns**: Modernize to use current best practices -- **Maintain functionality**: Ensure existing deployments continue to work - -**For New Files:** - -- Create from templates following IaC generation rules -- Follow standard naming conventions and patterns - -**Conflict Resolution:** - -- **Document conflicts**: Log when existing configurations conflict with requirements -- **Prioritize functionality**: Make changes needed for AZD compatibility -- **Preserve intent**: Keep user's architectural decisions when possible -- **Flag major changes**: Clearly indicate significant modifications made - -**Generate Files in Order:** - -- Create `./infra/main.bicep` first (always required) -- Create `./infra/main.parameters.json` second (always required) -- Generate each module file listed in the checklist -- Follow the exact file paths specified in the checklist - -**Main Parameters File Requirements:** - -The `./infra/main.parameters.json` file is critical for AZD integration and must follow this exact structure: - -```json -{ - "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#", - "contentVersion": "1.0.0.0", - "parameters": { - "environmentName": { - "value": "${AZURE_ENV_NAME}" - }, - "location": { - "value": "${AZURE_LOCATION}" - }, - "principalId": { - "value": "${AZURE_PRINCIPAL_ID}" - } - } -} -``` - -**Key Features:** - -- **Environment Variable Substitution**: Uses `${VARIABLE_NAME}` syntax for dynamic values -- **Standard Parameters**: Always include `environmentName`, `location`, and `principalId` -- **AZD Integration**: These variables are automatically populated by AZD during deployment -- **Additional Parameters**: Add service-specific parameters as needed, using the same substitution pattern - -**Service Infrastructure Mapping:** - -- **Container Apps:** Environment, Log Analytics, Container Registry, App Insights, Managed Identity -- **App Service:** Service Plan, App Service, App Insights, Managed Identity -- **Functions:** Function App, Storage Account, App Insights, Managed Identity -- **Static Web Apps:** Static Web App resource with configuration -- **Database:** SQL/CosmosDB/PostgreSQL with appropriate SKUs and security - -**Module Template Requirements:** - -- Use `targetScope = 'resourceGroup'` for all modules -- Accept resource group scope from main template -- Use standardized parameters (name, location, tags) -- Follow naming convention: `{resourcePrefix}-{name}-{uniqueHash}` -- Output connection information for applications -- Include security best practices and monitoring - -**Required Directory Structure:** - -```text -./infra/ -├── main.bicep # Primary deployment template (subscription scope) -├── main.parameters.json # Default parameters -├── modules/ -│ ├── container-apps.bicep -│ ├── app-service.bicep -│ ├── functions.bicep -│ ├── database.bicep -│ ├── storage.bicep -│ ├── keyvault.bicep -│ └── monitoring.bicep -└── resources.bicep # Shared resources -``` - -**Main Template Requirements:** - -- Use `targetScope = 'subscription'` -- Accept standardized parameters: `environmentName`, `location`, `principalId` -- Include feature flags for conditional deployment -- Create resource group with proper tagging (`azd-env-name`) -- Call modules conditionally based on service requirements -- Output connection strings and service endpoints - -📌 **Completion Checklist** - -- [ ] `azd_iac_generation_rules` tool referenced for complete compliance requirements -- [ ] **Existing IaC inventory completed** - all `.bicep` files in current directory catalogued -- [ ] **IaC File Generation Checklist read** from `azd-arch-plan.md` -- [ ] **Update vs. create strategy determined** for each file in checklist -- [ ] **All files from checklist generated or updated** in the correct locations -- [ ] **User customizations preserved** where compatible with requirements -- [ ] **Conflicts documented** and resolved with functional priority -- [ ] Infrastructure directory structure created following IaC rules -- [ ] Main.bicep template created/updated with subscription scope and resource group -- [ ] Module templates generated/updated for all services listed in checklist -- [ ] Parameter files created/updated with appropriate defaults -- [ ] Naming conventions and tagging implemented correctly -- [ ] Security best practices implemented (Key Vault, managed identities) -- [ ] **IaC checklist in `azd-arch-plan.md` updated** by marking completed files as [x] while preserving existing content +**File Generation Order:** +1. Generic resource modules in `./infra/modules/` +2. Service-specific modules in `./infra/modules/` +3. `./infra/main.bicep` (subscription scope orchestration) references all required modules +4. `./infra/main.parameters.json` (parameter defaults) +5. Follow exact paths from application spec checklist diff --git a/cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md b/cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md new file mode 100644 index 00000000000..b088c87e8d2 --- /dev/null +++ b/cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md @@ -0,0 +1,47 @@ +# AZD Stack Resources List + +**TASK:** Provide the definitive list of Azure resources required for each technology stack (baseline and stack-specific) to guide architecture planning and infrastructure generation. + +**SUCCESS CRITERIA:** + +- Complete understanding of baseline resources shared across all stacks +- Detailed knowledge of stack-specific resources and their purposes +- Azure resource type identifiers available for precise infrastructure generation +- Resource relationships and dependencies understood for proper deployment ordering + +**VALIDATION REQUIRED:** + +- Resource definitions are current and match latest Azure service capabilities +- Stack-specific resources align with architectural approaches +- Resource dependencies and integration patterns are clearly documented +- Resource specifications support both planning and generation phases + +**COMPLETION CHECKLIST:** + +- [ ] Review baseline Azure resources required for all AZD projects +- [ ] Review stack-specific Azure resources for the selected technology stack +- [ ] Understand the purpose and configuration of each resource type +- [ ] Use these resource definitions for architecture planning and infrastructure generation +- [ ] Update application specification to include all required files within IaC checklist + +## Critical Resource Categories + +**Baseline Resources (All Stacks):** + +- Essential capabilities for logging, monitoring, configuration management, and secure storage +- Provisioned regardless of selected technology stack +- Foundation for all AZD projects + +**Stack-Specific Resources:** + +- **Containers Stack**: Resources optimized for containerized workloads +- **Serverless Stack**: Resources for event-driven and function-based architectures +- **Logic Apps Stack**: Resources for workflow automation and integration scenarios + +**Usage Guidelines:** + +- **Architecture Planning**: Map application components to appropriate Azure resources +- **Infrastructure Generation**: Provide exact resource type identifiers and configurations +- **Resource Organization**: Plan resource group structure and naming conventions +- **Deployment Sequencing**: Determine resource dependencies and deployment order +- **Integration Patterns**: Configure monitoring, security, and access control diff --git a/cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md b/cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md new file mode 100644 index 00000000000..69e0c581732 --- /dev/null +++ b/cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md @@ -0,0 +1,60 @@ +# AZD Project Modernization and Migration Instructions + +**TASK:** Modernize existing applications to be AZD compatible by conducting analysis, requirements discovery, stack selection, architecture planning, and artifact generation while preserving existing functionality. + +**SUCCESS CRITERIA:** + +- Comprehensive application specification preserving existing project context +- Complete AZD compatible project structure created for existing application +- Bicep infrastructure templates generated in `./infra` directory +- Dockerfiles created for containerizable services where applicable +- Valid `azure.yaml` configuration file mapping existing components +- Validated project ready for `azd up` deployment + +**VALIDATION REQUIRED:** + +- Existing application functionality is preserved throughout modernization +- Generated artifacts are compatible with existing code and architecture +- Migration strategy aligns with user requirements and constraints +- All components are properly mapped to Azure services +- AZD project validation passes with all errors resolved + +**COMPLETION CHECKLIST:** + +- [ ] Analyze existing application architecture and codebase +- [ ] Conduct user intent discovery for requirements and constraints +- [ ] Determine optimal technology stack based on existing code and preferences +- [ ] Perform discovery analysis for comprehensive component identification +- [ ] Conduct architecture planning for Azure service selection +- [ ] Generate artifacts to create AZD compatible project structure +- [ ] Run full AZD project validation and address all errors +- [ ] Document complete modernization in application specification + +## Critical Modernization Requirements + +**Existing Project Evaluation:** + +- Scan workspace for application components, frameworks, and technologies +- Assess existing containerization and deployment configurations +- Review existing Azure resources or configuration +- Note any existing application architecture documentation + +**Migration-Specific Considerations:** + +- Preserve existing application functionality and architecture decisions +- Maintain backward compatibility during migration process +- Address current pain points or limitations identified by user +- Consider team comfort with existing vs new architectural patterns + +**Technology Stack Alignment:** + +- **Automatic Determination**: Based on clear code analysis (Docker files, architecture patterns) +- **Manual Selection**: When ambiguous, focus on team comfort and modernization goals +- **Migration Strategy**: Document chosen approach and rationale + +**Artifact Generation Strategy:** + +- **Preserve Existing**: Keep user customizations and working configurations +- **Add Missing**: Inject AZD required components and configurations +- **Modernize Patterns**: Update to current best practices where beneficial +- **Ensure Compatibility**: Maintain existing deployment and operational patterns diff --git a/cli/azd/internal/mcp/tools/prompts/azd_new_project.md b/cli/azd/internal/mcp/tools/prompts/azd_new_project.md new file mode 100644 index 00000000000..a0d2fe9ac2d --- /dev/null +++ b/cli/azd/internal/mcp/tools/prompts/azd_new_project.md @@ -0,0 +1,61 @@ +# AZD New Project Creation Orchestration Instructions + +**TASK:** Orchestrate complete new project creation from scratch through requirements discovery, stack selection, architecture planning, and file generation guidance to create a ready-to-implement project specification. + +**SUCCESS CRITERIA:** + +- Complete application specification document created with all project details +- Technology stack recommendation provided with clear rationale +- Azure service architecture design completed with component mappings +- File generation roadmap established for implementation phase +- Project specification serves as blueprint for deployment + +**VALIDATION REQUIRED:** + +- All project requirements gathered through systematic discovery process +- Stack selection aligns with team expertise and project characteristics +- Architecture design supports identified requirements and constraints +- Project specification is comprehensive and implementation-ready +- Validation checklist confirms project readiness + +**COMPLETION CHECKLIST:** + +- [ ] Welcome user and confirm new project creation intent +- [ ] Conduct user intent discovery for project requirements and constraints +- [ ] Perform stack selection process to determine optimal technology approach +- [ ] Conduct architecture planning for Azure service mappings and infrastructure +- [ ] Document comprehensive project specification +- [ ] Provide file generation guidance and next steps for implementation +- [ ] Run full AZD project validation and address all errors +- [ ] Ensure project specification is complete and up-to-date + +## Critical Creation Process + +**Project Initiation:** + +- Confirm new project creation (no existing code or infrastructure) +- Verify user wants AZD compatible Azure project +- Explain systematic discovery and planning process +- Create new application specification for documentation + +**Requirements Discovery Phase:** + +- Project purpose and classification (POC, Development Tool, Production Application) +- Expected scale and user base requirements +- Budget and cost considerations +- Performance and availability expectations +- Timeline and deployment urgency + +**Stack Selection Phase:** + +- Team technical expertise and preferences +- Application characteristics and complexity requirements +- Performance and scalability needs +- Integration and workflow requirements + +**Architecture Planning Phase:** + +- Application component breakdown and relationships +- Azure service mappings based on stack selection +- Infrastructure and deployment strategy +- Implementation roadmap and next steps diff --git a/cli/azd/internal/mcp/tools/prompts/azd_plan_init.md b/cli/azd/internal/mcp/tools/prompts/azd_plan_init.md index e8bd2e1685c..14edd035378 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_plan_init.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_plan_init.md @@ -1,98 +1,66 @@ -# AZD Application Initialization and Migration Instructions +# AZD Project Initialization Decision Tree Instructions -✅ **Agent Task List** +**TASK:** Analyze workspace contents to determine project state, classify as "new project" or "existing application", route users to appropriate workflow, and execute the selected workflow with proper tool orchestration. -1. **Check Progress:** Review existing `azd-arch-plan.md` to understand completed work -2. **Phase 1:** Execute `azd_discovery_analysis` for component identification -3. **Phase 2:** Execute `azd_architecture_planning` for Azure service selection -4. **Phase 3:** Execute file generation tools (`azd_azure_yaml_generation`, `azd_infrastructure_generation`, `azd_docker_generation`) -5. **Phase 4:** Execute `azd_project_validation` for complete validation -6. **Final:** Confirm project readiness for deployment +**SUCCESS CRITERIA:** -📄 **Required Outputs** +- Workspace analysis completed with clear routing decision rationale +- User confirmation obtained for selected workflow path +- Chosen workflow executed completely (new project creation or application modernization) +- Professional application specification document created +- Validated AZD compatible project ready for deployment -- Complete AZD-compatible project structure -- Valid `azure.yaml` configuration file -- Bicep infrastructure templates in `./infra` directory -- Dockerfiles for containerizable services -- Comprehensive `azd-arch-plan.md` documentation (created or updated while preserving existing content) -- Validated project ready for `azd up` deployment +**VALIDATION REQUIRED:** -🧠 **Execution Guidelines** +- Workspace analysis correctly identifies application vs minimal content +- Routing decision aligns with workspace contents and user intentions +- Selected workflow completes successfully with all required components +- Generated project passes AZD validation requirements +- Application specification provides comprehensive project documentation -**CRITICAL:** Always check if `azd-arch-plan.md` exists first to understand current progress and avoid duplicate work. If the file exists, preserve all existing content and user modifications while updating relevant sections. +**COMPLETION CHECKLIST:** -**Complete Workflow Phases:** +- [ ] Analyze current workspace to determine project state and contents +- [ ] Classify workspace as "empty/minimal" or "existing application" +- [ ] Route user to appropriate workflow with confirmation +- [ ] Perform selected workflow with proper tool orchestration +- [ ] Update application specification throughout the workflow +- [ ] Validate final project readiness for deployment -**Phase 1: Review Existing Progress** +## Critical Analysis and Routing -- Check if `azd-arch-plan.md` exists in current directory -- If exists: Review thoroughly and skip completed phases -- If doesn't exist: Proceed to Phase 2 +**Workspace Classification Logic:** -**Phase 2: Discovery and Analysis** +**Route to New Project Creation:** -- Tool: `azd_discovery_analysis` -- Scans files recursively, documents structure/languages/frameworks -- Identifies entry points, maps dependencies, creates component inventory -- Updates `azd-arch-plan.md` with findings +- No programming language files found +- Only documentation and git files present +- Empty workspace or minimal placeholder content +- User explicitly wants to start from scratch -**Phase 3: Architecture Planning and Azure Service Selection** +**Route to Application Modernization:** -- Tool: `azd_architecture_planning` -- Maps components to Azure services, plans hosting strategies -- Designs database/messaging architecture, creates containerization strategies -- Updates `azd-arch-plan.md` with service selections +- Application code files detected (any programming language) +- Framework configuration files present (package.json, requirements.txt, etc.) +- Docker files or containerization artifacts found +- Clear application structure and entry points -**Phase 4: File Generation (Execute in Sequence)** +**Handle Existing AZD Projects:** -Using available tools - Generate the following files: +- If `azure.yaml` exists, determine update/refinement needs +- Check completeness of existing AZD configuration +- Route to appropriate maintenance workflow -1. **Docker Configurations:** Generate docker files (Required for containerizable services) -2. **Infrastructure Templates:** Generate IaC infrastructure templates (Required for all projects) -3. **Azure.yaml Configuration:** Generate `azure.yaml` file (Required for all projects) +**User Confirmation Process:** -**Phase 5: Project Validation and Environment Setup** +- Present analysis results with detected technologies and recommendations +- Explain chosen workflow path and what it will accomplish +- Obtain explicit user confirmation before proceeding +- Handle ambiguous cases by presenting options and letting user choose -Using available tools - Perform and end-to-end AZD project validation +**Workflow Execution:** -- Validates azure.yaml against schema -- Validate AZD environment exists -- Validate infrastructure templates -- Ensures AZD environment exists, tests packaging, validates deployment preview -- Provides readiness confirmation - -**Usage Patterns:** - -**Complete New Project Migration:** - -```text -1. Review azd-arch-plan.md → 2. azd_discovery_analysis → 3. azd_architecture_planning → -4. azd_azure_yaml_generation → 5. azd_infrastructure_generation → 6. azd_docker_generation → -7. azd_project_validation -``` - -**Update Existing AZD Project:** - -```text -1. Review azd-arch-plan.md → 2. File generation tools → 3. azd_project_validation -``` - -**Quick Service Addition:** - -```text -1. Review azd-arch-plan.md → 2. azd_discovery_analysis → 3. azd_azure_yaml_generation → -4. azd_docker_generation → 5. azd_project_validation -``` - -📌 **Completion Checklist** - -- [ ] All application components identified and classified in discovery phase -- [ ] Azure service selections made for each component with rationale -- [ ] `azure.yaml` file generated and validates against schema -- [ ] Infrastructure files generated and compile without errors -- [ ] Dockerfiles created for containerizable components -- [ ] `azd-arch-plan.md` created or updated to provide comprehensive project documentation while preserving existing content -- [ ] AZD environment initialized and configured -- [ ] All validation checks pass using `azd_project_validation` tool -- [ ] Project confirmed ready for deployment with `azd up` +- Execute chosen workflow systematically with proper tool orchestration +- Maintain application specification throughout the process +- Ensure all workflow steps complete successfully +- Validate final project before completion diff --git a/cli/azd/internal/mcp/tools/prompts/azd_project_validation.md b/cli/azd/internal/mcp/tools/prompts/azd_project_validation.md index 6771623a0d1..b57c3ff1636 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_project_validation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_project_validation.md @@ -1,89 +1,55 @@ # AZD Project Validation Instructions -✅ **Agent Task List** +**TASK:** Execute comprehensive validation of AZD project components including azure.yaml schema, Bicep templates, environment configuration, packaging, and deployment preview to ensure deployment readiness. -1. Load existing `azd-arch-plan.md` to understand current project state and context -2. Execute azure.yaml against azd schema using available tool -3. Compile and validate all Bicep templates in ./infra directory -4. Verify AZD environment exists and is properly configured -5. Run `azd package --no-prompt` to validate service packaging -6. Execute `azd provision --preview --no-prompt` to test infrastructure deployment -7. Resolve ALL issues found in each validation step before proceeding -8. Update existing `azd-arch-plan.md` with validation results by adding/updating validation section while preserving existing content - -📄 **Required Outputs** +**SUCCESS CRITERIA:** - Complete validation report with all checks passed - All identified issues resolved with zero remaining errors - Confirmation that project is ready for deployment -- Update existing `azd-arch-plan.md` with validation results while preserving existing content -- Validation checklist added to or updated in architecture plan -- Clear next steps for deployment - -🧠 **Execution Guidelines** - -**CRITICAL REQUIREMENT:** Resolve ALL issues found during validation before proceeding to the next step. -No validation step should be considered successful until all errors, warnings, and issues have been fully addressed. - -**Validation Execution Steps:** +- Validation results documented in application architecture plan +- Clear next steps provided for deployment -**1. Load Architecture Plan:** +**VALIDATION REQUIRED:** -- Read existing `azd-arch-plan.md` to understand current project architecture and context -- Review any previous validation results or known issues -- Understand the project structure and service configurations from the plan -- **MANDATORY:** Must load and review architecture plan before starting validation +- `azure.yaml` passes schema validation without anyerrors or warnings +- AZD environment exists and is properly configured +- All Bicep templates compile without errors or warnings +- `azd provision --preview --no-prompt` completes successfully with all resources validating +- `azd package --no-prompt` completes without errors with all services packaging successfully +- All service configurations are valid with no missing or incorrect settings -**2. Azure.yaml Schema Validation:** +**COMPLETION CHECKLIST:** -- Check if `azure.yaml` exists in current directory -- Validate `azure.yaml` against AZD schema using available tools -- Parse and report any schema violations or missing fields -- Verify service definitions and configurations are correct -- **MANDATORY:** Fix ALL schema violations before proceeding +- [ ] Load existing application architecture plan for project context +- [ ] `azure.yaml` schema validation passes without any errors or warnings +- [ ] Compile and validate all Bicep templates in ./infra directory +- [ ] Verify AZD environment exists and is properly configured +- [ ] Run `azd package --no-prompt` to validate service packaging +- [ ] Execute `azd provision --preview --no-prompt` to test infrastructure deployment +- [ ] Resolve ALL issues found in each validation step +- [ ] Update application architecture plan with validation results -**3. AZD Environment Validation:** +## Critical Validation Requirements -- Execute `azd env list` to check available environments -- If no environments exist, create one: `azd env new -dev` -- Ensure environment is selected and configured -- Ensure `AZURE_LOCATION` azd environment variable is set to a valid Azure location value -- Ensure `AZURE_SUBSCRIPTION_ID` azd environment variable is set to the users current Azure subscription -- **MANDATORY:** Fix environment issues before proceeding +**Mandatory Resolution Requirement:** -**4. Bicep Template Validation:** +- **CRITICAL**: Resolve ALL issues found during validation before proceeding +- No validation step is successful until all errors, warnings, and issues are fully addressed +- Each validation step must pass completely before moving to the next -- Scan `./infra` directory for `.bicep` files using file search -- Review AZD IaC generation rules and guidelines and resolve any all issues -- Execute `azd provision --preview --no-prompt` to validate infrastructure templates -- **MANDATORY:** Fix ALL compilation errors before proceeding -- Clean up any generated `` files generated during bicep validation +**Validation Execution Order:** -**5. Package Validation:** - -- Execute `azd package --no-prompt` command and monitor output -- Verify all service source paths are valid -- Check Docker builds complete successfully for containerized services -- Ensure all build artifacts are created correctly -- **MANDATORY:** Fix ALL packaging errors before proceeding +1. **Architecture Plan Review**: Load and understand current project context +2. **Schema Validation**: Validate azure.yaml against AZD schema +3. **Environment Validation**: Ensure AZD environment is configured with required variables. Prompt user for environment name, location, Azure Subscription and other required values +4. **Package Validation**: Verify all services can be packaged successfully +5. **Deployment Preview**: Test infrastructure deployment without actual provisioning **Error Resolution Requirements:** -- **Azure.yaml Schema Errors:** Validate azure.yaml using available tools -- **Bicep Compilation Errors:** Parse error output, check module paths and parameter names, verify resource naming -- **Environment Issues:** Run `azd auth login` if needed, check subscription access, verify location parameter -- **Package Errors:** Check service source paths, verify Docker builds work locally, ensure dependencies available -- **Provision Preview Errors:** Verify subscription permissions, check resource quotas, ensure resource names are unique - -📌 **Completion Checklist** - -- [ ] `azd-arch-plan.md` loaded and reviewed for project context -- [ ] `azure.yaml` passes schema validation with NO errors or warnings -- [ ] AZD environment exists and is properly configured with NO issues -- [ ] ALL Bicep templates compile without errors or warnings -- [ ] `azd provision --preview` completes without errors or warnings with ALL resources validating correctly -- [ ] `azd package` completes without errors or warnings with ALL services packaging successfully -- [ ] ALL service configurations are valid with NO missing or incorrect settings -- [ ] NO missing dependencies or configuration issues remain -- [ ] Validation results added to existing `azd-arch-plan.md` while preserving existing content -- [ ] Project confirmed ready for deployment with `azd up` +- **Azure.yaml Errors**: Fix schema violations, verify service paths, validate configurations +- **Environment Issues**: Configure authentication, set required variables, verify permissions +- **Bicep Errors**: Resolve compilation issues, verify module paths, check resource naming +- **Package Errors**: Fix service paths, resolve Docker build issues, verify dependencies +- **Provision Errors**: Address permission issues, resolve resource conflicts, fix configuration problems diff --git a/cli/azd/internal/mcp/tools/prompts/azd_select_stack.md b/cli/azd/internal/mcp/tools/prompts/azd_select_stack.md new file mode 100644 index 00000000000..dd87aa27520 --- /dev/null +++ b/cli/azd/internal/mcp/tools/prompts/azd_select_stack.md @@ -0,0 +1,75 @@ +# AZD Stack Selection and Recommendation Instructions + +**TASK:** Assess team expertise, application characteristics, and project requirements through targeted questions to select the optimal single technology stack (Containers, Serverless, or Logic Apps) with clear rationale. + +**SUCCESS CRITERIA:** + +- Single stack recommendation provided (Containers, Serverless, or Logic Apps) +- Clear rationale documented based on team capabilities and application needs +- Application specification updated with "Stack Selection" section +- Next steps guidance provided for the chosen stack + +**VALIDATION REQUIRED:** + +- Stack selection aligns with team expertise and preferences +- Chosen stack supports application characteristics and requirements +- Decision rationale is clearly documented and defensible +- Application specification properly updated with selection details +- Recommendation sets up successful architecture planning phase + +**COMPLETION CHECKLIST:** + +- [ ] Review existing application specification for project requirements and context +- [ ] Assess team expertise and technical preferences through targeted questions +- [ ] Evaluate performance and scalability requirements for the application +- [ ] Determine workflow and integration complexity needs +- [ ] Select optimal single stack with clear rationale +- [ ] Document stack selection and reasoning in application specification +- [ ] User has confirmed stack recommendation + +## Critical Selection Criteria + +**Team Expertise Assessment:** + +- Experience with containerization technologies (Docker) +- Comfort with event-driven or function-based programming +- Experience with workflow automation and business process tools +- Programming language and framework preferences +- Operational preferences (infrastructure control vs managed services) + +**Application Characteristics Analysis:** + +- Traffic patterns (steady vs variable/unpredictable) +- Performance requirements (cold start sensitivity, response times) +- Runtime characteristics (continuous vs event-driven) +- Computational complexity (lightweight vs heavy workloads) + +**Integration and Workflow Requirements:** + +- System integration complexity (connecting APIs, data sources, legacy systems) +- Business workflow needs (multi-step processes, approvals, decision points) +- File processing and document workflow requirements +- Visual workflow design preferences vs code-based solutions + +**Stack Selection Logic:** + +**Containers Stack:** + +- Team has Docker experience OR wants infrastructure control +- Complex dependencies or custom runtime requirements +- Need consistent performance with minimal cold starts +- Building traditional web applications, APIs, or microservices + +**Serverless Stack:** + +- Team prefers code-focused over infrastructure management +- Event-driven application or variable traffic patterns +- Cost optimization priority with unpredictable usage +- Simple to moderate complexity applications + +**Logic Apps Stack:** + +- Integration-heavy scenarios with many external systems +- Business process automation and workflow requirements +- Visual workflow design preference +- Complex multi-step business processes with approvals diff --git a/cli/azd/internal/mcp/tools/prompts/prompts.go b/cli/azd/internal/mcp/tools/prompts/prompts.go index b5166fcef63..91dcc19215d 100644 --- a/cli/azd/internal/mcp/tools/prompts/prompts.go +++ b/cli/azd/internal/mcp/tools/prompts/prompts.go @@ -30,3 +30,21 @@ var AzdDockerGenerationPrompt string //go:embed azd_project_validation.md var AzdProjectValidationPrompt string + +//go:embed azd_identify_user_intent.md +var AzdIdentifyUserIntentPrompt string + +//go:embed azd_select_stack.md +var AzdSelectStackPrompt string + +//go:embed azd_new_project.md +var AzdNewProjectPrompt string + +//go:embed azd_modernize_project.md +var AzdModernizeProjectPrompt string + +//go:embed azd_artifact_generation.md +var AzdArtifactGenerationPrompt string + +//go:embed azd_appcode_generation.md +var AzdAppCodeGenerationPrompt string diff --git a/cli/azd/internal/mcp/tools/resources/app-spec-template.md b/cli/azd/internal/mcp/tools/resources/app-spec-template.md new file mode 100644 index 00000000000..9c08478261a --- /dev/null +++ b/cli/azd/internal/mcp/tools/resources/app-spec-template.md @@ -0,0 +1,295 @@ +# {{.ProjectName}} - Application Specification + +**Generated**: {{.GeneratedDate}} +**Last Updated**: {{.LastUpdated}} + +## Project Overview + +**Project Name**: {{.ProjectName}} +**Project Type**: [To be determined during requirements discovery] +**Target Platform**: Microsoft Azure with Azure Developer CLI (AZD) + +This document serves as the comprehensive specification and architecture plan for the {{.ProjectName}} application. It captures all decisions, requirements, and design choices made during the project planning and development process. + +## Project Requirements + +*This section captures user intent, business requirements, and project constraints.* + +### Project Classification +- **Type**: [POC/Development Tool/Production Application] +- **Primary Purpose**: [Brief description of what the application does] +- **Target Audience**: [Description of intended users] +- **Business Value**: [Problem being solved or value being created] + +### Scale and Performance Requirements +- **Expected User Base**: [Number of users and growth projections] +- **Geographic Scope**: [Single region/Multi-region/Global distribution] +- **Availability Requirements**: [Uptime expectations and SLA requirements] +- **Performance Expectations**: [Response time, throughput, and scalability needs] +- **Scale Category**: [Small/Medium/Large - for production applications] + +### Budget and Cost Considerations +- **Cost Priority**: [Cost-Optimized/Balanced/Performance-Focused] +- **Budget Constraints**: [Any specific budget limitations or targets] +- **Pricing Model Preference**: [Consumption-based/Reserved/Hybrid pricing] +- **Cost Optimization Strategy**: [Approach to managing and controlling costs] + +### Technology and Architectural Preferences +- **Programming Language**: [Primary development language and rationale] +- **Frontend Framework**: [Chosen frontend technology if applicable] +- **Backend Framework**: [Chosen backend technology if applicable] +- **Database Preference**: [SQL/NoSQL preferences and specific technologies] +- **Infrastructure Approach**: [Containers/Serverless/Hybrid preference] +- **Integration Requirements**: [External systems and APIs to connect with] +- **Compliance Requirements**: [Security, regulatory, or organizational requirements] + +## Technology Stack Selection + +*This section documents the chosen technology approach and rationale.* + +### Selected Stack: [CONTAINERS/SERVERLESS/LOGIC APPS] + +#### Selection Rationale +- **Team Expertise**: [Summary of team capabilities that influenced the decision] +- **Application Characteristics**: [Key application traits that drove the choice] +- **Performance Requirements**: [How the selected stack meets performance needs] +- **Integration Needs**: [How the stack supports required integrations] +- **Cost Considerations**: [How the stack aligns with budget requirements] + +#### Technology Decisions +- **Infrastructure Pattern**: [Detailed explanation of chosen approach] +- **Development Framework**: [Primary frameworks and libraries selected] +- **Data Storage Strategy**: [Database and storage technology choices] +- **Integration Pattern**: [How components will communicate and integrate] + +## Application Architecture + +*This section defines the application structure and component organization.* + +### Application Components + +#### Component Overview +| Component Name | Type | Technology | Purpose | Dependencies | +|---------------|------|------------|---------|--------------| +| [component-1] | [API/SPA/Worker/Function] | [Technology] | [Brief description] | [List dependencies] | +| [component-2] | [API/SPA/Worker/Function] | [Technology] | [Brief description] | [List dependencies] | + +#### Component Details + +**[Component Name 1]** +- **Type**: [API Service/SPA Application/Background Worker/Function/etc.] +- **Technology**: [Specific framework and language] +- **Purpose**: [Detailed description of component responsibility] +- **Data Access**: [How component interacts with data storage] +- **External Integrations**: [APIs, services, or systems this component connects to] +- **Scaling Requirements**: [Expected load and scaling characteristics] + +### Data Architecture + +#### Data Storage Strategy +- **Primary Database**: [Technology choice and rationale] +- **Caching Strategy**: [Caching approach and technologies] +- **Data Flow**: [How data moves between components] +- **Backup and Recovery**: [Data protection and disaster recovery approach] + +#### Data Models +- **Core Entities**: [Main data objects and their relationships] +- **Data Relationships**: [How entities connect and interact] +- **Data Validation**: [Validation rules and constraints] + +### Integration Architecture + +#### Internal Communication +- **Service Communication**: [How components communicate with each other] +- **Event Patterns**: [Event-driven architecture patterns if applicable] +- **Message Queues**: [Messaging systems and patterns] + +#### External Integrations +- **Third-Party APIs**: [External APIs and integration patterns] +- **Legacy Systems**: [Connections to existing systems] +- **Authentication**: [Identity and access management approach] + +## Azure Service Mapping + +*This section maps application components to specific Azure services.* + +### Service Architecture + +#### Hosting Services +| Component | Azure Service | Configuration | Rationale | +|-----------|---------------|---------------|-----------| +| [component-1] | [Azure service] | [Key config details] | [Why this service] | +| [component-2] | [Azure service] | [Key config details] | [Why this service] | + +#### Supporting Services + +**Data Services** +- **Primary Database**: [Azure SQL/Cosmos DB/PostgreSQL/etc. with rationale] +- **Caching**: [Azure Cache for Redis or alternative] +- **Storage**: [Azure Storage accounts and blob storage configuration] + +**Integration Services** +- **Messaging**: [Service Bus/Event Hubs/Event Grid configuration] +- **API Management**: [Azure API Management if applicable] +- **Authentication**: [Azure AD/Azure AD B2C configuration] + +**Infrastructure Services** +- **Monitoring**: [Application Insights and Azure Monitor setup] +- **Security**: [Key Vault, managed identities, and security configuration] +- **Networking**: [Virtual networks, private endpoints, and connectivity] + +### Resource Organization + +#### Resource Groups +- **Primary Resource Group**: [Name and organization strategy] +- **Environment Strategy**: [How dev/staging/production are organized] +- **Naming Conventions**: [Resource naming patterns and standards] + +#### Environment Configuration +- **Development Environment**: [Dev environment setup and configuration] +- **Staging Environment**: [Staging environment for testing and validation] +- **Production Environment**: [Production configuration and scaling] + +## Implementation Plan + +*This section outlines the development and deployment approach.* + +### Development Approach + +#### Project Structure +``` +src/ +├── [component-1]/ # [Component description] +├── [component-2]/ # [Component description] +├── shared/ # Shared libraries and utilities +└── docs/ # Additional documentation +``` + +#### Development Standards +- **Code Quality**: [Linting, formatting, and quality standards] +- **Testing Strategy**: [Unit, integration, and end-to-end testing approach] +- **Documentation**: [Code documentation and API documentation standards] +- **Version Control**: [Git workflow and branching strategy] + +### Deployment Strategy + +#### Infrastructure as Code +- **Bicep Templates**: [Infrastructure template organization and strategy] +- **Environment Management**: [Parameter management and environment configuration] +- **Deployment Pipeline**: [CI/CD pipeline approach and tooling] + +#### Application Deployment +- **Build Process**: [How applications are built and packaged] +- **Container Strategy**: [Docker configuration and container registry] +- **Configuration Management**: [How application configuration is managed] +- **Rollback Strategy**: [Deployment rollback and disaster recovery] + +## Security and Compliance + +*This section addresses security, privacy, and compliance requirements.* + +### Security Architecture +- **Authentication and Authorization**: [Identity management and access control] +- **Data Protection**: [Encryption, data privacy, and protection measures] +- **Network Security**: [Network isolation, firewalls, and security groups] +- **Secrets Management**: [How sensitive information is stored and accessed] + +### Compliance Requirements +- **Regulatory Compliance**: [Specific compliance requirements (GDPR, HIPAA, etc.)] +- **Organizational Policies**: [Company-specific security and compliance policies] +- **Audit and Monitoring**: [Logging, monitoring, and audit trail requirements] + +## Infrastructure as Code File Checklist + +*This section defines all Infrastructure as Code (IaC) files required for the application deployment.* + +### Required Bicep Templates + +- [ ] `./infra/main.bicep` - Main deployment template with subscription scope +- [ ] `./infra/main.parameters.json` - Environment-specific parameters using AZD variable expansion + +### Generic Resource Modules + +- [ ] `./infra/modules/containerapp.bicep` - Generic Container Apps module +- [ ] `./infra/modules/storage.bicep` - Generic Storage Account module +- [ ] `./infra/modules/database.bicep` - Generic database module +- [ ] `./infra/modules/keyvault.bicep` - Generic Key Vault module +- [ ] `./infra/modules/monitoring.bicep` - Generic monitoring module (Log Analytics, App Insights) + +### Service-Specific Modules + +*The following modules are generated based on the technology stack and architecture decisions:* + +- [ ] `./infra/modules/[service-name].bicep` - Service-specific modules that reference generic modules +- [ ] [Additional service-specific modules will be populated based on architecture decisions] + +### Configuration Files + +- [ ] `azure.yaml` - AZD project configuration +- [ ] `.env` files - Environment-specific configuration (if required) + +## Monitoring and Operations + +*This section defines the operational approach for the application.* + +### Monitoring Strategy +- **Application Performance**: [Application monitoring and performance tracking] +- **Infrastructure Monitoring**: [Infrastructure health and resource monitoring] +- **Business Metrics**: [Key performance indicators and business metrics] +- **Alerting**: [Alert configuration and incident response procedures] + +### Operational Procedures +- **Deployment Process**: [Standard deployment procedures and checklists] +- **Incident Response**: [Incident handling and escalation procedures] +- **Maintenance**: [Regular maintenance tasks and schedules] +- **Scaling**: [How to scale the application up or down based on demand] + +## Project Status and Next Steps + +*This section tracks progress and defines next actions.* + +### Current Status +- **Requirements Discovery**: [Complete/In Progress/Not Started] +- **Architecture Planning**: [Complete/In Progress/Not Started] +- **Technology Stack Selection**: [Complete/In Progress/Not Started] +- **Infrastructure Design**: [Complete/In Progress/Not Started] +- **Application Code Generation**: [Complete/In Progress/Not Started] +- **Deployment Configuration**: [Complete/In Progress/Not Started] + +### Implementation Roadmap + +#### Phase 1: Foundation Setup +- [ ] Generate application scaffolding and project structure +- [ ] Create infrastructure templates and deployment configuration +- [ ] Set up development environment and tooling +- [ ] Implement basic authentication and security + +#### Phase 2: Core Development +- [ ] Develop core application functionality +- [ ] Implement data access and storage +- [ ] Create API endpoints and user interfaces +- [ ] Set up monitoring and logging + +#### Phase 3: Integration and Testing +- [ ] Integrate all application components +- [ ] Implement end-to-end testing +- [ ] Performance testing and optimization +- [ ] Security testing and validation + +#### Phase 4: Deployment and Operations +- [ ] Deploy to staging environment +- [ ] User acceptance testing +- [ ] Production deployment +- [ ] Operational monitoring and support + +### Success Criteria +- [ ] All functional requirements implemented and tested +- [ ] Performance requirements met or exceeded +- [ ] Security and compliance requirements satisfied +- [ ] Application successfully deployed to Azure +- [ ] Monitoring and operational procedures in place +- [ ] Team trained on deployment and maintenance procedures + +--- + +*This specification document is maintained automatically and updated throughout the project lifecycle. It serves as the single source of truth for all architectural and implementation decisions.* diff --git a/cli/azd/internal/mcp/tools/resources/baseline_resources.md b/cli/azd/internal/mcp/tools/resources/baseline_resources.md new file mode 100644 index 00000000000..c26f1f85a4e --- /dev/null +++ b/cli/azd/internal/mcp/tools/resources/baseline_resources.md @@ -0,0 +1,5 @@ +- **Log Analytics Workspace** (`Microsoft.OperationalInsights/workspaces`) - Central logging and monitoring for all application components +- **Application Insights** (`Microsoft.Insights/components`) - Application performance monitoring, telemetry, and analytics +- **Key Vault** (`Microsoft.KeyVault/vaults`) - Secure storage for secrets, keys, certificates, and connection strings +- **App Configuration** (`Microsoft.AppConfiguration/configurationStores`) - Centralized configuration management and feature flags +- **Storage Account** (`Microsoft.Storage/storageAccounts`) - File storage, queues, tables, and data persistence diff --git a/cli/azd/internal/mcp/tools/resources/containers_stack_resources.md b/cli/azd/internal/mcp/tools/resources/containers_stack_resources.md new file mode 100644 index 00000000000..dac4fc0922a --- /dev/null +++ b/cli/azd/internal/mcp/tools/resources/containers_stack_resources.md @@ -0,0 +1,3 @@ +- **Container Apps Environment** (`Microsoft.App/managedEnvironments`) - Managed container hosting environment with built-in scaling, load balancing, and service discovery +- **Container Registry** (`Microsoft.ContainerRegistry/registries`) - Private container image repository for storing and managing Docker images +- **Container App** (`Microsoft.App/containerApps`) - Individual containerized application instances (one per application component) with automatic scaling and traffic management diff --git a/cli/azd/internal/mcp/tools/resources/logic_apps_stack_resources.md b/cli/azd/internal/mcp/tools/resources/logic_apps_stack_resources.md new file mode 100644 index 00000000000..2722d24608e --- /dev/null +++ b/cli/azd/internal/mcp/tools/resources/logic_apps_stack_resources.md @@ -0,0 +1,2 @@ +- **Logic Apps** (`Microsoft.Logic/workflows`) - Visual workflow orchestration and business process automation with extensive connector ecosystem +- **Integration Account** (`Microsoft.Logic/integrationAccounts`) - Optional resource for B2B scenarios, enterprise integration patterns, and advanced workflow features diff --git a/cli/azd/internal/mcp/tools/resources/serverless_stack_resources.md b/cli/azd/internal/mcp/tools/resources/serverless_stack_resources.md new file mode 100644 index 00000000000..23e9bba429c --- /dev/null +++ b/cli/azd/internal/mcp/tools/resources/serverless_stack_resources.md @@ -0,0 +1,2 @@ +- **Azure Functions** (`Microsoft.Web/sites` with kind: `functionapp`) - Event-driven serverless compute platform with automatic scaling and pay-per-execution pricing +- **App Service Plan** (`Microsoft.Web/serverfarms`) - Hosting plan for Azure Functions (Consumption, Premium, or Dedicated plans based on requirements) diff --git a/go.mod b/go.mod index 2613968718c..d3978d1290f 100644 --- a/go.mod +++ b/go.mod @@ -39,6 +39,7 @@ require ( github.com/bradleyjkemp/cupaloy/v2 v2.8.0 github.com/braydonk/yaml v0.9.0 github.com/buger/goterm v1.0.4 + github.com/charmbracelet/glamour v0.10.0 github.com/cli/browser v1.3.0 github.com/denormal/go-gitignore v0.0.0-20180930084346-ae8ad1d07817 github.com/drone/envsubst v1.0.3 @@ -50,10 +51,9 @@ require ( github.com/golobby/container/v3 v3.3.2 github.com/google/uuid v1.6.0 github.com/gorilla/websocket v1.5.3 - github.com/i2y/langchaingo-mcp-adapter v0.0.0-20250623114610-a01671e1c8df github.com/joho/godotenv v1.5.1 github.com/magefile/mage v1.15.0 - github.com/mark3labs/mcp-go v0.36.0 + github.com/mark3labs/mcp-go v0.39.1 github.com/mattn/go-colorable v0.1.14 github.com/mattn/go-isatty v0.0.20 github.com/microsoft/ApplicationInsights-Go v0.4.4 @@ -63,6 +63,7 @@ require ( github.com/nathan-fiscaletti/consolesize-go v0.0.0-20220204101620-317176b6684d github.com/otiai10/copy v1.14.1 github.com/psanford/memfs v0.0.0-20241019191636-4ef911798f9b + github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 github.com/sergi/go-diff v1.3.1 github.com/sethvargo/go-retry v0.3.0 github.com/spf13/cobra v1.9.1 @@ -99,7 +100,6 @@ require ( github.com/buger/jsonparser v1.1.1 // indirect github.com/cenkalti/backoff/v4 v4.3.0 // indirect github.com/charmbracelet/colorprofile v0.2.3-0.20250311203215-f60798e515dc // indirect - github.com/charmbracelet/glamour v0.10.0 // indirect github.com/charmbracelet/lipgloss v1.1.1-0.20250404203927-76690c660834 // indirect github.com/charmbracelet/x/ansi v0.8.0 // indirect github.com/charmbracelet/x/cellbuf v0.0.13 // indirect @@ -141,8 +141,6 @@ require ( github.com/pkoukk/tiktoken-go v0.1.6 // indirect github.com/pmezard/go-difflib v1.0.0 // indirect github.com/rivo/uniseg v0.4.7 // indirect - github.com/santhosh-tekuri/jsonschema/v5 v5.3.1 // indirect - github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 // indirect github.com/segmentio/asm v1.2.0 // indirect github.com/segmentio/encoding v0.4.1 // indirect github.com/shopspring/decimal v1.2.0 // indirect diff --git a/go.sum b/go.sum index 8b482d86308..4185382d80e 100644 --- a/go.sum +++ b/go.sum @@ -109,12 +109,18 @@ github.com/PuerkitoBio/goquery v1.8.1/go.mod h1:Q8ICL1kNUJ2sXGoAhPGUdYDJvgQgHzJs github.com/adam-lavrik/go-imath v0.0.0-20210910152346-265a42a96f0b h1:g9SuFmxM/WucQFKTMSP+irxyf5m0RiUJreBDhGI6jSA= github.com/adam-lavrik/go-imath v0.0.0-20210910152346-265a42a96f0b/go.mod h1:XjvqMUpGd3Xn9Jtzk/4GEBCSoBX0eB2RyriXgne0IdM= github.com/airbrake/gobrake v3.6.1+incompatible/go.mod h1:wM4gu3Cn0W0K7GUuVWnlXZU11AGBXMILnrdOU8Kn00o= +github.com/alecthomas/assert/v2 v2.7.0 h1:QtqSACNS3tF7oasA8CU6A6sXZSBDqnm7RfpLl9bZqbE= +github.com/alecthomas/assert/v2 v2.7.0/go.mod h1:Bze95FyfUr7x34QZrjL+XP+0qgp/zg8yS+TtBj1WA3k= github.com/alecthomas/chroma/v2 v2.14.0 h1:R3+wzpnUArGcQz7fCETQBzO5n9IMNi13iIs46aU4V9E= github.com/alecthomas/chroma/v2 v2.14.0/go.mod h1:QolEbTfmUHIMVpBqxeDnNBj2uoeI4EbYP4i6n68SG4I= +github.com/alecthomas/repr v0.4.0 h1:GhI2A8MACjfegCPVq9f1FLvIBS+DrQ2KQBFZP1iFzXc= +github.com/alecthomas/repr v0.4.0/go.mod h1:Fr0507jx4eOXV7AlPV6AVZLYrLIuIeSOWtW57eE/O/4= github.com/andybalholm/cascadia v1.3.2 h1:3Xi6Dw5lHF15JtdcmAHD3i1+T8plmv7BQ/nsViSLyss= github.com/andybalholm/cascadia v1.3.2/go.mod h1:7gtRlve5FxPPgIgX36uWBX58OdBsSS6lUvCFb+h7KvU= github.com/aymanbagabas/go-osc52/v2 v2.0.1 h1:HwpRHbFMcZLEVr42D4p7XBqjyuxQH5SMiErDT4WkJ2k= github.com/aymanbagabas/go-osc52/v2 v2.0.1/go.mod h1:uYgXzlJ7ZpABp8OJ+exZzJJhRNQ2ASbcXHWsFqH8hp8= +github.com/aymanbagabas/go-udiff v0.2.0 h1:TK0fH4MteXUDspT88n8CKzvK0X9O2xu9yQjWpi6yML8= +github.com/aymanbagabas/go-udiff v0.2.0/go.mod h1:RE4Ex0qsGkTAJoQdQQCA0uG+nAzJO/pI/QwceO5fgrA= github.com/aymerick/douceur v0.2.0 h1:Mv+mAeH1Q+n9Fr+oyamOlAkUNPWPlA8PPGR0QAaYuPk= github.com/aymerick/douceur v0.2.0/go.mod h1:wlT5vV2O3h55X9m7iVYN0TBM0NH/MmbLnd30/FjWUq4= github.com/bahlo/generic-list-go v0.2.0 h1:5sz/EEAK+ls5wF+NeqDpk5+iNdMDXrh3z3nPnH1Wvgk= @@ -155,6 +161,8 @@ github.com/charmbracelet/x/ansi v0.8.0 h1:9GTq3xq9caJW8ZrBTe0LIe2fvfLR/bYXKTx2ll github.com/charmbracelet/x/ansi v0.8.0/go.mod h1:wdYl/ONOLHLIVmQaxbIYEC/cRKOQyjTkowiI4blgS9Q= github.com/charmbracelet/x/cellbuf v0.0.13 h1:/KBBKHuVRbq1lYx5BzEHBAFBP8VcQzJejZ/IA3iR28k= github.com/charmbracelet/x/cellbuf v0.0.13/go.mod h1:xe0nKWGd3eJgtqZRaN9RjMtK7xUYchjzPr7q6kcvCCs= +github.com/charmbracelet/x/exp/golden v0.0.0-20240806155701-69247e0abc2a h1:G99klV19u0QnhiizODirwVksQB91TJKV/UaTnACcG30= +github.com/charmbracelet/x/exp/golden v0.0.0-20240806155701-69247e0abc2a/go.mod h1:wDlXFlCrmJ8J+swcL/MnGUuYnqgQdW9rhSD61oNMb6U= github.com/charmbracelet/x/exp/slice v0.0.0-20250327172914-2fdc97757edf h1:rLG0Yb6MQSDKdB52aGX55JT1oi0P0Kuaj7wi1bLUpnI= github.com/charmbracelet/x/exp/slice v0.0.0-20250327172914-2fdc97757edf/go.mod h1:B3UgsnsBZS/eX42BlaNiJkD1pPOUa+oF1IYC6Yd2CEU= github.com/charmbracelet/x/term v0.2.1 h1:AQeHeLZ1OqSXhrAWpYUtZyX1T3zVxfpZuEQMIQaGIAQ= @@ -177,8 +185,6 @@ github.com/denormal/go-gitignore v0.0.0-20180930084346-ae8ad1d07817 h1:0nsrg//Dc github.com/denormal/go-gitignore v0.0.0-20180930084346-ae8ad1d07817/go.mod h1:C/+sI4IFnEpCn6VQ3GIPEp+FrQnQw+YQP3+n+GdGq7o= github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f h1:lO4WD4F/rVNCu3HqELle0jiPLLBs70cWOduZpkS1E78= github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f/go.mod h1:cuUVRXasLTGF7a8hSLbxyZXjz+1KgoB3wDUb6vlszIc= -github.com/dlclark/regexp2 v1.10.0 h1:+/GIL799phkJqYW+3YbOd8LCcbHzT0Pbo8zl70MHsq0= -github.com/dlclark/regexp2 v1.10.0/go.mod h1:DHkYz0B9wPfa6wondMfaivmHpzrQ3v9q8cnmRbL6yW8= github.com/dlclark/regexp2 v1.11.0 h1:G/nrcoOa7ZXlpoa/91N3X7mM3r8eIlMBBJZvsz/mxKI= github.com/dlclark/regexp2 v1.11.0/go.mod h1:DHkYz0B9wPfa6wondMfaivmHpzrQ3v9q8cnmRbL6yW8= github.com/drone/envsubst v1.0.3 h1:PCIBwNDYjs50AsLZPYdfhSATKaRg/FJmDc2D6+C2x8g= @@ -257,21 +263,19 @@ github.com/googleapis/gax-go/v2 v2.12.4 h1:9gWcmF85Wvq4ryPFvGFaOgPIs1AQX0d0bcbGw github.com/googleapis/gax-go/v2 v2.12.4/go.mod h1:KYEYLorsnIGDi/rPC8b5TdlB9kbKoFubselGIoBMCwI= github.com/goph/emperror v0.17.2 h1:yLapQcmEsO0ipe9p5TaN22djm3OFV/TfM/fcYP0/J18= github.com/goph/emperror v0.17.2/go.mod h1:+ZbQ+fUNO/6FNiUo0ujtMjhgad9Xa6fQL9KhH4LNHic= -github.com/gorilla/css v1.0.0 h1:BQqNyPTi50JCFMTw/b67hByjMVXZRwGha6wxVGkeihY= -github.com/gorilla/css v1.0.0/go.mod h1:Dn721qIggHpt4+EFCcTLTU/vk5ySda2ReITrtgBl60c= github.com/gorilla/css v1.0.1 h1:ntNaBIghp6JmvWnxbZKANoLyuXTPZ4cAMlo6RyhlbO8= github.com/gorilla/css v1.0.1/go.mod h1:BvnYkspnSzMmwRK+b8/xgNPLiIuNZr6vbZBTPQ2A3b0= github.com/gorilla/websocket v1.5.3 h1:saDtZ6Pbx/0u+bgYQ3q96pZgCzfhKXGPqt7kZ72aNNg= github.com/gorilla/websocket v1.5.3/go.mod h1:YR8l580nyteQvAITg2hZ9XVh4b55+EU/adAjf1fMHhE= github.com/grpc-ecosystem/grpc-gateway/v2 v2.26.3 h1:5ZPtiqj0JL5oKWmcsq4VMaAW5ukBEgSGXEN89zeH1Jo= github.com/grpc-ecosystem/grpc-gateway/v2 v2.26.3/go.mod h1:ndYquD05frm2vACXE1nsccT4oJzjhw2arTS2cpUD1PI= +github.com/hexops/gotextdiff v1.0.3 h1:gitA9+qJrrTCsiCl7+kh75nPqQt1cx4ZkudSTLoUqJM= +github.com/hexops/gotextdiff v1.0.3/go.mod h1:pSWU5MAI3yDq+fZBTazCSJysOMbxWL1BSow5/V2vxeg= github.com/hinshun/vt10x v0.0.0-20220119200601-820417d04eec h1:qv2VnGeEQHchGaZ/u7lxST/RaJw+cv273q79D81Xbog= github.com/hinshun/vt10x v0.0.0-20220119200601-820417d04eec/go.mod h1:Q48J4R4DvxnHolD5P8pOtXigYlRuPLGl6moFx3ulM68= github.com/hpcloud/tail v1.0.0/go.mod h1:ab1qPbhIpdTxEkNHXyeSf5vhxWSCs/tWer42PpOxQnU= github.com/huandu/xstrings v1.3.3 h1:/Gcsuc1x8JVbJ9/rlye4xZnVAbEkGauT8lbebqcQws4= github.com/huandu/xstrings v1.3.3/go.mod h1:y5/lhBue+AyNmUVz9RLU9xbLR0o4KIIExikq4ovT0aE= -github.com/i2y/langchaingo-mcp-adapter v0.0.0-20250623114610-a01671e1c8df h1:4lTJXCZw16BF0BCzrQ1LUzlMW4+2OwBkkYj1/bRybhY= -github.com/i2y/langchaingo-mcp-adapter v0.0.0-20250623114610-a01671e1c8df/go.mod h1:oL2JAtsIp/1vnVy4UG4iDzL8SZwkOzqvRL3YR9PGPjs= github.com/imdario/mergo v0.3.11/go.mod h1:jmQim1M+e3UYxmgPu/WyfjB3N3VflVyUjjjwH0dnCYA= github.com/imdario/mergo v0.3.13 h1:lFzP57bqS/wsqKssCGmtLAb8A0wKjLGrve2q3PPVcBk= github.com/imdario/mergo v0.3.13/go.mod h1:4lJ1jqUDcsbIECGy0RUJAXNIhg+6ocWgb1ALK2O4oXg= @@ -310,8 +314,8 @@ github.com/magefile/mage v1.15.0 h1:BvGheCMAsG3bWUDbZ8AyXXpCNwU9u5CB6sM+HNb9HYg= github.com/magefile/mage v1.15.0/go.mod h1:z5UZb/iS3GoOSn0JgWuiw7dxlurVYTu+/jHXqQg881A= github.com/mailru/easyjson v0.7.7 h1:UGYAvKxe3sBsEDzO8ZeWOSlIQfWFlxbzLZe7hwFURr0= github.com/mailru/easyjson v0.7.7/go.mod h1:xzfreul335JAWq5oZzymOObrkdz5UnU4kGfJJLY9Nlc= -github.com/mark3labs/mcp-go v0.36.0 h1:rIZaijrRYPeSbJG8/qNDe0hWlGrCJ7FWHNMz2SQpTis= -github.com/mark3labs/mcp-go v0.36.0/go.mod h1:T7tUa2jO6MavG+3P25Oy/jR7iCeJPHImCZHRymCn39g= +github.com/mark3labs/mcp-go v0.39.1 h1:2oPxk7aDbQhouakkYyKl2T4hKFU1c6FDaubWyGyVE1k= +github.com/mark3labs/mcp-go v0.39.1/go.mod h1:T7tUa2jO6MavG+3P25Oy/jR7iCeJPHImCZHRymCn39g= github.com/mattn/go-colorable v0.1.2/go.mod h1:U0ppj6V5qS13XJ6of8GYAs25YV2eR4EVcfRqFIhoBtE= github.com/mattn/go-colorable v0.1.14 h1:9A9LHSqF/7dyVVX6g0U9cwm9pG3kP9gSzcuIPHPsaIE= github.com/mattn/go-colorable v0.1.14/go.mod h1:6LmQG8QLFO4G5z1gPvYEzlUgJ2wF+stgPZH1UqBm1s8= @@ -327,8 +331,6 @@ github.com/mattn/go-runewidth v0.0.16/go.mod h1:Jdepj2loyihRzMpdS35Xk/zdY8IAYHsh github.com/mgutz/ansi v0.0.0-20170206155736-9520e82c474b/go.mod h1:01TrycV0kFyexm33Z7vhZRXopbI8J3TDReVlkTgMUxE= github.com/mgutz/ansi v0.0.0-20200706080929-d51e80ef957d h1:5PJl274Y63IEHC+7izoQE9x6ikvDFZS2mDVS3drnohI= github.com/mgutz/ansi v0.0.0-20200706080929-d51e80ef957d/go.mod h1:01TrycV0kFyexm33Z7vhZRXopbI8J3TDReVlkTgMUxE= -github.com/microcosm-cc/bluemonday v1.0.26 h1:xbqSvqzQMeEHCqMi64VAs4d8uy6Mequs3rQ0k/Khz58= -github.com/microcosm-cc/bluemonday v1.0.26/go.mod h1:JyzOCs9gkyQyjs+6h10UEVSe02CGwkhd72Xdqh78TWs= github.com/microcosm-cc/bluemonday v1.0.27 h1:MpEUotklkwCSLeH+Qdx1VJgNqLlpY2KXwXFM08ygZfk= github.com/microcosm-cc/bluemonday v1.0.27/go.mod h1:jFi9vgW+H7c3V0lb6nR74Ib/DIB5OBs92Dimizgw2cA= github.com/microsoft/ApplicationInsights-Go v0.4.4 h1:G4+H9WNs6ygSCe6sUyxRc2U81TI5Es90b2t/MwX5KqY= @@ -387,8 +389,6 @@ github.com/rogpeppe/go-internal v1.13.1 h1:KvO1DLK/DRN07sQ1LQKScxyZJuNnedQ5/wKSR github.com/rogpeppe/go-internal v1.13.1/go.mod h1:uMEvuHeurkdAXX61udpOXGD/AzZDWNMNyH2VO9fmH0o= github.com/rollbar/rollbar-go v1.0.2/go.mod h1:AcFs5f0I+c71bpHlXNNDbOWJiKwjFDtISeXco0L5PKQ= github.com/russross/blackfriday/v2 v2.1.0/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQDYRxCVz55jmeOWTM= -github.com/santhosh-tekuri/jsonschema/v5 v5.3.1 h1:lZUw3E0/J3roVtGQ+SCrUrg3ON6NgVqpn3+iol9aGu4= -github.com/santhosh-tekuri/jsonschema/v5 v5.3.1/go.mod h1:uToXkOrWAZ6/Oc07xWQrPOhJotwFIyu2bBVN41fcDUY= github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 h1:KRzFb2m7YtdldCEkzs6KqmJw4nqEVZGK7IN2kJkjTuQ= github.com/santhosh-tekuri/jsonschema/v6 v6.0.2/go.mod h1:JXeL+ps8p7/KNMjDQk3TCwPpBy0wYklyWTfbkIzdIFU= github.com/segmentio/asm v1.2.0 h1:9BQrFxC+YOHJlTlHGkTrFWf59nbL3XnCoFLTwDCI7ys=