WAIT — Mixed signals — read the receipts

• Last commit 3d ago
• 16 active contributors
• MulanPSL-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 59% of recent commits
• ⚠ Non-standard license (MulanPSL-2.0) — review terms
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

Hutool is a comprehensive Java utility library (8.4MB of code) that bundles 50+ reusable tool classes covering strings, numbers, collections, encoding, dates, files, I/O, encryption, JDBC, JSON, and HTTP clients. It solves the problem of repetitive boilerplate code in Java applications by providing well-tested, production-grade helper methods—much like Apache Commons or Guava, but with Chinese-first documentation and a permissive copy-without-attribution philosophy. Multi-module Maven monorepo with core utilities in hutool-core and specialized packages (hutool-ai, hutool-http, hutool-json, hutool-log, etc.) as separate artifacts. The hutool-ai module demonstrates the pattern: src/main/java/cn/hutool/ai contains AIConfig, AIService, AIServiceFactory abstractions that wrap LLM providers. Root-level bin/ contains deployment and build scripts (deploy.sh, package.sh, update_version.sh); docs/ holds generated API documentation.

Java backend developers and teams who need fast, reliable utility functions for common tasks (date formatting, collection operations, HTTP requests, cryptography) without adding heavy dependencies. Also useful for Chinese-speaking developers who benefit from extensive native-language code comments and documentation at hutool.cn.

Highly mature and production-ready. The project has significant adoption (evidenced by Maven Central distribution and multiple GitHub/Gitee stars), runs CI/CD via Travis CI (.travis.yml present), maintains CHANGELOG across versions (CHANGELOG_5.0-5.7.md), and is at version 5.8.46 with a monorepo structure. Active maintenance is clear from the recent hutool-ai module addition for LLM integration.

Low risk for stability, but moderate maintenance dependency: the project is single-maintainer (looly/chinabugotech), making long-term support contingent on one person. Breaking changes have occurred between major versions (evidenced by separate CHANGELOG files). The codebase is large (8MB) with many modules, increasing surface area for bugs, though test infrastructure appears solid (Codacy badge, CodeCov integration). Dependencies on hutool-core, hutool-http, hutool-json, hutool-log suggest tight internal coupling across modules.

Active development on AI/LLM integration (hutool-ai module with AIServiceFactory, AIConfigRegistry, ModelName abstractions for pluggable AI providers). Version drift management ongoing (bin/check_dependency_updates.sh, bin/update_version.sh scripts). Security policy in place (SECURITY.md added), suggesting increased project governance.

git clone https://github.com/chinabugotech/hutool.git
cd hutool
./bin/fast_install.sh

Or using Maven directly: mvn clean install in the root directory. The project requires JDK 8+ (per README badge).

Daily commands: This is a library, not an application. To verify builds locally: mvn clean test or use ./bin/test.sh. To generate Javadoc: ./bin/javadoc.sh. To package all modules: ./bin/package.sh. Individual modules can be imported into your project via Maven coordinates like <groupId>cn.hutool</groupId><artifactId>hutool-all</artifactId><version>5.8.46</version>.

• hutool-ai/src/main/java/cn/hutool/ai/core/AIService.java — Core interface defining the contract for all AI service implementations; every AI provider must implement this.
• hutool-ai/src/main/java/cn/hutool/ai/core/BaseAIService.java — Abstract base class providing common functionality for all AI service implementations.
• hutool-ai/src/main/java/cn/hutool/ai/AIServiceFactory.java — Factory class for instantiating and managing AI service instances; entry point for using the AI module.
• hutool-ai/src/main/java/cn/hutool/ai/core/AIConfig.java — Core configuration interface that all AI provider configs must implement.
• hutool-ai/src/main/java/cn/hutool/ai/core/AIConfigRegistry.java — Registry for managing and looking up AI configurations for different providers.
• hutool-ai/src/main/resources/META-INF/services/cn.hutool.ai.core.AIConfig — SPI configuration file for service loader discovery of AI config implementations.

• AIServiceFactory (Java reflection, SPI, AIConfigRegistry) — Locates and instantiates the correct AI service provider based on model name.
  • Failure mode: Returns null or throws exception if provider not found or misconfigured.
• BaseAIService (Template method pattern, Message/AIConfig models) — Provides common logic for message handling, request building, and error management across all providers.
  • Failure mode: Propagates provider-specific errors as AIException; incomplete implementation in subclass causes runtime errors.
