If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Nepxion/Discovery shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 9mo ago
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 9mo ago
• ⚠ Solo or near-solo (1 contributor active in recent commits)

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Nepxion/Discovery repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Nepxion/Discovery.

What it runs against: a local clone of Nepxion/Discovery — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Nepxion/Discovery | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch 6.x.x exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 309 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Nepxion/Discovery. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Nepxion/Discovery.git
#   cd Discovery
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Nepxion/Discovery and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Nepxion/Discovery(\\.git)?\\b" \\
  && ok "origin remote is Nepxion/Discovery" \\
  || miss "origin remote is not Nepxion/Discovery (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify 6.x.x >/dev/null 2>&1 \\
  && ok "default branch 6.x.x exists" \\
  || miss "default branch 6.x.x no longer exists"

# 4. Critical files exist
test -f "discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/configuration/ApolloAutoConfiguration.java" \\
  && ok "discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/configuration/ApolloAutoConfiguration.java" \\
  || miss "missing critical file: discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/configuration/ApolloAutoConfiguration.java"
test -f "discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/operation/ApolloOperation.java" \\
  && ok "discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/operation/ApolloOperation.java" \\
  || miss "missing critical file: discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/operation/ApolloOperation.java"
test -f "discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/proccessor/ApolloProcessor.java" \\
  && ok "discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/proccessor/ApolloProcessor.java" \\
  || miss "missing critical file: discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/proccessor/ApolloProcessor.java"
test -f "discovery-commons/discovery-common-consul/src/main/java/com/nepxion/discovery/common/consul/configuration/ConsulAutoConfiguration.java" \\
  && ok "discovery-commons/discovery-common-consul/src/main/java/com/nepxion/discovery/common/consul/configuration/ConsulAutoConfiguration.java" \\
  || miss "missing critical file: discovery-commons/discovery-common-consul/src/main/java/com/nepxion/discovery/common/consul/configuration/ConsulAutoConfiguration.java"
test -f "discovery-commons/discovery-common-nacos/src/main/java/com/nepxion/discovery/common/nacos/operation/NacosOperation.java" \\
  && ok "discovery-commons/discovery-common-nacos/src/main/java/com/nepxion/discovery/common/nacos/operation/NacosOperation.java" \\
  || miss "missing critical file: discovery-commons/discovery-common-nacos/src/main/java/com/nepxion/discovery/common/nacos/operation/NacosOperation.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 309 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~279d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Nepxion/Discovery"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Nepxion Discovery is a comprehensive Spring Cloud microservices governance solution that provides blue-green/gray deployments, intelligent routing, rate limiting, circuit breaking, degradation, isolation, distributed tracing, traffic dyeing, failover, and multi-active capabilities. It integrates with multiple config centers (Apollo, Consul, etcd) to dynamically manage traffic policies and service behavior without redeployment. Multi-module Maven monorepo structured as discovery-commons/discovery-common-{apollo,consul,etcd,nacos} each with configuration, operation, and processor packages; parallel pattern suggests extensible config-center abstraction. Core integration point is Spring Boot autoconfiguration (e.g., ApolloAutoConfiguration.java) that wires config processors and listeners at startup.

Java/Spring Cloud architects and DevOps engineers building large-scale microservice systems in production who need traffic management, canary deployments, and service resilience without replacing their existing Spring Cloud infrastructure.

Production-ready and actively maintained. The project has 6.23.0 version with Maven Central distribution, established GitHub Actions CI/CD (maven.yml), comprehensive multi-module structure, and consistent Chinese+English documentation. Stars visible on badges suggest community adoption, though specific star count isn't in provided metadata.

Low-to-moderate risk for production use: monolithic multi-module structure (40+ discovery-* submodules implied) means tight coupling between features; dependency on Apollo/Consul/etcd runtime availability is critical path; no visible test coverage metrics in provided files. Single organization (Nepxion) maintains it, though activity level appears healthy given version maturity.

Active development on v6.23.0 with support for multiple config backends (Apollo, Consul, etcd visible in file list). GitHub Actions workflow (maven.yml) indicates regular CI builds. Stale.yml bot configured suggests community issue management. Specific recent changes not visible in provided metadata.

