|
| 1 | +# Agent Conventions |
| 2 | + |
| 3 | +## Purpose |
| 4 | + |
| 5 | +This file guides coding agents working in this repository. Keep it operational and project-specific. Use `README.md` for package usage and `docs/developer.md` for local setup details; do not duplicate those walkthroughs here. |
| 6 | + |
| 7 | +## Workflow Tools |
| 8 | + |
| 9 | +- Use `uv` for contributor and agent workflows by default. |
| 10 | +- Use `uv sync` to create or refresh the local environment. |
| 11 | +- Use `uv run ...` for project commands instead of bare `python`, `pip`, or globally installed tooling unless the task explicitly requires it. |
| 12 | +- Use Ruff for Python formatting and linting by default. |
| 13 | + |
| 14 | +## Repo Map |
| 15 | + |
| 16 | +- `wagtail_honeypot/`: package behavior and public implementation. |
| 17 | +- `wagtail_honeypot/models.py`: honeypot settings defaults and form submission logic. |
| 18 | +- `wagtail_honeypot/templatetags/honeypot_tags.py`: template tag context and field names. |
| 19 | +- `wagtail_honeypot/templates/` and `wagtail_honeypot/static/`: rendered markup and browser-side behavior. |
| 20 | +- `wagtail_honeypot/locale/`: translations. |
| 21 | +- `tests/`: unit coverage for models, methods, forms, and template tags. |
| 22 | +- `tests/testapp/`: minimal Wagtail integration site; use it only when a change needs page-level or form-flow coverage. |
| 23 | + |
| 24 | +## Change Conventions |
| 25 | + |
| 26 | +- Put reusable package behavior in `wagtail_honeypot/`, not in `tests/testapp/`. |
| 27 | +- Change `models.py` when adjusting honeypot defaults, settings handling, or form submission decisions. |
| 28 | +- Change `templatetags/honeypot_tags.py` and `templates/tags/honeypot_fields.html` when adjusting rendered field names, context, or markup. |
| 29 | +- Change `static/css/` or `static/js/` only for browser behavior related to hiding or presenting honeypot fields. |
| 30 | +- Update `locale/` only when user-facing strings change. |
| 31 | +- Keep `tests/testapp/` focused on integration behavior; do not treat it as a second implementation surface. |
| 32 | + |
| 33 | +## Compatibility Rules |
| 34 | + |
| 35 | +- Preserve existing `HONEYPOT_*` setting names and behavior unless the task explicitly changes support policy. |
| 36 | +- Avoid unnecessary breaking changes to template tag output, rendered field attributes, or form-processing semantics. |
| 37 | +- Treat the Django and Wagtail support matrix in `tox.ini` as a constraint when making changes. |
| 38 | +- Preserve backwards compatibility across supported versions unless the task explicitly requires otherwise. |
| 39 | + |
| 40 | +## Testing Expectations |
| 41 | + |
| 42 | +- For model or method changes, add or update focused tests in `tests/test_models.py` or `tests/test_methods.py`. |
| 43 | +- For form submission behavior, update `tests/test_form.py` and verify both accepted and ignored submissions. |
| 44 | +- For template tag or rendered field changes, update `tests/test_tags.py` with context and rendered HTML assertions. |
| 45 | +- Use `tests/testapp/` coverage when the change affects Wagtail page behavior or end-to-end form flow. |
| 46 | +- For translation or configuration changes, add focused assertions where practical. |
| 47 | +- Run `make lint` or `uv run ruff check .` for Python style checks. |
| 48 | +- Run `make format` or `uv run ruff format .` when updating Python formatting. |
| 49 | +- Run `make test` or `uv run coverage run manage.py test` for the default suite. |
| 50 | +- Use `make tox` or `uv run tox --skip-missing-interpreters` only when matrix coverage is relevant to the task. |
| 51 | + |
| 52 | +## Documentation Rules |
| 53 | + |
| 54 | +- Update `README.md` when package usage, settings, or integration steps change for users. |
| 55 | +- Update `docs/developer.md` when local development workflow changes. |
| 56 | +- Update `CHANGELOG` under `## Unreleased` for every PR. Keep entries short, flat, and user or contributor facing. |
| 57 | +- Keep `AGENTS.md` concise and directive; do not turn it into a duplicate contributor guide. |
| 58 | + |
| 59 | +## PR Readiness |
| 60 | + |
| 61 | +- Keep the pull request title and body aligned with the current branch scope. |
| 62 | +- Update the PR title whenever the branch scope changes materially and the current title no longer describes the work accurately. |
| 63 | +- Update the PR description whenever behavior, tooling, documentation, or test coverage changes materially from the current summary. |
| 64 | +- The maintained PR body should cover the behavior change, docs or tooling updates, and verification performed. |
| 65 | +- When handling pull request review suggestions that require code changes, commit the fix, push the branch, and update the review reply after the branch reflects the final change set. |
| 66 | +- Treat the PR title, PR summary, and `CHANGELOG` entry as required closing steps before the branch is ready. |
| 67 | + |
| 68 | +## Branch Workflow |
| 69 | + |
| 70 | +- Treat `release` as the repository default branch. |
| 71 | +- Start all new work from `release`; it tracks the latest changes that are not yet released to PyPI. |
| 72 | +- Treat `main` as the release-preparation branch, not the starting point for routine feature or fix work. |
| 73 | +- Target merge requests at `release`. |
| 74 | + |
| 75 | +## Change Boundaries |
| 76 | + |
| 77 | +- Do not change version metadata, supported-version claims, or migrations unless the task requires it. |
| 78 | +- Keep commit scope narrow and tied to one behavior change. |
| 79 | +- Prefer minimal edits that preserve the package's existing API and documented behavior. |
0 commit comments