Update microsphere-spring-cloud and add GitHub prompt templates

.github/copilot-instructions.md

@@ -0,0 +1,24 @@
+# Copilot Instructions
+
+## Build and test commands
+
+- Build all modules: `./mvnw -DskipTests package`
+- Run the full test suite: `./mvnw test`
+- Run one test class from a leaf module: `./mvnw -pl microsphere-spring-cloud-gateway-server-webflux -am -Dtest=WebEndpointMappingGlobalFilterTest -Dsurefire.failIfNoSpecifiedTests=false test`
+- CI also exercises compatibility profiles with commands like `./mvnw -Drevision=0.0.1-SNAPSHOT test -Ptest,coverage,spring-cloud-2021` and the same profile set for `spring-cloud-hoxton` and `spring-cloud-2020`
+
+## High-level architecture
+
+- The root `pom.xml` is a Maven reactor. `microsphere-gateway-parent` imports the Microsphere Spring Cloud BOM, and `microsphere-gateway-dependencies` publishes the BOM that downstream applications import.
+- `microsphere-spring-cloud-gateway-commons` contains the shared gateway contract: property constants, conditional annotations, `WebEndpointConfig`, and `WebEndpointConfigurationPropertiesBindHandlerAdvisor`. That advisor injects typed `metadata.web-endpoint` config into bound `spring.cloud.gateway.routes[*]` definitions.
+- `microsphere-spring-cloud-gateway-server-webflux` is the runtime module. It registers auto-configuration in both `META-INF/spring.factories` and `META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports`, and uses `WebEndpointApplicationContextInitializer` to install the bind-handler advisor before route properties are bound.
+- The main runtime feature is web-endpoint routing. Gateway routes that use `uri: we://...` and usually `Path=/{application}/**` are intercepted by `WebEndpointMappingGlobalFilter`, which loads `WebEndpointMapping` metadata from discovered service instances, caches request-mapping candidates per route, rewrites the downstream path, adds the endpoint mapping ID header, and forwards to a load-balanced target instance.
+- `GatewayAutoConfiguration` also replaces Spring Cloud Gateway's `FilteringWebHandler` with `CachingFilteringWebHandler`, and wires listeners/interceptors that refresh route state on successful route refreshes, environment changes, and service-instance changes while suppressing heartbeat-triggered refresh noise.
+
+## Key conventions
+
+- The custom route scheme is `we`. `we://all` subscribes to every discovered service; otherwise the URI host names the subscribed services.
+- Per-route web-endpoint exclusions live under `spring.cloud.gateway.routes[*].metadata.web-endpoint.excludes` and use Spring request-mapping fields such as `patterns`, `methods`, `params`, `headers`, `consumes`, and `produces`.
+- Gateway features are layered behind property-based conditional annotations and default to enabled: `spring.cloud.gateway.enabled`, `microsphere.spring.cloud.gateway.enabled`, and `microsphere.spring.cloud.web-endpoint-mapping.enabled`.
+- When changing auto-configuration, keep both registration files in sync: `spring.factories` and `AutoConfiguration.imports`.
+- Tests rely on shared YAML fixtures in `src/test/resources/META-INF/config/default/test.yaml`. WebFlux integration-style tests commonly activate the `simple-service-registry,gateway` profiles and use `@EnableWebFluxExtension`.

.github/prompts/create-readme.prompt.md

@@ -0,0 +1,45 @@
+---
+agent: 'agent'
+description: 'Create a comprehensive README.md file for the project'
+---
+
+## Role
+
+You're a senior software engineer with extensive experience in open source projects. You create appealing, informative, and easy-to-read README files.
+
+## Task
+
+1. Review the entire project workspace and codebase
+2. Create a comprehensive README.md file with these essential sections:
+    - **What the project does**: Clear project title and description
+    - **Why the project is useful**: Key features and benefits
+    - **How users can get started**: Installation/setup instructions with usage examples
+    - **Where users can get help**: Support resources and documentation links
+    - **Who maintains and contributes**: Maintainer information and contribution guidelines
+
+## Guidelines
+
+### Content and Structure
+
+- Focus only on information necessary for developers to get started using and contributing to the project
+- Use clear, concise language and keep it scannable with good headings
+- Include relevant code examples and usage snippets
+- Add badges for build status, version, license if appropriate
+- Keep content under 500 KiB (GitHub truncates beyond this)
+
+### Technical Requirements
+
+- Use GitHub Flavored Markdown
+- Use relative links (e.g., `docs/CONTRIBUTING.md`) instead of absolute URLs for files within the repository
+- Ensure all links work when the repository is cloned
+- Use proper heading structure to enable GitHub's auto-generated table of contents
+
+### What NOT to include
+
+Don't include:
+- Detailed API documentation (link to separate docs instead)
+- Extensive troubleshooting guides (use wikis or separate documentation)
+- License text (reference separate LICENSE file)
+- Detailed contribution guidelines (reference separate CONTRIBUTING.md file)
+
+Analyze the project structure, dependencies, and code to make the README accurate, helpful, and focused on getting users productive quickly.

