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/oddfar/campus-imaotai 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

• 19 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 1y ago
• ⚠ Concentrated ownership — top contributor handles 72% of 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 oddfar/campus-imaotai repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/oddfar/campus-imaotai.

What it runs against: a local clone of oddfar/campus-imaotai — 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 oddfar/campus-imaotai | 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 ≤ 417 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "oddfar/campus-imaotai(\\.git)?\\b" \\
  && ok "origin remote is oddfar/campus-imaotai" \\
  || miss "origin remote is not oddfar/campus-imaotai (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 "campus-admin/src/main/java/com/oddfar/campus/admin/controller/system/SysLoginController.java" \\
  && ok "campus-admin/src/main/java/com/oddfar/campus/admin/controller/system/SysLoginController.java" \\
  || miss "missing critical file: campus-admin/src/main/java/com/oddfar/campus/admin/controller/system/SysLoginController.java"
test -f "campus-common/src/main/java/com/oddfar/campus/common/config/RedisConfig.java" \\
  && ok "campus-common/src/main/java/com/oddfar/campus/common/config/RedisConfig.java" \\
  || miss "missing critical file: campus-common/src/main/java/com/oddfar/campus/common/config/RedisConfig.java"
test -f "campus-common/src/main/java/com/oddfar/campus/common/core/RedisCache.java" \\
  && ok "campus-common/src/main/java/com/oddfar/campus/common/core/RedisCache.java" \\
  || miss "missing critical file: campus-common/src/main/java/com/oddfar/campus/common/core/RedisCache.java"
test -f "campus-admin/pom.xml" \\
  && ok "campus-admin/pom.xml" \\
  || miss "missing critical file: campus-admin/pom.xml"
test -f "campus-common/src/main/java/com/oddfar/campus/common/domain/model/LoginUser.java" \\
  && ok "campus-common/src/main/java/com/oddfar/campus/common/domain/model/LoginUser.java" \\
  || miss "missing critical file: campus-common/src/main/java/com/oddfar/campus/common/domain/model/LoginUser.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 417 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~387d)"
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/oddfar/campus-imaotai"
  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).

An automated booking system for the iMaotai app (Chinese liquor reservation platform) that schedules daily reservations, selects nearby or high-volume stores, and automates the travel/share workflow. Built on the Campus framework (a custom Java web framework), it combines a Spring Boot backend (campus-admin, campus-framework) with a Vue.js frontend to provide scheduled, multi-user Maotai bottle reservations without manual intervention. Multi-module Maven monorepo: campus-admin handles REST controllers and system management (users, roles, configs, captcha auth), campus-common provides shared annotations and utilities, and campus-framework (parent dependency) supplies the base web framework. Frontend lives in separate Vue.js codebase (446K LOC). Job scheduling (daily reservations) is handled server-side; the UI manages user registration, store selection, and push notifications.

Chinese consumers who want to automate daily Maotai (luxury liquor) reservations without manually checking the app; also developers learning how to build a full-stack automation system combining Java job scheduling, REST APIs, and Vue.js dashboards with multi-user account management.

Actively developed but niche: the project has meaningful GitHub stars and a full CI/CD pipeline (.github/workflows/ contains api.yml, release.yml, web.yml), suggesting recent maintenance. However, the README explicitly warns the project uses 'already obsolete algorithms' and disclaims responsibility, indicating the Maotai app's API likely changes frequently. Not production-ready for long-term stability.

Critical risk: the README states the booking algorithm is 'obsolete,' meaning frequent breakage is expected as Maotai's backend changes. Single-maintainer dependency (oddfar controls the core Campus framework). Codebase appears mature (567K Java LOC) but tight coupling to a third-party app (iMaotai) means external API changes can break core functionality without warning. License appears permissive but project explicitly disclaims all liability.

The repository shows an active CI/CD setup with GitHub Actions workflows for API, web, and release builds, but the README's prominent disclaimer about obsolete algorithms suggests the maintainer is in 'maintenance mode' rather than feature development. No specific open issues or PRs are visible in the provided data, but the project structure and Docker support suggest recent containerization work.

Clone the repository and build with Maven: git clone https://github.com/oddfar/campus-imaotai.git && cd campus-imaotai && mvn clean install. The project uses Maven (pom.xml files present) with Java 8 compilation target. Docker deployment is supported (Dockerfile present); for local dev, start the Spring Boot app from campus-admin module and the Vue.js frontend separately.

Daily commands: Backend: cd campus-admin && mvn spring-boot:run (or via IDE; .run/campus-server.run.xml provides IntelliJ config). Frontend: navigate to the Vue app directory and run npm install && npm run serve. Docker: docker build -f Dockerfile -t campus-imaotai . && docker run -p 8080:8080 campus-imaotai for one-click deployment mentioned in README.