• Provider ServiceImpl (e.g., OpenaiServiceImpl) (HTTP client, JSON marshaling, provider SDK (if used)) — Translates Message objects into provider-specific API calls and parses responses back to Message format.
  • Failure mode: API errors (rate limits, auth failures, network issues) result in AIException with original error details.
• AIConfigRegistry (SPI, Map-based caching, AIConfig interface) — Manages and caches configurations for each provider; allows runtime config registration and lookup.
  • Failure mode: Config not found returns null; duplicate registrations overwrite previous entries silently.
• AIConfig/BaseConfig (Builder pattern, inheritance hierarchy) — Encapsulates provider-specific credentials, endpoints, model parameters, and connection settings.
  • Failure mode: Missing required fields (API key) cause service instantiation or request failures.
• Message (POJO with getters/setters, equals/hashCode) — Represents a single message in a conversation (role, content, metadata); acts as data transfer object between layers.
  • Failure mode: Null content or invalid role causes provider request validation to fail.
• AIUtil (Static methods, AIServiceFactory delegation) — Provides convenience methods and shortcuts for common AI operations; facade over factory and service.
  • Failure mode: Delegates failures to underlying factory/service; may hide provider initialization errors.

• Application Code → AIServiceFactory — Application calls getService(modelName) to obtain a ready-to-use AIService instance.
• AIServiceFactory → AIConfigRegistry — Factory looks up configuration for the requested provider.
• AIConfigRegistry → AIServiceProvider — Registry delegates to provider's factory method to instantiate the service.
• Application Code → AIService — Application calls service methods (e.g., chat(messages)) with Message objects.
• AIService → External AI Provider API — Service serializes messages to provider-specific request JSON and sends HTTP request.
• External AI Provider API → AIService — Provider returns JSON response which service deserializes back to Message objects.

Add a New AI Provider

1. Create provider package under hutool-ai/src/main/java/cn/hutool/ai/model/[providername]/ (hutool-ai/src/main/java/cn/hutool/ai/model/openai/)
2. Create [Provider]Config extending BaseConfig with provider-specific settings (hutool-ai/src/main/java/cn/hutool/ai/model/openai/OpenaiConfig.java)
3. Create [Provider]ServiceImpl extending BaseAIService to implement API calls (hutool-ai/src/main/java/cn/hutool/ai/model/openai/OpenaiServiceImpl.java)
4. Create [Provider]Provider implementing AIServiceProvider for factory instantiation (hutool-ai/src/main/java/cn/hutool/ai/model/openai/OpenaiProvider.java)
5. Create [Provider]Common utility class with constants and helper methods (hutool-ai/src/main/java/cn/hutool/ai/model/openai/OpenaiCommon.java)
6. Register the provider in META-INF/services/cn.hutool.ai.core.AIConfig via SPI (hutool-ai/src/main/resources/META-INF/services/cn.hutool.ai.core.AIConfig)

Add a New Configuration Option to All Providers

1. Add property to BaseConfig class (hutool-ai/src/main/java/cn/hutool/ai/core/BaseConfig.java)
2. Add setter/getter to BaseConfig or update AIConfigBuilder (hutool-ai/src/main/java/cn/hutool/ai/core/AIConfigBuilder.java)
3. Update each provider-specific config class to handle the new property (hutool-ai/src/main/java/cn/hutool/ai/model/openai/OpenaiConfig.java)

Add a New Message Type or Communication Feature

1. Extend or modify the Message class to support new fields or types (hutool-ai/src/main/java/cn/hutool/ai/core/Message.java)
2. Update BaseAIService.java to handle the new message structure in common logic (hutool-ai/src/main/java/cn/hutool/ai/core/BaseAIService.java)
3. Update each provider-specific ServiceImpl to handle the new message type (hutool-ai/src/main/java/cn/hutool/ai/model/openai/OpenaiServiceImpl.java)

• Java 8+ — Hutool targets JDK 8+ for broad compatibility; uses modern Java features like lambdas and streams in base utilities.
• Service Provider Interface (SPI) — Enables pluggable provider discovery and registration without modifying core code; supports dynamic provider loading via META-INF/services.
• Abstract Base Classes (BaseAIService, BaseConfig) — Reduces code duplication across providers and enforces consistent behavior and interface contracts.
• Factory Pattern (AIServiceFactory) — Centralizes service instantiation and provider selection logic; simplifies consumer API.

