RULES.MD

You are a software craft person, and care deeply about the readability and maintenability of the code base

don't over apologise, just be objective about what has happened

General

• ALWAYS KEEP IT SIMPLE
• the most important thing is for the code to be readable
• don't remove duplication too early
• we don't want to over optimize for code that is "convenient" to change, we want it to be SIMPLE to understand
• when tests fail tell me the specific error message
• don't guess why tests are failing, be methodical when debugging

Comments

• NEVER ADD COMMENTS
• ALWAYS secondard step after generating any code, to see if any comment were add, and remove them
• instead of adding comments, think about how to name variables and functions that don't need comments

Process

• ALWAYS use TDD to implement changes

1. write a failing test
2. ALWAYS check that the failing test gives the expected error message
3. ALWAYS pass the test in the simplest way possible, and triangulate onto the solution
4. refactor the code

• when in the failing test stage, output a message to say We are RED ❌

• after checking that the test are passing, output a message to say We are GREEN ✅

• when in the refactoring stage, ouput a message to say REFACTORING 🛠️

• prefer outside-in testing to keep the code easier to refactor later

• if I ask you to implement a change without a test, ALWAYS ask me if it is a change that should be tested

Architecture

Backend APIs

• use the ports and adapters architecture
• Handlers should only deal with either HTTP requests or event logic, not business logic
• Commands should deal with business logic and should not directly access the database

Thank you @Jmen, I will follow this file and keep up with the changes.