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/ZhongFuCheng3y/austin 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 the board

• Last commit 2mo ago
• 15 active contributors
• Distributed ownership (top contributor 37% of recent commits)
• Apache-2.0 licensed
• Tests present
• ⚠ No CI workflows detected

_{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 ZhongFuCheng3y/austin repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ZhongFuCheng3y/austin.

What it runs against: a local clone of ZhongFuCheng3y/austin — 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 ZhongFuCheng3y/austin | 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 master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 98 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ZhongFuCheng3y/austin(\\.git)?\\b" \\
  && ok "origin remote is ZhongFuCheng3y/austin" \\
  || miss "origin remote is not ZhongFuCheng3y/austin (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "austin-common/src/main/java/com/java3y/austin/common/pipeline/ProcessTemplate.java" \\
  && ok "austin-common/src/main/java/com/java3y/austin/common/pipeline/ProcessTemplate.java" \\
  || miss "missing critical file: austin-common/src/main/java/com/java3y/austin/common/pipeline/ProcessTemplate.java"
test -f "austin-common/src/main/java/com/java3y/austin/common/enums/ChannelType.java" \\
  && ok "austin-common/src/main/java/com/java3y/austin/common/enums/ChannelType.java" \\
  || miss "missing critical file: austin-common/src/main/java/com/java3y/austin/common/enums/ChannelType.java"
test -f "austin-common/src/main/java/com/java3y/austin/common/domain/TaskInfo.java" \\
  && ok "austin-common/src/main/java/com/java3y/austin/common/domain/TaskInfo.java" \\
  || miss "missing critical file: austin-common/src/main/java/com/java3y/austin/common/domain/TaskInfo.java"
test -f "austin-common/src/main/java/com/java3y/austin/common/dto/model/ContentModel.java" \\
  && ok "austin-common/src/main/java/com/java3y/austin/common/dto/model/ContentModel.java" \\
  || miss "missing critical file: austin-common/src/main/java/com/java3y/austin/common/dto/model/ContentModel.java"
test -f "austin-cron/src/main/java/com/java3y/austin/cron/handler/CronTaskHandler.java" \\
  && ok "austin-cron/src/main/java/com/java3y/austin/cron/handler/CronTaskHandler.java" \\
  || miss "missing critical file: austin-cron/src/main/java/com/java3y/austin/cron/handler/CronTaskHandler.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 98 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~68d)"
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/ZhongFuCheng3y/austin"
  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).

Austin is a production-grade message push platform that distributes notifications across 6+ channels: Email, SMS, WeChat Official Account, WeChat Mini Program, Enterprise WeChat, and DingDing. It's a multi-tenant system built on SpringBoot 2.5.6 that handles message deduplication, task recall, and distributed delivery via Kafka/RabbitMQ/RocketMQ through a modular channel abstraction layer. Maven monorepo structure: austin-common/ (shared domain models, enums, constants, DTOs for accounts and content) provides the abstraction layer for all channels. Channel implementations appear distributed across modules (inferred from dto/account/ and dto/model/ hierarchies: SmsAccount, WeChatOfficialAccount, DingDingRobotAccount, etc.), with TaskInfo/AnchorInfo as core domain abstractions. ThreadPoolConstant and message queue integration suggest async processing pipeline.

Platform engineers and backend developers building notification systems for SaaS products, mobile apps, or internal tools who need to manage multi-channel message delivery without integrating each vendor's API separately. Also relevant for teams running on-premise or private cloud infrastructure in Chinese enterprises.

Production-ready and actively maintained. The project has substantial scope (589KB Java code), uses stable Spring/JPA/Redis stack (MySQL 5.7, JDK 8+), includes Docker containerization, and integrates enterprise-grade infrastructure (XXL-Job for scheduling, Apollo/Nacos for config, Prometheus/Grafana for monitoring). Evidence of active use in Chinese tech community (Gitee stars visible), though open issue/PR visibility not provided in this data.

Moderate risks: single maintainer (3y/ZhongFuCheng3y) visible in badges creates continuity risk; tight coupling to Chinese vendor APIs (Alipay, Tencent, YunPian SMS, GeTui push) may limit portability to Western deployments; requires coordination of multiple external services (Kafka, Redis, MySQL, Redis, distributed job scheduler, config center) making local development non-trivial. Breaking changes in vendor APIs could impact multiple channels simultaneously.

Cannot determine from provided data—no recent commit dates, PR list, or issue backlog visible. File list shows comprehensive channel support already implemented (Alipay, DingDing, FeiShu, LinTong SMS, YunPian, Tencent SMS, Enterprise WeChat, WeChat Mini Program/Official Account). Focus appears to be on consolidation of existing channels rather than new feature exploration.

git clone https://github.com/ZhongFuCheng3y/austin.git
cd austin
mvn clean install
mvn spring-boot:run -pl austin-service