• Configuration via immutable/builder pattern rather than annotations

  • Why: Provides explicit control and type safety; simpler for users to understand configuration flow.
  • Consequence: Requires more boilerplate code in config classes; less automatic detection of provider capabilities.

• One BaseAIService for all providers despite API differences

  • Why: Maximizes code reuse and maintains consistent interface; eases swapping providers.
  • Consequence: Provider-specific features must be abstracted or passed through generic methods; may hide some API capabilities.

• SPI-based provider registration instead of hardcoded factories

  • Why: Decouples provider implementations from core; allows third-party providers without modifying hutool.
  • Consequence: Requires META-INF/services entries; less obvious where providers are registered; discovery happens at runtime.

• Real-time streaming responses (chat completion streaming)
• Image generation or vision APIs
• Fine-tuning or model training workflows
• Authentication beyond API key management
• Advanced caching or response deduplication
• Multi-turn conversation state management beyond message passing

• Broad exception catching in BaseAIService (Medium) — hutool-ai/src/main/java/cn/hutool/ai/core/BaseAIService.java: Catching generic Exception instead of specific API-related exceptions may hide unexpected errors and make debugging harder.
• Config lookup without null checks in factory (Medium) — hutool-ai/src/main/java/cn/hutool/ai/AIServiceFactory.java: If AIConfigRegistry returns null for an unregistered provider, factory may fail with unclear NullPointerException instead of descriptive error.
• Provider-specific implementation details leaking into BaseAIService (Low) — hutool-ai/src/main/java/cn/hutool/ai/core/BaseAIService.java: Template methods may contain conditional logic branching on provider type, reducing abstraction quality.

• hutool-ai/src/main/java/cn/hutool/ai/AIServiceFactory.java (Performance) — Service instantiation happens on every factory call; no caching of service instances per config.
• hutool-ai/src/main/java/cn/hutool/ai/core/BaseAIService.java (Scalability) — Message list serialization in chat() method may be slow for large conversation histories; no batching or pagination.
• External API calls in (undefined) — undefined

No obvious required environment variables or external service dependencies for building. However: (1) The bin/ scripts assume Bash and Linux/macOS environment (no native Windows support evident); use Git Bash or WSL on Windows. (2) Maven settings.xml must be configured with credentials for deploying to Maven Central (bin/deploy.sh requires this). (3) Version management is centralized in bin/version.txt and bin/update_version.sh—changing versions manually in pom.xml files will cause inconsistencies. (4) The monorepo uses relative parent references in pom.xml (parent version = ${project.parent.version}), so individual modules cannot be built in isolation without installing the parent pom first.

• Service Provider Interface (SPI) / Plugin Architecture — The AIServiceFactory and AIServiceProvider pattern in hutool-ai demonstrates how Hutool abstracts provider implementations; understanding this is critical for extending Hutool with custom AI models or swapping implementations
• Factory Pattern with Registry — AIServiceFactory combined with AIConfigRegistry shows how Hutool decouples object creation from usage; you'll use this pattern when adding new providers or utilities
• Monorepo with Maven Multimodule Architecture — Hutool organizes 10+ modules (core, http, json, ai, log, etc.) in one repository with parent pom inheritance; understanding inter-module dependencies and version management is essential for local development
• Builder Pattern — AIConfigBuilder class in hutool-ai exemplifies fluent configuration API design; Hutool uses Builders extensively to simplify complex object setup without constructor overloading
• Encryption and Hashing Primitives — Hutool abstracts AES, RSA, MD5, SHA, and HMAC operations; understanding symmetric vs. asymmetric crypto and when to use each is crucial for security-sensitive utilities in the codebase
• JDBC Abstraction Layer — Hutool provides db utilities that wrap raw JDBC; understanding connection pooling, statement caching, and ORM patterns helps you leverage the database module effectively
• HTTP Client Abstraction — hutool-http wraps HTTP operations with connection pooling and request/response interceptors; critical for understanding how Hutool's AI module makes LLM API calls under the hood

• google/guava — Industry-standard Java utilities library; Hutool is a spiritual competitor with lower overhead and Chinese focus
• apache/commons-lang — Apache Commons Lang provides similar string/number/collection utilities; Hutool bundles more (HTTP, JSON, crypto) into one library
• alibaba/fastjson — Fast JSON processing for Java; likely used internally by hutool-json module for serialization
• looly/hutool-site — Official documentation site repository (referenced in README); companion repo containing website assets and API docs hosting
• chinabugotech/hutool-generator — Code generation tooling companion; generates boilerplate for Hutool-based projects (inferred from hutool ecosystem pattern)

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 comprehensive unit tests for hutool-ai module