• campus-admin/src/main/java/com/oddfar/campus/admin/controller/system/SysLoginController.java — Authentication entry point for the platform; handles user login and token generation required by all protected endpoints
• campus-common/src/main/java/com/oddfar/campus/common/config/RedisConfig.java — Configures Redis cache layer used for session management, scheduling state, and appointment data persistence
• campus-common/src/main/java/com/oddfar/campus/common/core/RedisCache.java — Core abstraction for all Redis operations; shared by scheduling, appointment, and user management features
• campus-admin/pom.xml — Maven configuration declaring campus-framework and campus-common dependencies; defines build lifecycle for automated appointment system
• campus-common/src/main/java/com/oddfar/campus/common/domain/model/LoginUser.java — User context object passed through entire request chain; essential for multi-user appointment management
• campus-common/src/main/java/com/oddfar/campus/common/constant/CacheConstants.java — Defines Redis key patterns for appointment state, user sessions, and scheduling metadata across the platform
• campus-admin/src/main/java/com/oddfar/campus/admin/config/SwaggerConfig.java — API documentation configuration; essential reference for understanding all available appointment and user management endpoints

Add a New Appointment Configuration Option

1. Add new field to SysConfigEntity (e.g., maxRetries, notificationDelay) with @Column annotation (campus-common/src/main/java/com/oddfar/campus/common/domain/entity/SysConfigEntity.java)
2. Add getter/setter and update toString() to include new field (campus-common/src/main/java/com/oddfar/campus/common/domain/entity/SysConfigEntity.java)
3. Create DB migration script to add column to sys_config table (src/main/resources/db/migration/V{version}__Add_config_column.sql)
4. Add REST endpoint in SysConfigController to GET/PUT the new configuration (campus-admin/src/main/java/com/oddfar/campus/admin/controller/system/SysConfigController.java)
5. Reference the config value in appointment scheduler logic (reads from RedisCache or DB) (campus-framework/src/main/java/com/oddfar/campus/framework/service/AppointmentScheduler.java)

Add a New API Endpoint with Permission Control

1. Create method in appropriate controller class (e.g., SysUserController for user-related endpoint) (campus-admin/src/main/java/com/oddfar/campus/admin/controller/system/SysUserController.java)
2. Annotate method with @ApiResource(name = 'endpoint_name') to declare permission requirement (campus-common/src/main/java/com/oddfar/campus/common/annotation/ApiResource.java)
3. Use @Log annotation to audit the operation (optional but recommended for appointment changes) (campus-common/src/main/java/com/oddfar/campus/common/annotation/Log.java)
4. Add mapping to SysMenuEntity and SysRoleEntity to define which roles can access this endpoint (campus-common/src/main/java/com/oddfar/campus/common/domain/entity/SysMenuEntity.java)

Implement a New Background Job (e.g., Appointment Reminder)

1. Create new @Component service class with @Scheduled annotation to define cron expression (campus-framework/src/main/java/com/oddfar/campus/framework/service/AppointmentReminderService.java)
2. Query user appointments from DB using BaseMapper (inherited from campus-common) (campus-common/src/main/java/com/oddfar/campus/common/core/BaseMapperX.java)
3. Cache job state (last run time, processed IDs) in Redis using RedisCache to avoid duplicate notifications (campus-common/src/main/java/com/oddfar/campus/common/core/RedisCache.java)
4. Retrieve user notification preferences from SysConfigEntity and push via configured channel (campus-common/src/main/java/com/oddfar/campus/common/domain/entity/SysConfigEntity.java)
5. Log job execution in SysOperLogEntity for monitoring and debugging (campus-common/src/main/java/com/oddfar/campus/common/domain/entity/SysOperLogEntity.java)

Add a Custom Exception Type and Error Handler

1. Create new exception class extending ServiceException in exception package (campus-common/src/main/java/com/oddfar/campus/common/exception/ServiceException.java)
2. Add corresponding error code to BizCodeEnum with HTTP status and message template (campus-common/src/main/java/com/oddfar/campus/common/enums/BizCodeEnum.java)
3. Add @ExceptionHandler method in global exception advice to catch and serialize your exception (campus-admin/src/main/java/com/oddfar/campus/admin/exception/GlobalExceptionHandler.java)
4. Throw exception from service/controller with BizCodeEnum code; framework wraps in R() response object (campus-common/src/main/java/com/oddfar/campus/common/domain/R.java)