Requires: Java 8+, Maven 3.6+, MySQL 5.7+, Redis, Kafka/RabbitMQ/RocketMQ, and configuration via Apollo or Nacos.

Daily commands:

# Requires MySQL, Redis, Kafka running
mvn clean install
mvn spring-boot:run -pl austin-service -Dspring-boot.run.arguments="--server.port=8080"

# Docker alternative (see Dockerfile in root):
docker build -t austin:latest .
docker run -p 8080:8080 --env-file .env austin:latest

• austin-common/src/main/java/com/java3y/austin/common/pipeline/ProcessTemplate.java — Core pipeline abstraction that defines the processing template for all message delivery flows—every new channel integration must implement this
• austin-common/src/main/java/com/java3y/austin/common/enums/ChannelType.java — Central enum defining all supported delivery channels (email, SMS, WeChat, DingDing, etc.)—must be updated when adding new channels
• austin-common/src/main/java/com/java3y/austin/common/domain/TaskInfo.java — Primary data model for message tasks containing all metadata—foundational to all push operations across the system
• austin-common/src/main/java/com/java3y/austin/common/dto/model/ContentModel.java — Base class for channel-specific content models—all message payload formats inherit from this abstraction
• austin-cron/src/main/java/com/java3y/austin/cron/handler/CronTaskHandler.java — Main cron job handler orchestrating scheduled tasks like token refresh and message pending—critical for background operations
• austin-common/src/main/java/com/java3y/austin/common/constant/AustinConstant.java — System-wide constants and configuration values—reference for understanding default behaviors and magic numbers
• austin-cron/src/main/java/com/java3y/austin/cron/xxl/config/XxlJobConfig.java — XXL-Job distributed scheduling configuration—enables scaled message processing across multiple instances

Add Support for a New Messaging Channel

1. Add new channel type to the ChannelType enum (austin-common/src/main/java/com/java3y/austin/common/enums/ChannelType.java)
2. Create a channel-specific Account DTO extending base account model (austin-common/src/main/java/com/java3y/austin/common/dto/account/ (new file: YourChannelAccount.java))
3. Create a channel-specific ContentModel extending ContentModel base class (austin-common/src/main/java/com/java3y/austin/common/dto/model/ (new file: YourChannelContentModel.java))
4. Implement BusinessProcess interface for your channel's delivery logic ((new module or file: YourChannelBusinessProcess.java))
5. Register the new business process in pipeline configuration (austin-common/src/main/java/com/java3y/austin/common/pipeline/ProcessController.java)

Add a New Scheduled Task for Token Refresh or Batch Processing

1. Create new handler extending the pattern used in existing handlers (austin-cron/src/main/java/com/java3y/austin/cron/handler/ (new file: YourTaskHandler.java))
2. Implement the task logic and define execution schedule (austin-cron/src/main/java/com/java3y/austin/cron/service/impl/TaskHandlerImpl.java)
3. Register task in XXL-Job configuration if using distributed scheduling (austin-cron/src/main/java/com/java3y/austin/cron/xxl/config/XxlJobConfig.java)
4. Add constants for your task to constants file (austin-cron/src/main/java/com/java3y/austin/cron/xxl/constants/XxlJobConstant.java)

Add Support for a New SMS Provider

1. Add provider to SmsSupplier enum (austin-common/src/main/java/com/java3y/austin/common/enums/SmsSupplier.java)
2. Create new SmsAccount subclass for the provider (austin-common/src/main/java/com/java3y/austin/common/dto/account/sms/ (new file: YourProviderSmsAccount.java))
3. Implement SMS delivery BusinessProcess with provider API integration ((new file or update: YourProviderSmsProcess.java))
4. Add provider URL constant to SendChanelUrlConstant (austin-common/src/main/java/com/java3y/austin/common/constant/SendChanelUrlConstant.java)

Implement Message Deduplication or Shield Logic

1. Review deduplication type enum for your strategy (austin-common/src/main/java/com/java3y/austin/common/enums/DeduplicationType.java)
2. Review shield type enum for your rules (austin-common/src/main/java/com/java3y/austin/common/enums/ShieldType.java)
3. Create new BusinessProcess to apply deduplication/shield rules in pipeline ((new file: YourDeduplicationProcess.java))
4. Wire into ProcessController to execute before channel-specific handlers (austin-common/src/main/java/com/java3y/austin/common/pipeline/ProcessController.java)

1. Vendor API Credentials: All channel implementations require accounts/credentials configured externally (Apollo/Nacos)—missing any will cause silent failures on specific channels. 2. Database Migrations: MySQL 5.7+ required with specific schema; no Flyway/Liquibase migrations visible in file list, suggesting manual schema setup needed. 3. Distributed Service Dependencies: System requires Redis, Kafka (or RabbitMQ/RocketMQ), XXL-Job, and config center running—cannot be tested in isolation. 4. Chinese Vendor APIs: All SMS providers are Chinese-specific (YunPian, Tencent, LinTong); non-Chinese users will need to swap implementations. 5. ThreadPoolConstant: Thread pool sizes appear configuration-driven; undersized pools will block message distribution at scale.

