From e4ee659ef3ce5a1e4b56fdc99d12d323fee35be3 Mon Sep 17 00:00:00 2001 From: Jeffrey Phillips Freeman Date: Wed, 5 Nov 2025 16:14:01 -0500 Subject: [PATCH] Made clear in implementation plan the tooling should be idiopathic python --- implementation_plan.md | 1 + 1 file changed, 1 insertion(+) diff --git a/implementation_plan.md b/implementation_plan.md index 396469c8f..fb5475347 100644 --- a/implementation_plan.md +++ b/implementation_plan.md @@ -8,6 +8,7 @@ - **Living document protocol**: After finishing each checklist item (and its testing sub-items), immediately append every decision, discovery, open question, or deviation to this document under the matching Notes section. This plan remains the authoritative record. - **Single documentation surface**: Do not create auxiliary notes elsewhere unless explicitly required. All architectural updates, troubleshooting outcomes, and contextual knowledge must flow back into this markdown file. - **Sequential discipline**: Always begin with the first unchecked item in the checklist. Do not progress until that item, its documentation update, and its testing sub-items (including any spawned remediation tasks) are fully resolved. +- **USE MODERN PYTHON TOOLING**: This is a cutting-edge Python project that must use modern build tools and workflows. NO Makefiles, NO legacy approaches. Use Hatch/PDM/Poetry for project management, nox for task automation, pyproject.toml for all configuration. Commands should be Python-native (e.g., `hatch run test`, `nox -s lint`) not shell scripts or make targets. All tooling must be from the current Python ecosystem (2024+). When current tooling (such as "Behave" and "Robot Framework") can be used to solve a problem, use them rather than adding new tooling, keep it simple. - **Unit + integration testing mandate**: For every coding task, author or update both unit and integration tests, run them, and achieve passing results before marking the task complete. Testing subtasks are non-optional. - **Behavior-driven testing stack**: Use Behave feature suites under `features/` for unit-level and scenario tests and Robot Framework suites under `robot/` for integration and end-to-end coverage. Keep both synchronized with the code under test and document all updates in this plan. - **Do not use pytest style unit tests**: Under no circumstances should you write pytest styled unit tests, all unit tests should be Behave based (as noted in the last bullet point), which follows the Cucumber/Gherkin style of tests as seen under `features/`, this is why there is intentionally no `tests/` folder.