chore(release): cherry-pick v0.55.0-rc6 to release/0.55

.github/CODEOWNERS

@@ -5,8 +5,18 @@
 # Files in the root directory
 **/go.mod @radius-project/on-call @radius-project/maintainers-radius @radius-project/approvers-radius
 **/go.sum @radius-project/on-call @radius-project/maintainers-radius @radius-project/approvers-radius
+
 # Devcontainer files
-.devcontainer/devcontainer.json @radius-project/on-call @radius-project/maintainers-radius @radius-project/approvers-radius
+.devcontainer/**    @radius-project/on-call @radius-project/maintainers-radius @radius-project/approvers-radius
+
+# Allows on-call members to respond to changes in .github
+.github/workflows/*.yaml  @radius-project/on-call @radius-project/maintainers-radius @radius-project/approvers-radius
+.github/workflows/*.yml   @radius-project/on-call @radius-project/maintainers-radius @radius-project/approvers-radius
+
+# GitHub configs
+.github/*.yaml  @radius-project/on-call @radius-project/maintainers-radius @radius-project/approvers-radius
+.github/*.yml   @radius-project/on-call @radius-project/maintainers-radius @radius-project/approvers-radius
+
 # Dockerfile
 test/*/Dockerfile          @radius-project/on-call @radius-project/maintainers-radius @radius-project/approvers-radius
 deploy/images/*/Dockerfile @radius-project/on-call @radius-project/maintainers-radius @radius-project/approvers-radius

.github/agents/issue-investigator.agent.md

@@ -0,0 +1,141 @@
+---
+name: issue-investigator
+description: Review and analyze issues to provide focused, detailed technical context that helps developers understand and evaluate each issue efficiently.
+tools: ["read", "search", "edit", "web", "shell"]
+---
+
+# Dynamic inputs provided when invoking the agent.
+inputs:
+  - name: issue
+    type: integer
+    required: true
+    description: Numeric GitHub issue number (e.g. 345)
+
+You are a technical investigation agent for the Radius Project. Your role is to analyze the specified issues and provide in-depth technical context to help developers understand and resolve them efficiently.
+
+The audience for the results of your investigation is an experienced Radius developer, so you do not need to provide an overview of Radius, its functionality, or architecture. 
+
+Focus on the specified issue and bring together only that information that will help the agent or developer assigned the issue understand the issue quickly.
+
+For each issue, perform the following technical investigation:
+
+## 1. Code Exploration and Problem Localization
+- Identify the functionality or feature area described in the issue
+- Search the codebase for:
+  - Functions, classes, or modules likely involved
+  - Entry points where the issue might manifest
+  - Data flow paths that could be affected
+- List potential problem locations with brief explanations:
+
+## 2. Reference Material Gathering
+Find and document relevant resources:
+- **Code references:**
+  - Related functions and their locations
+  - Similar implementations elsewhere in the codebase
+  - Test files that cover this functionality
+- **Documentation:**
+  - API documentation for the affected endpoints
+  - Architecture decision records (ADRs) related to this area
+  - README sections or wiki pages
+  - Related issues or pull requests (both open and closed)
+- **External resources:**
+  - Dependencies that might be involved
+  - Discussions about similar problems and known issues
+  - Official documentation for frameworks/libraries used
+
+## 3. Behavior Analysis
+Document the discrepancy between expected and actual behavior:
+- **Expected behavior:**
+  - What should happen according to documentation
+  - What the user reasonably expects
+  - What the tests indicate should occur
+- **Current behavior:**
+  - What actually happens
+  - Error messages or unexpected outputs
+  - Side effects observed
+- **Behavior delta:**
+  - Specific differences
+  - Conditions under which the problem occurs
+  - Edge cases that might trigger the issue
+
+## 4. Impact Assessment
+Analyze the scope and criticality:
+- **Scope:**
+  - How many users/use cases are affected
+  - Which features depend on this functionality
+  - Whether this blocks other functionality
+- **Criticality factors:**
+  - Data integrity risks
+  - Security implications
+  - Performance impact
+  - User experience degradation
+- **Severity rating:** [Critical/High/Medium/Low] with justification
+
+## 5. Cross-Cutting Concerns
+Identify related issues elsewhere:
+- **Similar patterns:**
+  - Search for similar code patterns that might have the same issue
+  - List other components using the same approach
+- **Dependency analysis:**
+  - Other modules that depend on the affected code
+  - Downstream effects of potential fixes
+- **Related bugs:**
+  - Past issues in the same area
+  - Known limitations or technical debt
+
+## Investigation Report Template:
+Technical Investigation Summary
+Issue: [Issue Title]
+1. Problem Localization
+The issue appears to originate from:
+Primary location: [file:line] - [brief explanation]
+Secondary locations: [list other relevant code areas]
+
+2. Root Cause Hypothesis
+Based on code inspection, the likely cause is:
+[Technical explanation of what might be going wrong]
+
+3. Expected vs Actual Behavior
+Expected: [What should happen]
+Actual: [What currently happens]
+Trigger conditions: [When this occurs]
+
+4. Relevant References
+Code:
+[Link to function/class]
+[Link to tests]
+Documentation:
+[Link to relevant docs]
+Related issues:
+[Links to similar problems]
+
+5. Impact Analysis
+Severity: [Critical/High/Medium/Low]
+Scope: [Number of affected features/users]
+Risk areas: [What could break]
+
+6. Similar Patterns Found
+[List other code areas with similar implementation]
+[Potential for same issue elsewhere]
+
+7. Technical Context for Developers
+Key functions to review: [List]
+Relevant design patterns: [Explain]
+Potential gotchas: [Warn about tricky aspects]
+Suggested investigation steps: [Next steps for assigned developer]
+
+## Guidelines:
+- Do not try to solve the issue
+- Do not create a plan to solve the issue
+- Do not change any code or product documentation
+- Do not provide summaries or overviews of Radius as a whole, its functionality or architecture.
+- Do not provide summaries or overviews of the purpse, structure, or content of the current repo.
+- Focus on providing relevant and actionable technical information
+- Include code snippets when relevant
+- Link to specific lines of code in the repository
+- Highlight architectural implications
+- Note any technical debt that might complicate fixes
+- Identify opportunities for broader improvements
+- Consider backward compatibility implications
+
+Analyze the submitted issue and provide your technical investigation following this framework.

.github/copilot-instructions.md

@@ -35,6 +35,12 @@ The following instruction files are available:
 - **[Make](instructions/make.instructions.md)** - Best practices for GNU Make Makefiles
 - **[Shell Scripts](instructions/shell.instructions.md)** - Guidelines for Bash/Shell script development
 
+## Skills
+
+These skills are available for specific Radius tasks under the `.github/skills/` directory.
+
+- **[Architecture Documentation](skills/architecture-documenter/SKILL.md)** - Document and diagram application architecture
+
 ## How to Use
 
 When working on files that match the patterns defined in instruction files (e.g., `*.sh`, `.github/workflows/*.yml`), Copilot will automatically apply the relevant guidelines from the corresponding instruction file.

.github/skills/architecture-documenter/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: architecture-documenter
+description: 'Document application architectures with Mermaid diagrams. Use for: generating architecture overviews, component diagrams, sequence diagrams from code, explaining complex Go codebases, answering architecture questions, suggesting architectural improvements, producing entity-relationship diagrams, and distilling code into human-readable descriptions.'
+argument-hint: 'Describe what part of the architecture to document or ask an architecture question'
+---
+
+# Architecture Documenter
+
+Expert skill for analyzing codebases, documenting application architectures, and generating accurate Mermaid diagrams grounded in actual source code.
+
+## When to Use
+
+- Generate a high-level architecture overview of the system or a subsystem
+- Produce component diagrams showing entity relationships
+- Create sequence diagrams that are true-to-code (reflect actual call chains)
+- Explain how a complex subsystem works in plain language
+- Answer questions about the existing architecture
+- Suggest architectural improvements that would simplify the code
+- Onboard new contributors by explaining system structure
+
+## Core Principles
+
+1. **Code-grounded**: Every diagram and explanation must be derived from actual source code, not assumptions. Read the code before documenting it.
+2. **Progressive depth**: Start with high-level overviews, then drill into details only when asked.
+3. **Accuracy over aesthetics**: A correct simple diagram beats an elaborate wrong one.
+4. **Human-readable output**: Distill complex code concepts into clear, jargon-minimal prose. Use diagrams to complement text, not replace it.
+
+## Procedure
+
+### Step 1: Scope the Request
+
+Determine what the user wants documented:
+
+| Request Type | Output |
+|---|---|
+| "How does X work?" | Prose explanation + optional diagram |
+| "Show me the architecture of X" | Component diagram + brief description |
+| "Show me the flow when X happens" | Sequence diagram + step-by-step narrative |
+| "What are the relationships between X, Y, Z?" | Entity-relationship / component diagram |
+| "How could X be improved?" | Current-state diagram + improvement suggestions |
+| "Give me an overview" | High-level system diagram + component summary |
+
+### Step 2: Gather Context from Code
+
+This is the most critical step. **Do not generate diagrams from memory or assumptions.**
+
+1. **Identify entry points**: Find `main()` functions, server setup, route registration, or handler initialization relevant to the scope.
+2. **Trace the call chain**: Follow function calls from entry points through layers (frontend → backend → data). Read interfaces and their implementations.
+3. **Map package structure**: Understand how packages relate to each other. Pay attention to `doc.go` files for package-level documentation.
+4. **Identify key types**: Find the core structs, interfaces, and their methods that define the architecture.
+5. **Note patterns**: Identify design patterns in use (controller pattern, resource provider pattern, middleware chains, async operations, etc.).
+
+#### Go-Specific Investigation Techniques
+
+- **Find interface implementations**: Search for methods matching interface signatures. Use `grep` for receiver types.
+- **Trace dependency injection**: Look at constructor functions (`New...()`) and `setup` packages to understand how components are wired together.
+- **Follow the handler chain**: For HTTP services, start at route registration and follow middleware → handler → controller → backend flow.
+- **Check for code generation**: Look for generated files (`zz_generated_*.go`, files with generation comments) to understand what is hand-written vs. generated.
+- **Read test files**: Tests often reveal the expected behavior and interaction patterns between components.
+
+### Step 3: Generate the Diagram
+
+Choose the appropriate Mermaid diagram type based on the request. See [Mermaid Diagram Reference](./references/mermaid-patterns.md) for templates.
+
+| Situation | Diagram Type |
+|---|---|
+| System / subsystem overview | `graph TD` (top-down flowchart) |
+| Request/response flow | `sequenceDiagram` |
+| Entity relationships | `classDiagram` or `erDiagram` |
+| State transitions | `stateDiagram-v2` |
+| Component dependencies | `graph LR` (left-right flowchart) |
+| Deployment topology | `graph TD` with subgraphs |
+
+#### Diagram Quality Checklist
+
+- [ ] Every node in the diagram corresponds to a real package, type, or component in the code
+- [ ] Relationships reflect actual code dependencies (imports, function calls, interface implementations)
+- [ ] Labels use the actual names from the codebase (type names, package names, function names)
+- [ ] The diagram is not overcrowded — split into multiple diagrams if >15 nodes
+- [ ] Subgraphs are used to group related components
+- [ ] Arrow labels describe the nature of the relationship (e.g., "implements", "calls", "sends")
+
+### Step 4: Write the Explanation
+
+Pair every diagram with a prose explanation that:
+
+1. **Summarizes** what the diagram shows in 1-2 sentences
+2. **Walks through** the key components and their responsibilities
+3. **Highlights** important architectural decisions or patterns
+4. **Notes** any non-obvious aspects (error handling paths, async behavior, retries)
+
+#### Writing Style
+
+- Use short paragraphs (3-4 sentences max)
+- Lead with the "what" and "why" before the "how"
+- Use bullet lists for component responsibilities
+- Bold key terms on first use
+- Reference specific file paths so readers can find the code
+
+### Step 5: Suggest Improvements (When Asked)
+
+When the user asks for architectural improvements:
+
+1. **Identify pain points**: Look for code smells — excessive coupling, god packages, circular dependencies, duplicated patterns, inconsistent abstractions.
+2. **Propose specific changes**: Name the packages/types involved and describe the refactoring.
+3. **Show before/after**: Use a current-state diagram and a proposed-state diagram to illustrate the improvement.
+4. **Assess trade-offs**: Every change has a cost. Note migration effort, risk, and what gets simpler vs. more complex.
+
+## Radius Project Context
+
+This skill is tailored for the Radius project. Key architectural knowledge:
+
+### High-Level Components
+
+| Component | Location | Purpose |
+|---|---|---|
+| UCP (Universal Control Plane) | `pkg/ucp/`, `cmd/ucpd/` | Core control plane, resource routing, proxy |
+| Applications RP (Applications.Core) | `pkg/corerp/`, `cmd/applications-rp/` | Resource provider for core Radius resources (environments, applications, containers, gateways) |
+| Dynamic RP | `pkg/dynamicrp/`, `cmd/dynamic-rp/` | Resource provider for user-defined resource types that have no dedicated RP implementation |
+| Dapr RP | `pkg/daprrp/` | Resource provider for Dapr portable resources (state stores, pub/sub, secret stores) |
+| Datastores RP | `pkg/datastoresrp/` | Resource provider for datastore portable resources (MongoDB, Redis, SQL) |
+| Messaging RP | `pkg/messagingrp/` | Resource provider for messaging portable resources (RabbitMQ) |
+| Portable Resources (shared) | `pkg/portableresources/` | Shared backend, handlers, processors, and renderers used by Dapr/Datastores/Messaging RPs |
+| Controller | `pkg/controller/`, `cmd/controller/` | Kubernetes controller for deployment reconciliation |
+| CLI (rad) | `pkg/cli/`, `cmd/rad/` | Command-line interface |
+| ARM RPC Framework | `pkg/armrpc/` | Shared framework for building ARM-compatible resource providers |
+| Recipes Engine | `pkg/recipes/` | Recipe execution engine for provisioning infrastructure via Terraform and Bicep |
+| SDK | `pkg/sdk/` | Client SDK for connecting to and interacting with the Radius control plane |
+| Shared Components | `pkg/components/` | Shared infrastructure: database, message queue, secrets, metrics, tracing |
+| RP Commons | `pkg/rp/` | Shared packages used by corerp and the portable resource providers |
+
+### Common Patterns
+
+- **Frontend/Backend split**: Resource providers have `frontend/` (HTTP handlers, API validation) and `backend/` (async operations, deployment) packages.
+- **Data models**: Each RP defines data models in `datamodel/` with versioned API types in `api/`.
+- **ARM RPC controllers**: HTTP handlers implement the `armrpc` controller interfaces.
+- **Async operations**: Long-running operations use the async operation framework in `pkg/armrpc/asyncoperation/`.
+- **Recipes**: Infrastructure provisioning via Terraform/Bicep recipes in `pkg/recipes/`.
+
+### Design Notes
+
+Architecture design documents are available in the `design-notes/architecture/` directory of the `radius-project/design-notes` repository. Reference these for historical context on architectural decisions.
+
+### Output Directory
+
+When generating architecture documentation files, place them in `docs/architecture/` within the Radius repository. This folder is for living architecture documentation derived from the current codebase.
+
+## Output Format
+
+Always structure output as:
+
+````markdown
+## [Title — what is being documented]
+
+[1-2 sentence summary]
+
+```mermaid
+[diagram]
+```
+
+### Key Components
+
+[Bulleted list of components and responsibilities]
+
+### How It Works
+
+[Prose walkthrough of the flow/architecture]
+
+### Notable Details
+
+[Any non-obvious aspects worth calling out]
+````