- This repository is
zzupy, a Python library that wraps Zhengzhou University mobile-app and web services. - Main public modules live under
zzupy/app,zzupy/web, andzzupy/aio. - Sync and async clients intentionally mirror each other. When changing behavior in
zzupy/apporzzupy/web, check whether the same change is also needed in the correspondingzzupy/aiomodule. - Data contracts are centralized in
zzupy/model. Shared helpers live inzzupy/utils.py, and project-specific exceptions live inzzupy/exception.py.
- Python packaging is defined in
pyproject.toml; the build backend is Hatchling. - Use
uvfor environment management, installs, and project commands. - Common commands:
uv sync --extra develop,docsuv buildruff format zzupyruff check zzupyty check zzupy
- There is currently no dedicated test suite in
tests/; for most changes, at least run a build and a lightweight syntax check. - Docs are built with MkDocs Material. If you change public APIs or user workflows, update the relevant docs in
docs/and verify withuv sync --extra docs && uv run mkdocs buildwhen practical.
- Follow the existing Chinese-first documentation style for docstrings, logs, and user-facing error messages unless a file already uses another style.
- Keep implementations simple and explicit. This codebase prefers straightforward
httpxrequest flows over heavy abstraction. - Reuse the existing exception types from
zzupy/exception.pyinstead of raising generic exceptions for domain failures. - Preserve the current logging style with
loguru, including request/response diagnostics where a module already uses them. - Keep type hints modern and consistent with the codebase, including
| Noneunions and Pydantic v2 APIs such asmodel_validate. - Put schema parsing and normalization in models or small helpers when possible; avoid duplicating response-shape handling across clients.
- Most clients wrap reverse-engineered upstream services. Avoid speculative refactors that might change request headers, params, cookie handling, or encryption details unless required.
- Preserve login state behavior, token refresh flows, and context-manager semantics (
__enter__,__exit__,close,logout) when modifying clients. - When adding a new campus service, prefer matching the existing layout: client in
zzupy/apporzzupy/web, async counterpart inzzupy/aio, models inzzupy/modelif needed, and exports in the relevant__init__.py. - If a response is validated with Pydantic in the sync client, keep the async client aligned.
- Public surface changes should usually update
README.mdand the relevant usage docs underdocs/usage/. - Keep repository-level AI/discovery metadata in sync when relevant:
llms.txtfor project guidance,context7.jsonfor Context7 ownership metadata, and the README badges/links for external documentation indexes such as DeepWiki. - API reference pages are generated from code, so exported symbols and docstrings matter.
- Prefer small, targeted documentation commits when changing repository metadata or discovery files so ownership/verification changes stay easy to audit.
- Versioning and release automation are handled through
python-semantic-release; do not manually change release flow unless the task explicitly requires it.
- The working tree may contain unrelated user changes or untracked files. Do not remove or overwrite them unless the user explicitly asks.
- In particular, check
git statusbefore broad edits, and limit changes to files relevant to the task.