• Channel Abstraction / Strategy Pattern — Austin abstracts each notification vendor (SMS, WeChat, Email) as a ChannelType with corresponding Account and ContentModel classes—understanding this pattern is essential for adding new vendors or modifying existing channel behavior.
• Message Deduplication (Content-based vs Identifier-based) — DeduplicationType enum controls whether duplicate detection uses message content hash or recipient phone/email—critical for avoiding duplicate user notifications in retry scenarios.
• Distributed Task Scheduling with XXL-Job — Austin delegates message retries and recalls to XXL-Job for distributed scheduling—knowledge of cron expressions, executor groups, and handler routing is needed for task configuration.
• Async Message Queuing (Kafka/RabbitMQ/RocketMQ) for High-Throughput Push — Austin decouples request acceptance from delivery by enqueuing tasks on configurable brokers—understanding producer/consumer patterns and partitioning is essential for tuning throughput.
• Distributed Configuration Management (Apollo/Nacos) — All vendor credentials, thread pools, and feature flags are stored externally in Apollo or Nacos—local development requires mock or test configs to avoid credential exposure.
• Task Recall / Message Withdrawal — RecallTaskInfo and AnchorInfo track message lifecycle for post-delivery revocation (e.g., unsend SMS/emails)—understanding state transitions is needed for editing recall logic.
• Distributed Request Tracing with AnchorInfo — AnchorInfo and SimpleAnchorInfo provide trace IDs and state anchors across async processing stages—essential for debugging multi-step message delivery chains in logs.

• Iterable/iterable-java-sdk — Production Java SDK for multi-channel marketing automation (email, SMS, push)—similar problem space with different vendor integrations and orchestration approach.
• netease-im/NIM_Android_SDK — NetEase IM SDK used by Chinese enterprises for in-app messaging—complementary to Austin's server-side push for client-side message handling.
• alibaba/spring-cloud-alibaba — Alibaba ecosystem libraries for distributed config (Nacos) and service mesh—Austin explicitly integrates Nacos/Apollo for configuration management.
• xuxueli/xxl-job — Distributed job scheduler that Austin relies on for message retry and recall scheduling—critical dependency for understanding task lifecycle.
• YunaiV/ruoyi-vue-pro — Chinese enterprise SaaS template using similar SpringBoot 2.5 + JPA + Redis + distributed job stack—architectural reference for scaling Austin patterns.

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 ChannelType and MessageType enums

The repository has multiple enum classes (ChannelType.java, MessageType.java, SmsSupplier.java, etc.) in austin-common/src/main/java/com/java3y/austin/common/enums/ but no visible test coverage. These enums are critical for message routing and type validation across the entire austin messaging platform. Adding unit tests would ensure enum values remain consistent and catch future refactoring errors early.

• [ ] Create austin-common/src/test/java/com/java3y/austin/common/enums/ directory structure
• [ ] Write ChannelTypeTest.java covering all enum values (Email, SMS, WeChat MiniProgram, DingDing, etc.)
• [ ] Write MessageTypeTest.java with tests for enum initialization and EnumUtil utility methods
• [ ] Add SmsSupplierTest.java to validate SMS supplier enum combinations with different SMS account types
• [ ] Include tests for PowerfulEnum interface implementation across all enum classes

Add unit tests for ProcessTemplate and BusinessProcess pipeline classes

The pipeline pattern implementation in austin-common/src/main/java/com/java3y/austin/common/pipeline/ (ProcessTemplate.java, BusinessProcess.java, ProcessContext.java) is a core architectural component for message processing, but has no visible test coverage. Testing this pipeline is critical to ensure the chain of processing steps works correctly for different channel types and message validation scenarios.

• [ ] Create austin-common/src/test/java/com/java3y/austin/common/pipeline/ directory
• [ ] Write ProcessTemplateTest.java to test template execution flow and handler registration
• [ ] Write ProcessContextTest.java to validate context state management and data passing between pipeline steps
• [ ] Add integration test for typical message flow (e.g., SMS validation → rate limiting → delivery)
• [ ] Test ProcessException handling and error propagation through the pipeline

Add validation utility class with tests for ContentModel DTOs

The repository has 11+ ContentModel classes (EmailContentModel, SmsContentModel, OfficialAccountsContentModel, etc.) in austin-common/src/main/java/com/java3y/austin/common/dto/model/ but no apparent validation framework. Given that austin is a production messaging platform, adding a ContentModelValidator utility with comprehensive tests would prevent invalid messages from being queued and ensure channel-specific requirements are met.