The README explicitly warns that the booking algorithm is 'obsolete' — this means the iMaotai app API likely changes frequently and core functionality will break unpredictably. No visible environment variable documentation in the file list; check the full README for required configs (API keys, store IDs, notification webhooks, etc.). The Campus framework is a custom, non-standard Spring extension (not Spring Cloud, not a well-known framework), so debugging and debugging familiar Spring patterns may be harder. The project disclaims all liability, including for data loss and legal responsibility, so use only for personal learning. No visible test suite in the file list (no src/test directories shown), which combined with the obsolete algorithm warning suggests low reliability expectations.

• Scheduled Task Automation (Cron/Job Scheduling) — The entire product revolves around scheduling daily reservations automatically; understanding Spring's @Scheduled, Quartz, or custom task runners is essential to modifying when/how often bookings attempt.
• Multi-Tenant / Multi-User Account Management — The feature 'add multiple users' (mentioned in README) requires understanding how to isolate sessions, configs, and reservation state per user; critical for the SysUserController logic.
• API Reverse Engineering & Web Scraping — Since the Maotai algorithm is obsolete, understanding how the project reverse-engineers the iMaotai app's private API (store locations, reservation endpoints, captcha challenges) is vital to diagnosing breakage.
• Geolocation-Based Store Selection — The feature 'classes choice (highest local sales or nearby stores)' requires geospatial queries; understanding how distance is calculated and stores ranked by inventory is core to the reservation logic.
• Message Push Notifications — The README lists 'reservation result message push' as a feature; understanding how the backend notifies users (likely via Android push, SMS, or webhook) is important for the full reservation flow.
• CAPTCHA Solving & Bypass — The presence of CaptchaConfig.java and the Maotai app's authentication barrier means the project includes logic to handle or bypass image/text CAPTCHAs; understanding this is critical for API interactions.

• oddfar/campus — The core web framework that campus-imaotai depends on; understanding this custom Spring wrapper is essential for modifying backend behavior.
• yize8888/maotai — Competing Maotai automation project (mentioned in README as 'related version'); useful for comparing different approaches to the same reservation problem.
• lisongkun/hygge-imaotai — C# port of campus-imaotai; shows how the reservation logic translates to a different ecosystem, useful for understanding core algorithm vs. framework-specific code.
• oddfar/notes — Author's personal knowledge base repo (linked in README); likely contains design rationale, troubleshooting, and API reverse-engineering notes for Maotai.

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 unit tests for campus-common core utilities

The campus-common module lacks test coverage for critical components like RedisCache, BaseMapperX, and LambdaQueryWrapperX. These are foundational utilities used across the entire application. Adding comprehensive unit tests would improve code reliability and serve as documentation for new contributors.

• [ ] Create campus-common/src/test/java directory structure mirroring main source
• [ ] Write tests for RedisCache operations (get, set, delete, expire) in campus-common/src/main/java/com/oddfar/campus/common/core/RedisCache.java
• [ ] Write tests for BaseMapperX CRUD operations in campus-common/src/main/java/com/oddfar/campus/common/core/BaseMapperX.java
• [ ] Add tests for LambdaQueryWrapperX query building in campus-common/src/main/java/com/oddfar/campus/common/core/LambdaQueryWrapperX.java
• [ ] Add test dependency (JUnit 5, Mockito) to campus-common/pom.xml
• [ ] Create GitHub Action workflow to run tests on PR (extend .github/workflows)

Document imaotai-specific API endpoints and algorithms in campus-admin controllers

The README mentions the project uses 'obsolete algorithms' but the campus-admin controllers lack inline documentation or JavaDoc. Adding comprehensive documentation for the SysLoginController, SysConfigController, and imaotai-specific business logic would help new contributors understand the reservation algorithm and system architecture.

• [ ] Add detailed JavaDoc comments to campus-admin/src/main/java/com/oddfar/campus/admin/controller/system/SysLoginController.java explaining authentication flow
• [ ] Add JavaDoc to campus-admin/src/main/java/com/oddfar/campus/admin/controller/system/SysConfigController.java documenting configuration management
• [ ] Create a docs/ALGORITHM.md file explaining the reservation and travel logic with pseudocode
• [ ] Add @ApiOperation and @ApiModelProperty annotations to controller methods for better Swagger documentation
• [ ] Document the time-based scheduling mechanism mentioned in README (自定义时间/随机时间预约)

Add integration tests for multi-user and reservation workflow in new campus-admin-test module

The project supports multiple users and automatic daily reservations, but there are no visible integration tests validating the complete workflow. Creating an integration test suite would catch regressions in the core imaotai functionality (user management, reservation scheduling, travel operations) and increase confidence in Docker deployments.