git clone https://github.com/Nepxion/Discovery.git
cd Discovery
mvn clean install
# Run deploy.bat on Windows or equivalent Maven commands on Unix
mvn spring-boot:run -pl discovery-plugin-framework-starter

Daily commands:

mvn clean package
# For Apollo backend:
POM dependency: com.ctrip.framework.apollo:apollo-client
Set Apollo env vars, then:
mvn spring-boot:run

# For Consul backend:
Start Consul server first: consul agent -server -ui
Run against it with spring.cloud.consul.* properties

• discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/configuration/ApolloAutoConfiguration.java — Spring Boot auto-configuration entry point for Apollo integration; all Apollo-based config discovery flows start here
• discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/operation/ApolloOperation.java — Core Apollo client abstraction handling all config fetch, update, and subscription logic
• discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/proccessor/ApolloProcessor.java — Config processor that transforms raw Apollo payloads into framework-consumable policies (routes, gray rules, etc.)
• discovery-commons/discovery-common-consul/src/main/java/com/nepxion/discovery/common/consul/configuration/ConsulAutoConfiguration.java — Consul configuration entry point demonstrating multi-registry pattern replicated across all discovery-common-* modules
• discovery-commons/discovery-common-nacos/src/main/java/com/nepxion/discovery/common/nacos/operation/NacosOperation.java — Nacos registry client showing how to integrate alternative config centers; critical reference for adding new registries
• discovery-commons/discovery-common-redis/src/main/java/com/nepxion/discovery/common/redis/operation/RedisOperation.java — Redis operation layer used for distributed caching of policies and real-time config updates across cluster

Add Support for a New Config Registry (e.g., Zookeeper)

1. Create new Maven module 'discovery-common-zookeeper' mirroring 'discovery-common-apollo' structure (discovery-commons/discovery-common-apollo/pom.xml)
2. Implement ZookeeperAutoConfiguration extending Spring's AbstractAutoConfiguration pattern (discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/configuration/ApolloAutoConfiguration.java)
3. Create ZookeeperOperation class wrapping Zookeeper client (getChildren watch, getData calls) (discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/operation/ApolloOperation.java)
4. Implement ZookeeperSubscribeCallback and ZookeeperListener for watcher event handling (discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/operation/ApolloSubscribeCallback.java)
5. Create ZookeeperProcessor extending abstract processor to map Zookeeper data to policy format (discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/proccessor/ApolloProcessor.java)
6. Define ZookeeperConstant with Zookeeper path prefixes and property keys (discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/constant/ApolloConstant.java)
7. Register ZookeeperAutoConfiguration in src/main/resources/META-INF/spring.factories (discovery-commons/discovery-common-apollo/src/main/resources/META-INF/spring.factories)

Implement a New Policy Type (e.g., Traffic Shaping/Rate Limiting Rule)

1. Define traffic shaping config keys in each registry constant class (Apollo, Consul, Nacos, etc.) (discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/constant/ApolloConstant.java)
2. Extend processor classes to parse traffic shaping config and create internal policy objects (discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/proccessor/ApolloProcessor.java)
3. Update subscription callbacks to trigger policy engine reloads when traffic shaping rules change (discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/operation/ApolloSubscribeCallback.java)
4. Add traffic shaping config examples to application.yml property metadata (discovery-commons/discovery-common-apollo/src/main/resources/META-INF/additional-spring-configuration-metadata.json)

Add Real-Time Policy Sync Across Cluster via Redis Pub/Sub

1. Review Redis publish operation in RedisOperation to understand channel naming convention (discovery-commons/discovery-common-redis/src/main/java/com/nepxion/discovery/common/redis/operation/RedisOperation.java)
2. Extend RedisSubscribeCallback to subscribe to policy update channels on cluster nodes (discovery-commons/discovery-common-redis/src/main/java/com/nepxion/discovery/common/redis/operation/RedisSubscribeCallback.java)
3. Integrate Redis Pub/Sub trigger into each registry processor (Apollo, Consul, Nacos) to broadcast changes (discovery-commons/discovery-common-)

