Review Workflow#
DeePTB has more code paths than the current maintainer capacity can review manually from scratch every time. The review workflow should make AI useful, CI mechanically strict, and human review focused on design and scientific risk.
PR Review Pipeline#
Use three layers:
AI-assisted review identifies likely risks, missing tests, and compatibility concerns.
CI catches mechanical failures, regressions, and smoke-test breakage.
Human maintainer review decides whether the remaining risk is acceptable.
AI review is advisory. It should not replace maintainer judgment, especially for physics semantics and numerical behavior.
For the step-by-step PR procedure, use docs/maintenance/maintainer_sop.md.
Minimal AI Review Roles#
Before running prompts, generate a file-based review plan when reviewing a local branch:
git diff --name-only main...HEAD | python scripts/ci/pr_review_plan.py --stdin
The same script can run in GitHub Actions as an advisory job summary. Treat it as a checklist generator, not as an automated approval.
Start with two roles before adding more automation. Use the prompt text in docs/maintenance/ai_review_prompts.md so manual review and future automation follow the same rules.
Maintainer Review
correctness bugs
regressions against main
public API, config, checkpoint, and dataset compatibility
high-risk modules touched
merge recommendation
Test Gap Review
changed behavior without tests
examples or CLI paths that should be smoke-tested
regression tests needed for scientific behavior
These two prompts are the recommended minimum AI review set. Future CodeRabbit, OpenClaw, Hermes, or GitHub Action automation should reuse them rather than creating a separate review standard.
Maintainer Checklist#
PR scope is clear and not mixed with unrelated cleanup.
High-risk files were reviewed using
docs/maintenance/risk_map.md.Main branch behavior is preserved unless explicitly changed.
Public API, CLI, docs, examples, and config schema are consistent.
Tests cover the changed behavior.
AI review findings were handled or explicitly waived.
CI passed.
Remaining risks are recorded in the PR merge decision.
Repository Hygiene Check#
The repository hygiene check is a low-noise CI guard for hard errors only. It verifies that example JSON files parse, required maintenance documents exist, and the maintenance docs remain linked from the docs index.
Run it locally with:
python scripts/ci/check_repository_hygiene.py
This check does not replace full unit tests, Sphinx docs builds, notebook validation, or human review.
Test Layering#
Use pytest markers to match test effort to PR risk:
uv run pytest ./dptb/tests -m smoke
uv run pytest ./dptb/tests -m regression
uv run pytest ./dptb/tests -m "not slow"
uv run pytest ./dptb/tests
See docs/maintenance/test_strategy.md for marker definitions and review guidance.
Merge Decision Template#
Use the PR template’s Merge Decision section before merging:
Recommendation: merge after CI passes.
Reason:
- Core workflow is covered by regression tests.
- AI review concerns were resolved.
- No unresolved compatibility issues.
Remaining risks:
- Real MKL/Pardiso path requires Linux + MKL environment and is not covered in this PR.