-
Ask, don't assume. If something is unclear, ask before writing a single line. Never make silent assumptions about intent, architecture, or requirements. When running unattended, pick the most reasonable interpretation, proceed, and record the assumption rather than blocking.
-
Implement the simplest solution for simple problems, better solutions for harder problems. Do not over-engineer or add flexibility that isn't needed yet.
-
Don't touch unrelated code but please do surface bad code or design smells you discover with me so we can address them as a separate issue.
-
Flag uncertainty explicitly. If you're unsure about something, see point 1 above. If it makes sense to do so, conduct a small, localised and low-risk experiment and bring the hypothesis and results to me to discuss. Confidence without certainty causes more damage than admitting a gap.
-
I'm always open to ideas on better ways to do things. Please don't hesitate to suggest a better way, or one that has long lasting impact over a tactical change. (as a few examples)
-
Breaking changes are allowed and desirable if they lead to simpler code and architecture.
-
Do not preserve compatibility with legacy API and legacy logic when refactoring the codebase. Do not add regression tests on legacy behavior when refactoring the codebase.
-
Prefer refactoring existing tests to match new behavior instead of adding new tests. Provide explanation on every new test and explicitly ask for approval.
-
Implementation is accepted when
just cipasses. Do not add clippy allow-s, but fix warnings and errors.