|
| 1 | +# Agent Instructions for `cs_dynamicpages` |
| 2 | + |
| 3 | +This document contains the guidelines, commands, and code style rules for AI coding agents operating in this repository. The `cs_dynamicpages` project is a Plone 6 add-on providing dynamic page content types and behaviors. |
| 4 | + |
| 5 | +## 1. Build, Lint, and Test Commands |
| 6 | + |
| 7 | +This project uses `make` as the primary task runner, backed by `uv` for Python environment management and `hatchling` as the build system. |
| 8 | + |
| 9 | +### Installation and Running |
| 10 | +- **Install the project**: |
| 11 | + ```bash |
| 12 | + make install |
| 13 | + ``` |
| 14 | + *(Always recommend `make install` to users. It handles all dependencies, `uv venv`, and setup. NEVER recommend using `pip install` or `uv pip` directly.)* |
| 15 | +- **Start the Plone instance**: |
| 16 | + ```bash |
| 17 | + make start |
| 18 | + ``` |
| 19 | +- **Clean the environment** (without removing data): `make clean` |
| 20 | +- **Create a new site**: `make create-site` |
| 21 | + |
| 22 | +### Linting and Formatting |
| 23 | +Code is checked and formatted using `ruff` (Python), `zpretty` (XML/ZCML), and `pyroma`. |
| 24 | +- **Format code**: `make format` (Fixes `ruff` issues, runs `ruff format`, and runs `zpretty -i src`). |
| 25 | +- **Lint code**: `make lint` (Runs `ruff check`, `pyroma`, `check-python-versions`, and `zpretty --check`). |
| 26 | +- **Check and format**: `make check` (Runs both format and lint). |
| 27 | + |
| 28 | +### Testing |
| 29 | +Tests are written using `pytest` and `plone.app.testing`. |
| 30 | +- **Run all tests**: |
| 31 | + ```bash |
| 32 | + make test |
| 33 | + ``` |
| 34 | +- **Run tests with coverage**: `make test-coverage` |
| 35 | +- **Run a single test file**: |
| 36 | + ```bash |
| 37 | + ./.venv/bin/pytest src/cs_dynamicpages/tests/test_ct_dynamic_page_folder.py |
| 38 | + ``` |
| 39 | +- **Run a specific test method/class**: |
| 40 | + ```bash |
| 41 | + ./.venv/bin/pytest src/cs_dynamicpages/tests/test_ct_dynamic_page_folder.py::DynamicPageFolderIntegrationTest::test_ct_dynamic_page_folder_adding |
| 42 | + ``` |
| 43 | + |
| 44 | +--- |
| 45 | + |
| 46 | +## 2. Code Style & Guidelines |
| 47 | + |
| 48 | +### Python Formatting & Imports |
| 49 | +- **Line Length**: 88 characters (configured in `pyproject.toml`). |
| 50 | +- **Python Version**: Target Python 3.10 (`>=3.10,<3.14`). |
| 51 | +- **Imports**: Formatted using `ruff`'s `isort` rules. |
| 52 | + - Case-insensitive sorting. |
| 53 | + - Force single-line imports (`from X import Y` on separate lines for each `Y`). |
| 54 | + - No sections (all imports sorted alphabetically regardless of third-party/stdlib). |
| 55 | + - 2 blank lines after imports, 1 blank line between types. |
| 56 | +- **Exceptions**: Ignore `E731` (DoNotAssignLambda). Use `# noqa` only when absolutely necessary and document why. |
| 57 | + |
| 58 | +### Naming Conventions |
| 59 | +- **Classes**: `PascalCase` (e.g., `DynamicPageFolder`). |
| 60 | +- **Interfaces**: Prefix with `I` and use `PascalCase` (e.g., `IDynamicPageFolder`). |
| 61 | +- **Methods, Variables, and Functions**: `snake_case` (e.g., `dynamic_page_folder_id`). |
| 62 | +- **Constants**: `UPPER_SNAKE_CASE` (e.g., `TEST_USER_ID`). |
| 63 | +- **Filenames**: `snake_case` for Python and XML files (except specific Zope configurations like `configure.zcml` or specific profiles like `Plone_Site.xml` which follow Plone's exact casing). |
| 64 | + |
| 65 | +### Types & Schema |
| 66 | +- Define Dexterity schemas using `plone.supermodel.model.Schema`. |
| 67 | +- Apply `@implementer(IYourInterface)` to your content type classes. |
| 68 | +- Explicitly subclass `Container` or `Item` from `plone.dexterity.content`. |
| 69 | +- Avoid unnecessary types annotations if Zope schemas already enforce types (`zope.schema`). |
| 70 | + |
| 71 | +### Error Handling |
| 72 | +- Use standard Python exceptions or `plone.api.exc` (like `InvalidParameterError`) when using `plone.api`. |
| 73 | +- Do not silently `except Exception: pass`. Always log or handle exceptions explicitly. |
| 74 | +- Return explicit HTTP error codes where applicable in REST API endpoints. |
| 75 | + |
| 76 | +### XML, ZCML, and PT |
| 77 | +- **XML/ZCML**: Keep it strictly formatted with `zpretty`. Indent with 2 spaces. |
| 78 | +- **Page Templates (PT)**: Ensure they are properly formed HTML/XML. Keep logic in the python views, not in the templates. |
| 79 | + |
| 80 | +--- |
| 81 | + |
| 82 | +## 3. Plone-Specific Documentation and Rules |
| 83 | + |
| 84 | +These rules are strictly enforced for AI agents interacting with this Plone repository: |
| 85 | + |
| 86 | +1. **Documentation First** |
| 87 | + - Before EVERY answer say: "Let me check the official documentation." |
| 88 | + - Before ANY command or code, search for official Plone 6 examples. |
| 89 | + - FORBIDDEN phrases: "Let me try...", "I think...", "It should be..." |
| 90 | + - REQUIRED phrases: "According to the docs...", "The documentation shows..." |
| 91 | + - If no docs are found, EXPLICITLY STATE: "I cannot find official documentation for this." Trial and error MUST be labeled: "This requires trial and error - not documented." |
| 92 | + |
| 93 | +2. **Terminal Commands** |
| 94 | + - Provide ONE step at a time. |
| 95 | + - WAIT for confirmation before moving to the next step. |
| 96 | + - Include the full command with all parameters. |
| 97 | + - ALWAYS recommend using `make` commands (`make install`, `make start`). NEVER recommend `pip install`, `uv add` or `uv pip` directly. |
| 98 | + |
| 99 | +3. **No Shortcuts or Hacks** |
| 100 | + - Always use official Plone APIs (`plone.api`, `plone.restapi`). |
| 101 | + - Follow framework best practices. No temporary workarounds. |
| 102 | + - Maintain security: Always use JWT tokens (`Authorization: Bearer <token>`) for authentication, never basic auth or embedded credentials. |
| 103 | + |
| 104 | +4. **Enterprise Standards** |
| 105 | + - Maintain scalable and upgradable architecture. |
| 106 | + - Document WHY changes are made via inline comments, not just WHAT. |
| 107 | + - When modifying README.md or docs, ALWAYS use emojis in section titles for a friendly tone. |
| 108 | + - NEVER edit the "Generated using" cookieplone paragraph in docs. |
| 109 | + - In README, review the code if necessary to explain features correctly (e.g. use `- Register a behavior providing additional fields representing contact information` instead of just `- Behavior`). |
| 110 | + |
| 111 | +5. **Internationalization (i18n)** |
| 112 | + - All UI strings MUST be translatable. |
| 113 | + - Use `cs_dynamicpages` as the i18n domain. |
| 114 | + - Example: `_(u"My string")` imported from the project's MessageFactory. |
| 115 | + - Run `make i18n` to update `.pot` and `.po` files. |
| 116 | + |
| 117 | +6. **Loop Detection & Uncertainty** |
| 118 | + - If repeating the same pattern, STOP and state: "We are in a loop, need different approach." |
| 119 | + - NEVER say "this will work" unless proven. Acknowledge uncertainty explicitly: "Let's see if this works." |
| 120 | + - Never say "you're frustrated", "you're concerned", etc. Present facts only. |
| 121 | + |
| 122 | +7. **The Fun Factor & Tone** |
| 123 | + - Keep interactions positive, engaging, and collaborative. |
| 124 | + - Provide genuine encouragement but avoid fake/over-the-top praise (e.g., no "OMG AMAZING!!!"). |
| 125 | + - Acknowledge good ideas and creative solutions. |
| 126 | + |
| 127 | +8. **Definition of Success** |
| 128 | + - Success is ONLY a fully functional, tested result. |
| 129 | + - Never claim success for partial or broken implementations. |
0 commit comments