tool-module-builder

To implement a backend module from a design document without legacy drift, derive the module contract strictly from the architect task, design doc, and test doc, treating them as the single source of truth. This ensures the implementation aligns with the repository architecture and ignores historical code assumptions.

A doc-driven API contract for backend module development converts the task list, design document, and test document into an explicit contract covering paths, permissions, request and response schemas, validation, and error cases. It ensures the module implementation strictly matches documented observable behavior.

Build exactly one backend tool module by deriving its scope from the architect task and implementing it within the repository's separation of layers, including interface, application, and persistence. This approach ensures architecture alignment while strictly limiting development to the allowed module scope.

Yes, you can repair existing backend module tests using an architect task and test document. The process updates or produces module tests so behavior is verifiable against the test document, ensuring both happy paths and documented failures match the expected observable outcomes.

Backend module development requires both a design document and a test document to generate an accurate API contract. These documents, combined with the architect task list, define the request and response schemas, validation rules, and error cases needed for test-driven implementation.

Backend module implementation should ignore historical assumptions to prevent development drift and ensure the codebase matches current architectural intent. By treating provided documents as the source of truth, developers avoid introducing legacy bugs and maintain strict alignment with the updated repository architecture.