.github/prompts/document-api.prompt.md

@@ -0,0 +1,52 @@
+---
+agent: 'agent'
+description: 'Generate OpenAPI 3.0 specification for API endpoints'
+---
+
+## Task
+
+Analyze the API endpoint code and generate a valid OpenAPI 3.0 specification in YAML format.
+
+## OpenAPI Structure
+
+Generate a complete OpenAPI spec including:
+
+1. **OpenAPI Header**
+    - OpenAPI version (3.0.3)
+    - API info (title, description, version)
+    - Server configuration
+
+2. **Path Definitions**
+    - HTTP method and path
+    - Operation summary and description
+    - Tags for organization
+
+3. **Parameters Schema**
+    - Path parameters with type validation
+    - Query parameters with constraints and defaults
+    - Request body schema using proper JSON Schema
+    - Required vs optional parameters
+
+4. **Response Schemas**
+    - Success responses (200, 201, etc.) with schema definitions
+    - Error responses (400, 401, 404, 500) with error schema
+    - Content-Type specifications
+    - Realistic example values
+
+5. **Components Section**
+    - Reusable schemas for request/response models
+    - Security schemes (Bearer token, API key, etc.)
+    - Common parameter definitions
+
+## Requirements
+
+- Generate valid OpenAPI 3.0.3 YAML that passes validation
+- Use proper JSON Schema for all data models
+- Include realistic example values, not placeholders
+- Define reusable components to avoid duplication
+- Add appropriate data validation (required fields, formats, constraints)
+- Include security requirements where applicable
+
+Focus on: ${input:endpoint_focus:Which specific endpoint or endpoints should be documented?}
+
+Generate production-ready OpenAPI specification that can be used with Swagger UI, Postman, and code generators.

.github/prompts/explain-code.prompt.md

@@ -0,0 +1,19 @@
+---
+agent: 'agent'
+description: 'Generate a clear code explanation with examples'
+---
+
+Explain the following code in a clear, beginner-friendly way:
+
+Code to explain: Each Java file
+Target audience: beginners, intermediate developers, seansoned developers
+
+Please provide:
+
+* A brief overview of what the code does
+* A step-by-step breakdown of the main parts
+* Explanation of any key concepts or terminology
+* A simple example showing how it works
+* Common use cases or when you might use this approach
+
+Use clear, simple language and avoid unnecessary jargon.

.github/prompts/generate-unit-tests.prompt.md

@@ -0,0 +1,52 @@
+---
+agent: 'agent'
+description: 'Generate unit tests for selected functions or methods'
+---
+
+## Task
+
+Analyze the selected function/method and generate focused unit tests that thoroughly validate its behavior.
+
+## Test Generation Strategy
+
+1. **Core Functionality Tests**
+    - Test the main purpose/expected behavior
+    - Verify return values with typical inputs
+    - Test with realistic data scenarios
+
+2. **Input Validation Tests**
+    - Test with invalid input types
+    - Test with null/undefined values
+    - Test with empty strings/arrays/objects
+    - Test boundary values (min/max, zero, negative numbers)
+
+3. **Error Handling Tests**
+    - Test expected exceptions are thrown
+    - Verify error messages are meaningful
+    - Test graceful handling of edge cases
+
+4. **Side Effects Tests** (if applicable)
+    - Verify external calls are made correctly
+    - Test state changes
+    - Validate interactions with dependencies
+
+## Test Structure Requirements
+
+- Use existing project testing framework and patterns
+- Follow AAA pattern: Arrange, Act, Assert
+- Write descriptive test names that explain the scenario
+- Group related tests in describe/context blocks
+- Mock external dependencies cleanly
+
+Target function: ${input:function_name:Which function or method should be tested?}
+Testing framework: ${input:framework:Which framework? (jest/vitest/mocha/pytest/rspec/etc)}
+
+## Guidelines
+
+- Generate 5-8 focused test cases covering the most important scenarios
+- Include realistic test data, not just simple examples
+- Add comments for complex test setup or assertions
+- Ensure tests are independent and can run in any order
+- Focus on testing behavior, not implementation details
+
+Create tests that give confidence the function works correctly and help catch regressions.