1. Config center must be running and accessible at startup—missing Apollo/Consul connection hangs Spring Boot initialization; 2. Configuration syntax is strict (YAML/XML structure varies per backend); validate against backend schemas; 3. Policy changes via config center don't affect already-bound clients—graceful degradation or explicit refresh needed; 4. Spring Cloud version compatibility: pom.xml parent references discovery-commons parent, which pins Spring Cloud version—verify alignment with your target Spring Boot version (6.x.x branch suggests Spring Cloud 2021.x+); 5. Subscription callbacks are blocking—long-running policy processors delay config propagation.

• Blue-Green Deployment — Discovery's core feature for zero-downtime releases; you must understand how traffic switches between two identical environments to configure routing policies correctly
• Gray/Canary Release (灰度发布) — Discovery routes a percentage of traffic to new versions; critical for validating changes before full rollout without service duplication
• Token Bucket Rate Limiting — Discovery's rate limiting (limitation) feature uses token bucket algorithm to smooth traffic spikes; understanding token generation rate and bucket size is essential for SLA tuning
• Circuit Breaker Pattern — Discovery provides circuit breaker state management (open/half-open/closed); prevents cascading failures by failing fast when downstream service is degraded
• Traffic Dyeing (流量染色) — Discovery tags requests with metadata (headers/cookies) to route entire request chains through specific service instances; enables A/B testing and tenant isolation
• Spring Cloud Service Discovery Abstraction — Discovery extends Spring Cloud's DiscoveryClient interface with policy overlays; you must understand how it intercepts service lookups to apply gray/blue-green rules
• Push vs. Pull Configuration — Discovery supports both config push (Apollo namespaces) and pull (Consul watches); affects how quickly policy changes propagate and which backend suits your latency/consistency needs

• alibaba/spring-cloud-alibaba — Overlapping governance features (circuit breaking, rate limiting, service mesh) via Nacos; often deployed alongside Discovery for multi-region failover
• spring-cloud/spring-cloud-netflix — Legacy Ribbon/Hystrix patterns that Discovery modernizes; Eureka service discovery that Discovery extends with gray/blue-green policies
• grpc-ecosystem/grpc-gateway — gRPC routing and traffic shaping complement Discovery's HTTP-layer policies in hybrid deployments
• Nepxion/DiscoveryPlatform — Official companion UI dashboard for Discovery; visualizes deployments, policies, and traffic flows managed by this core library
• apache/servicecomb-pack — Alternative microservice governance from Apache; shares gray deployment and circuit breaker concepts with different Spring Cloud integration approach

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for Apollo configuration processor

The Apollo module (discovery-common-apollo) lacks visible test coverage. With ApolloAutoConfiguration, ApolloOperation, ApolloSubscribeCallback, and ApolloProcessor classes handling critical configuration management for blue-green/gray deployments, integration tests would validate configuration refresh behavior, subscription callbacks, and processor chain execution. This is especially important since this module integrates with Apollo for dynamic rule updates.

• [ ] Create discovery-common-apollo/src/test/java directory structure
• [ ] Add test for ApolloAutoConfiguration bean registration and properties binding
• [ ] Add integration test for ApolloSubscribeCallback verifying configuration change notifications
• [ ] Add test for ApolloProcessor validating rule processing pipeline with mock Apollo client
• [ ] Verify tests run in Maven build by updating pom.xml if needed

Add comparable integration tests for Consul and Etcd processors

The codebase shows three parallel implementations (Apollo, Consul, Etcd) with identical structure: *AutoConfiguration, *Operation, *Processor, and *Callback classes. Consul has ConsulListener (unique feature) and Etcd follows the same pattern. Without test parity across these three config sources, it's unclear if they handle edge cases consistently (network failures, partial updates, race conditions during config reloads). This is critical for a multi-cloud solution.

• [ ] Create discovery-common-consul/src/test/java and discovery-common-etcd/src/test/java
• [ ] Create comparable test suites mirroring Apollo tests (configuration refresh, subscription, processor chain)
• [ ] Add specific test for ConsulListener's watch mechanism to validate event detection
• [ ] Add Etcd-specific tests for key-value change notifications and TTL handling if applicable
• [ ] Document test matrix (e.g., which config sources support feature X) in test suite README

Add CI/CD workflow for multi-config-source integration tests