The hutool-ai module is relatively new (evident from the file structure showing AI service providers like DeepSeek, Doubao, Gemini) but appears to lack corresponding test files. This module handles critical AI service integration logic (config, providers, service implementations) that needs robust test coverage. New contributors can add unit tests for core AI classes like AIServiceFactory, AIConfigRegistry, BaseAIService, and model-specific implementations (DeepSeekServiceImpl, DoubaoServiceImpl).

• [ ] Create hutool-ai/src/test/java/cn/hutool/ai/core/ directory structure
• [ ] Add unit tests for AIServiceFactory.java and AIConfigRegistry.java
• [ ] Add unit tests for BaseAIService.java and Message.java
• [ ] Add unit tests for DeepSeekServiceImpl.java and DoubaoServiceImpl.java with mocked HTTP calls
• [ ] Add integration tests for AIConfigBuilder and configuration validation logic
• [ ] Ensure test coverage for error handling (AIException scenarios)

Add GitHub Actions workflow for hutool-ai module testing and deployment

While .travis.yml exists and GitHub Actions workflow files are present (codeql-analysis.yml), there's no dedicated workflow for building and testing the hutool-ai module specifically. Given that AI service integrations require API credentials and have external dependencies, a dedicated workflow should test the core logic, validate configuration handling, and ensure the module builds correctly on each commit.

• [ ] Create .github/workflows/hutool-ai-test.yml for unit testing the ai module
• [ ] Add Maven build step: 'mvn clean test -pl hutool-ai'
• [ ] Add linting/code quality checks specific to AI service implementations
• [ ] Include matrix testing for JDK 8+ compatibility (per badge in README)
• [ ] Document any secrets needed for API testing in SECURITY.md

Add documentation and examples for hutool-ai module in docs directory

The hutool-ai module supports multiple LLM providers (DeepSeek, Doubao, Gemini visible in file structure) but there's no corresponding documentation in the docs/ folder. The apidocs folder exists but lacks specific guides for using AI services. New contributors can create implementation guides and usage examples for each AI provider.

• [ ] Create docs/ai/index.md with overview of hutool-ai capabilities
• [ ] Create docs/ai/getting-started.md with basic usage examples for AIUtil and AIServiceFactory
• [ ] Create docs/ai/providers/deepseek.md with DeepSeek-specific configuration and example code
• [ ] Create docs/ai/providers/doubao.md with Doubao-specific configuration and example code
• [ ] Create docs/ai/configuration.md documenting AIConfigBuilder and AIConfig properties
• [ ] Add code examples showing error handling (AIException) and message formatting

• Add unit tests for cn.hutool.ai.core.AIConfigBuilder—the AIConfigBuilder class is defined but no corresponding test file is visible in the hutool-ai structure, leaving test coverage gaps for configuration validation logic.
• Expand Chinese documentation comments in hutool-ai/src/main/java/cn/hutool/ai/AIUtil.java—the Hutool philosophy emphasizes Chinese-first documentation, but AIUtil (a public API entry point) likely needs richer comments for non-English developers.
• Implement support for additional LLM providers in AIServiceFactory—currently only scaffolding is visible; adding concrete implementations for Claude, Gemini, or local models (LLaMA) as registered providers would be high-value and moderate difficulty.

The hutool-ai module presents a moderate security posture. Primary concerns relate to external AI service integration, API credential management, and HTTP communication security. The codebase lacks visible evidence of comprehensive security controls for configuration management and exception handling. The project benefits from a well-defined security policy and version support strategy. Recommendations focus on securing API integrations, enforcing strict input/output validation, implementing secure configuration management, and adding automated security scanning to the development pipeline.

