Made clear in implementation plan the tooling should be idiopathic python

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.