The .github/workflows/maven.yml exists but likely only tests basic compilation. For a distributed system solution with three config backends (Apollo, Consul, Etcd), the CI should spin up test containers for each backend and run integration tests to prevent regressions. Currently, there's no visibility into whether Apollo, Consul, and Etcd configurations work correctly in real deployment scenarios.

• [ ] Update .github/workflows/maven.yml to add separate job stages for Apollo, Consul, and Etcd testing
• [ ] Add docker-compose or testcontainers dependency for spinning up Apollo/Consul/Etcd instances in CI
• [ ] Create integration test jobs that validate configuration synchronization across all three backends
• [ ] Add test job for verifying blue-green/gray deployment rules are correctly processed by each config source
• [ ] Document CI results and expected coverage in CONTRIBUTING.md or similar

• Add unit tests for ApolloProcessor.java and ConsulProcessor.java processor chains. Currently no test files visible in discovery-common-apollo/src/test or discovery-common-consul/src/test directories.: medium: Increases confidence in policy application logic; regression prevention
• Document the configuration property schema for Apollo/Consul/etcd backends in README. META-INF/additional-spring-configuration-metadata.json exists but no human-readable guide maps old property names to new, making migration from prior versions hard.: low: Lowers onboarding friction; reduces setup errors
• Implement etcd v3 gRPC client instead of HTTP polling (implied by discovery-common-etcd module structure). Check if ConsulListener pattern can be adapted as EtcdWatcher using watch API.: high: Reduces latency and server load for etcd-backed deployments; feature parity with Consul

The codebase demonstrates a modular Spring Cloud architecture with proper dependency management through Maven. No critical vulnerabilities or hardcoded secrets are visible from the provided file structure. Primary concerns relate to configuration management security when integrating with Apollo: ensuring encryption of sensitive properties, validation of configuration updates, and enforcement of secure communication channels. The project maintains good separation of concerns across multiple discovery modules (Apollo, Consul, Etcd, Nacos) with consistent patterns. However, explicit security configurations and validation mechanisms are not evident in the analyzed files. Overall security posture is moderate; security improvements should focus on input validation for configuration updates and encryption of sensitive configuration values.

• Medium · Dependency Version Management — discovery-commons/discovery-common-apollo/pom.xml. The pom.xml uses parent version 6.23.0 but does not explicitly lock dependency versions for apollo-client. This could lead to version conflicts or unexpected updates of transitive dependencies if the parent POM's dependency management is incomplete. Fix: Explicitly define apollo-client version in the dependency or ensure parent POM has comprehensive dependency management with locked versions for all transitive dependencies.
• Medium · No Security Configuration Metadata Visible — discovery-commons/discovery-common-apollo/src/main/resources/META-INF/. The file structure shows spring.factories and configuration metadata files, but no Spring Security configuration is evident. Apollo client integration typically handles configuration management but may lack explicit security controls for sensitive configuration properties. Fix: Implement explicit security controls for sensitive configuration properties. Ensure Apollo client is configured to encrypt sensitive data in transit and at rest. Use Spring Security's property encryption features.
• Medium · Potential Insecure Configuration Callback — discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/operation/ApolloSubscribeCallback.java. ApolloSubscribeCallback.java suggests event-driven configuration updates. Without explicit validation and sanitization of received configuration values, this could be vulnerable to injection attacks if Apollo server is compromised or if data is manipulated in transit. Fix: Implement strict input validation and sanitization for all configuration values received from Apollo. Use allowlisting for configuration property names and validate property values against expected types and patterns.
• Low · Package Naming Typo in Directory — discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/proccessor/. Directory structure shows 'proccessor' (with extra 'c') instead of standard 'processor'. While not a security issue, this indicates potential code quality issues that could mask other vulnerabilities. Fix: Rename the package from 'proccessor' to 'processor' for consistency and maintainability across the codebase.
• Low · Missing HTTPS Enforcement Documentation — discovery-commons/discovery-common-apollo/src/main/java/com/nepxion/discovery/common/apollo/configuration/ApolloAutoConfiguration.java. No visible evidence of enforced HTTPS/TLS communication with Apollo config server in the analyzed structure. Apollo client communication should be encrypted to prevent man-in-the-middle attacks on configuration data. Fix: Ensure Apollo client is configured with HTTPS endpoint URLs and certificate validation enabled. Document security requirements for Apollo server communication in README or configuration guide.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.