• Medium · AI Module with External Service Integration — hutool-ai/src/main/java/cn/hutool/ai/. The hutool-ai module integrates with multiple external AI services (DeepSeek, Doubao, Gemini, Grok, Hutool). This introduces risks around: (1) API key management and exposure, (2) Man-in-the-middle attacks if HTTPS is not enforced, (3) Dependency on external service availability and security posture. Fix: Ensure: (1) API keys are never hardcoded and are loaded from secure environment variables or secure vaults, (2) HTTPS is enforced for all external API calls, (3) Input validation is performed on all responses from external services to prevent injection attacks, (4) API rate limiting and timeout configurations are implemented
• Medium · Dynamic Configuration Management — hutool-ai/src/main/java/cn/hutool/ai/core/AIConfigRegistry.java, AIConfigBuilder.java. The AIConfigRegistry and AIConfigBuilder classes suggest dynamic configuration of AI services. Without proper validation, this could lead to misconfigurations or injection vulnerabilities if configuration sources are untrusted. Fix: Implement strict input validation for all configuration parameters, use allowlists for service providers, validate configuration against a schema, and log all configuration changes
• Medium · HTTP Client Usage Without Visible Security Controls — hutool-ai/pom.xml (hutool-http dependency). The module depends on hutool-http for HTTP communication. Without seeing the actual implementation, there's risk of: (1) Insecure SSL/TLS configuration, (2) Missing certificate pinning, (3) Inadequate request/response validation. Fix: Verify that: (1) TLS 1.2 or higher is enforced, (2) Certificate validation is enabled, (3) Hostname verification is configured, (4) Request/response size limits are set, (5) Security headers are properly handled
• Low · Potential Information Disclosure in Exception Handling — hutool-ai/src/main/java/cn/hutool/ai/AIException.java. The AIException class is present but implementation details are not visible. Improper exception handling could leak sensitive information (API endpoints, service details) in stack traces or error messages. Fix: Ensure exception messages do not contain: sensitive configuration, API keys, full stack traces in production, or internal service details. Implement proper exception wrapping and sanitization
• Low · Outdated Parent Version — hutool-ai/pom.xml. The parent POM version is 5.8.46. While this is supported per SECURITY.md, it's important to verify this is the latest available patch version to ensure all security updates are included. Fix: Check for newer patch versions of hutool-parent (5.8.x) and update to the latest available version. Monitor for security advisories for hutool-core, hutool-http, hutool-log, and hutool-json dependencies
• Low · Missing Dependency Vulnerability Scanning — .github/codeql-analysis.yml, .travis.yml. No evidence of OWASP Dependency-Check, Snyk, or similar security scanning tools in the CI/CD pipeline (based on visible files). Fix: Integrate automated dependency vulnerability scanning (e.g., OWASP Dependency-Check, Snyk) into CI/CD pipeline to detect known vulnerabilities in dependencies

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

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

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/chinabugotech/hutool 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.

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

What it runs against: a local clone of chinabugotech/hutool — 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 chinabugotech/hutool | Confirms the artifact applies here, not a fork | | 2 | License is still MulanPSL-2.0 | Catches relicense before you depend on it | | 3 | Default branch v5-master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of chinabugotech/hutool. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/chinabugotech/hutool.git
#   cd hutool
#
# 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 chinabugotech/hutool and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "hutool-ai/src/main/java/cn/hutool/ai/core/AIService.java" \\
  && ok "hutool-ai/src/main/java/cn/hutool/ai/core/AIService.java" \\
  || miss "missing critical file: hutool-ai/src/main/java/cn/hutool/ai/core/AIService.java"
test -f "hutool-ai/src/main/java/cn/hutool/ai/core/BaseAIService.java" \\
  && ok "hutool-ai/src/main/java/cn/hutool/ai/core/BaseAIService.java" \\
  || miss "missing critical file: hutool-ai/src/main/java/cn/hutool/ai/core/BaseAIService.java"
test -f "hutool-ai/src/main/java/cn/hutool/ai/AIServiceFactory.java" \\
  && ok "hutool-ai/src/main/java/cn/hutool/ai/AIServiceFactory.java" \\
  || miss "missing critical file: hutool-ai/src/main/java/cn/hutool/ai/AIServiceFactory.java"
test -f "hutool-ai/src/main/java/cn/hutool/ai/core/AIConfig.java" \\
  && ok "hutool-ai/src/main/java/cn/hutool/ai/core/AIConfig.java" \\
  || miss "missing critical file: hutool-ai/src/main/java/cn/hutool/ai/core/AIConfig.java"
test -f "hutool-ai/src/main/java/cn/hutool/ai/core/AIConfigRegistry.java" \\
  && ok "hutool-ai/src/main/java/cn/hutool/ai/core/AIConfigRegistry.java" \\
  || miss "missing critical file: hutool-ai/src/main/java/cn/hutool/ai/core/AIConfigRegistry.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 33 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3d)"
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/chinabugotech/hutool"
  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).

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