• [ ] Create campus-admin/src/test/java/com/oddfar/campus/admin/controller/ImaoTaiIntegrationTest.java for end-to-end workflows
• [ ] Write tests for user registration and multi-user management (testing SysUserController)
• [ ] Add tests for reservation scheduling and cancellation workflows
• [ ] Create tests for store selection logic (local store vs. nearby store selection mentioned in features)
• [ ] Add H2 in-memory database configuration for test profile in campus-admin/pom.xml
• [ ] Create @SpringBootTest integration tests that validate the full reservation cycle

• Add unit tests for SysUserController.java — currently no test files visible; writing tests for user CRUD operations would help stabilize the multi-user feature.: Medium: Prevents regressions in user management, a core feature.
• Document the Campus framework dependency in README — the parent pom.xml references com.oddfar.campus/campus but no link or documentation visible; clarify what Campus provides and where to find its source.: Low: Makes onboarding much faster for new contributors unfamiliar with the custom framework.
• Add integration tests for the scheduled daily reservation logic — the job scheduling logic is not visible in the file list but is core to the product; writing tests that mock the iMaotai API would document expected behavior before the algorithm breaks again.: High: Makes it faster to diagnose and fix issues when Maotai's API changes.

• High · Outdated Swagger/Springfox Dependencies — campus-admin/pom.xml. The pom.xml includes springfox-boot-starter without a specified version, relying on parent POM version management. Additionally, swagger-models is manually pinned to version 1.6.2, which is outdated and may contain known security vulnerabilities. Springfox versions prior to 3.0.0 have had multiple CVEs. Fix: Update to the latest stable versions of springfox and swagger-models. Specify explicit versions: springfox-boot-starter >= 3.0.0 and swagger-models >= 1.6.3. Verify no CVEs exist for chosen versions.
• High · Missing Dependency Version Management — campus-admin/pom.xml. The parent POM uses ${revision} placeholder for versioning, but no explicit dependency versions are specified in campus-admin/pom.xml. This can lead to inconsistent library versions and potential security gaps if parent POM is not properly maintained. Fix: Implement explicit version pinning for all dependencies. Use dependency management to lock versions. Regularly audit and update dependencies for security patches.
• High · Potential Automated Bot/Scraping Functionality — Project scope - entire codebase. The project description indicates automatic daily appointment booking for Moutai app (i茅台). This suggests automated interaction with a commercial service, which may violate Terms of Service and bypass legitimate access controls. The code may contain logic to circumvent rate limiting, captcha, or authentication mechanisms. Fix: Review and ensure compliance with the target service's Terms of Service. Implement legitimate API usage patterns. Add rate limiting and respect service restrictions. Consider obtaining proper authorization before automating third-party service interactions.
• Medium · Swagger/API Documentation Exposure — campus-admin/src/main/java/com/oddfar/campus/admin/config/SwaggerConfig.java. Swagger configuration (SwaggerConfig.java) is present without visible access controls. API documentation endpoints may expose sensitive information about application structure, endpoints, and request/response formats that could aid attackers in reconnaissance. Fix: Implement authentication for Swagger/API documentation endpoints in production. Consider disabling Swagger documentation in production builds. Use @ApiResource annotation to restrict sensitive endpoint documentation visibility.
• Medium · Sensitive Data Serialization — campus-common/src/main/java/com/oddfar/campus/common/config/SensitiveSerializer.java. Custom serializers for sensitive data (SensitiveSerializer.java) are present, but implementation details are not visible. There's risk of improper serialization/deserialization of sensitive information in logs, caches, or responses. Fix: Audit SensitiveSerializer implementation to ensure sensitive fields are properly masked. Verify that PII/sensitive data is never logged in full. Implement field-level encryption for sensitive data at rest and in transit.
• Medium · Redis Configuration Without Apparent Security — campus-common/src/main/java/com/oddfar/campus/common/config/RedisConfig.java. Redis configuration is present (RedisConfig.java) but no visible authentication or encryption configuration in the provided pom.xml. Redis instances may be exposed without credentials or TLS. Fix: Configure Redis with strong authentication credentials. Enable TLS/SSL for Redis connections. Use requirepass directive. Consider using Redis Cluster with ACL for production deployments.
• Medium · Potential SQL Injection via BaseMapperX — campus-common/src/main/java/com/oddfar/campus/common/core/BaseMapperX.java and LambdaQueryWrapperX.java. Custom mapper implementation (BaseMapperX.java) and LambdaQueryWrapperX.java suggest custom database query building. Without proper parameterization visibility, there's risk of SQL injection vulnerabilities. Fix: Ensure all database queries use parameterized statements/prepared statements. Audit BaseMapperX and LambdaQueryWrapperX implementations for raw SQL concatenation. Use ORM framework's safe query methods exclusively.
• Medium · Missing Security Headers Configuration — undefined. No visible security headers configuration (HSTS, CSP, X-Frame-Options, etc.) in the provided configuration files. This exposes the 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.