.github/prompts/onboarding-plan.prompt.md

@@ -0,0 +1,26 @@
+---
+agent: 'agent'
+description: 'Help new team members onboard with a phased plan and suggestions for first tasks.'
+---
+
+# Create My Onboarding Plan
+
+I'm a new team member joining [Microsphere Projects](https://github.com/microsphere-projects) and I need help creating a structured onboarding plan.
+
+My background: the experienced developer new to this stack
+
+Please create a personalized phased onboarding plan that includes the following phases.
+
+## Phase 1 - Foundation
+
+Environment setup with step-by-step instructions and troubleshooting tips, plus identifying the most important documentation to read first
+
+## Phase 2 - Exploration
+
+Codebase discovery starting with README files, running existing tests/scripts to understand workflows, and finding beginner-friendly first tasks like documentation improvements. If possible, find me specific open issues or tasks that are suitable for my background.
+
+## Phase 3 - Integration
+
+Learning team processes, making first contributions, and building confidence through early wins
+
+For each phase, break down complex topics into manageable steps, recommend relevant resources, provide concrete next steps, and suggest hands-on practice over just reading theory.

.github/prompts/review-code.prompt.md

@@ -0,0 +1,59 @@
+---
+agent: 'agent'
+description: 'Perform a comprehensive code review'
+---
+
+## Role
+
+You're a senior software engineer conducting a thorough code review. Provide constructive, actionable feedback.
+
+## Review Areas
+
+Analyze the selected code for:
+
+1. **Security Issues**
+    - Input validation and sanitization
+    - Authentication and authorization
+    - Data exposure risks
+    - Injection vulnerabilities
+
+2. **Performance & Efficiency**
+    - Algorithm complexity
+    - Memory usage patterns
+    - Database query optimization
+    - Unnecessary computations
+
+3. **Code Quality**
+    - Readability and maintainability
+    - Proper naming conventions
+    - Function/class size and responsibility
+    - Code duplication
+
+4. **Architecture & Design**
+    - Design pattern usage
+    - Separation of concerns
+    - Dependency management
+    - Error handling strategy
+
+5. **Testing & Documentation**
+    - Test coverage and quality
+    - Documentation completeness
+    - Comment clarity and necessity
+
+## Output Format
+
+Provide feedback as:
+
+**🔴 Critical Issues** - Must fix before merge
+**🟡 Suggestions** - Improvements to consider
+**✅ Good Practices** - What's done well
+
+For each issue:
+- Specific line references
+- Clear explanation of the problem
+- Suggested solution with code example
+- Rationale for the change
+
+Focus on: ${input:focus:Any specific areas to emphasize in the review?}
+
+Be constructive and educational in your feedback.

CONTRIBUTING.md

@@ -0,0 +1,35 @@
+# Contributing
+
+Thanks for contributing to Microsphere Gateway.
+
+## Before You Start
+
+- Search [existing issues](https://github.com/microsphere-projects/microsphere-gateway/issues) before opening a new report or feature request.
+- For behavior or API changes, open an issue first so the approach can be discussed early.
+
+## Local Setup
+
+```bash
+git clone https://github.com/microsphere-projects/microsphere-gateway.git
+cd microsphere-gateway
+./mvnw package
+./mvnw test -Ptest,spring-cloud-2025
+```
+
+The project targets Java 17+ and is exercised in CI across multiple Spring Cloud profiles.
+
+## Making Changes
+
+1. Create a branch from `main`.
+2. Keep changes focused and update documentation when behavior changes.
+3. Run the relevant Maven build or test command before submitting.
+
+## Pull Requests
+
+1. Describe the problem and the intended fix clearly.
+2. Link the related issue when one exists.
+3. Include tests for code changes when practical.
+
+## Community Standards
+
+By participating, you agree to follow [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md).