• [ ] Create austin-common/src/main/java/com/java3y/austin/common/util/ContentModelValidator.java with validation rules for each model type
• [ ] Add validation for required fields per channel (e.g., email requires recipient, SMS requires phone format)
• [ ] Create austin-common/src/test/java/com/java3y/austin/common/util/ContentModelValidatorTest.java
• [ ] Write test cases for each ContentModel subclass covering valid/invalid scenarios
• [ ] Integrate validator into existing ContentModel classes via base class or composition

• Add unit tests for SmsContentModel validation—currently no test files visible in common module despite model complexity across TencentSmsAccount, YunPianSmsAccount, LinTongSmsAccount variants.
• Create integration test suite for deduplication logic across DeduplicationType enum values—verify that DeduplicationType.CONTENT_DEDUP vs .PHONE_DEDUP produce expected behavior with TaskInfo.
• Add OpenAPI/Swagger documentation generation for the message push API—common/dto/ classes lack @ApiOperation/@ApiModel annotations, making API contract discovery difficult for frontend teams.

• High · Hardcoded Test Profile in Dockerfile — Dockerfile. The Dockerfile sets a default Spring profile to 'test' via environment variable PARAMS. This exposes test configuration in production deployments and may disable security features, use mock credentials, or expose debug endpoints. Fix: Remove hardcoded test profile from Dockerfile. Use environment variables or config management to set profiles at runtime: ENV PARAMS="" and pass --spring.profiles.active=prod during container startup.
• High · Outdated Java Runtime Base Image — Dockerfile. The Dockerfile uses 'openjdk:8-jre', which is significantly outdated (Java 8 reached end-of-life in 2022). This image contains known vulnerabilities in the JVM and system libraries. Fix: Upgrade to a maintained Java image: 'openjdk:17-jre-slim' or 'eclipse-temurin:17-jre-alpine'. Ensure regular image updates.
• High · Missing ENTRYPOINT Security Hardening — Dockerfile. The Dockerfile uses 'sh -c' which starts a shell process unnecessarily. This increases attack surface and allows shell injection via JAVA_OPTS environment variable. Fix: Use exec form without shell: ENTRYPOINT ["java", "-jar", "austin.jar"] and handle parameters more securely. Validate JAVA_OPTS in startup scripts.
• Medium · Missing Base Image Security Scanning — Dockerfile / CI-CD Configuration. No indication of security scanning or vulnerability scanning (e.g., Trivy, Grype) in the Docker build pipeline. Unknown base image vulnerability status. Fix: Implement container image scanning in CI/CD pipeline. Use minimal base images (alpine) and regularly scan for vulnerabilities.
• Medium · Sensitive Credentials in Multiple Account DTOs — austin-common/src/main/java/com/java3y/austin/common/dto/account/. The codebase contains multiple account credential DTOs (SmsAccount, WeChatOfficialAccount, DingDingRobotAccount, etc.). Risk of credentials being logged, exposed in error messages, or stored in plaintext. Fix: Implement credential encryption at rest. Use Spring Cloud Config, AWS Secrets Manager, or HashiCorp Vault. Ensure credentials are never logged. Mask sensitive fields in toString() methods.
• Medium · Potential SQL Injection via TaskInfo/SimpleTaskInfo — austin-common/src/main/java/com/java3y/austin/common/domain/TaskInfo.java. TaskInfo and SimpleTaskInfo domain objects suggest dynamic query construction. Without visible prepared statement usage in file structure, SQL injection risk exists. Fix: Use parameterized queries/prepared statements exclusively. Implement input validation and sanitization. Use ORM frameworks (JPA/Hibernate) to prevent SQLi.
• Medium · Content Model Classes May Be Vulnerable to XSS — austin-common/src/main/java/com/java3y/austin/common/dto/model/. Multiple ContentModel classes (EmailContentModel, OfficialAccountsContentModel, SmsContentModel) suggest user-generated content handling. Risk of stored/reflected XSS if content is rendered without escaping. Fix: Implement HTML escaping for all user-supplied content. Use templating engines with auto-escaping. Validate and sanitize content at input boundaries.
• Medium · Missing CORS and Security Headers Configuration — austin-web module (not provided in analysis). No visible Spring Security configuration or WebSecurityConfig in provided files. Default configuration likely lacks CORS restrictions and security headers. Fix: Configure Spring Security with appropriate CORS policies, CSRF protection, and HTTP security headers (CSP, X-Frame-Options, X-Content-Type-Options).
• Low · Unvalidated External Service Calls — austin-common/src/main/java/com/java3y/austin/common/constant/. SendChanelUrlConstant suggests direct calls to external services (SMS, WeChat, DingDing, etc.). No visible validation of response signatures or SSL certificate pinning. Fix: undefined

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.