Improve system prompt (OOP principles, etc.)

.serena/project.yml

@@ -71,21 +71,31 @@ included_optional_tools: []
 # initial prompt for the project. It will always be given to the LLM upon activating the project
 # (contrary to the memories, which are loaded on demand).
 initial_prompt: |
-  IMPORTANT: You use an idiomatic, object-oriented style.
-  In particular, this implies that, for any non-trivial interfaces, you use interfaces that expect explicitly typed abstractions
-  rather than mere functions (i.e. use the strategy pattern, for example).
-  You avoid the use of low-level data structures in all cases where an object-oriented abstraction would be more appropriate.
-  For simple data storage, you use dataclasses instead of dictionaries or tuples.
+  IMPORTANT: You use an idiomatic, object-oriented style (Java-esque principles, Pythonic syntax and constructs). 
 
-  You structure function implementations into functional blocks that are separated by blank lines.
-  Atop each functional block, you write an elliptical phrase (starting with lower-case letter) that describes the purpose of the 
-  block in a concise manner.
+  Design:
+  * You keep each concern in exactly one home. 
+    A mechanism whose parts are only correct in combination is implemented as a single component/class, and its parts are private to it;
+    expose a minimal public surface. Java-like encapsulation: If helper functions and constants are only used by one abstraction, 
+    make them internal to the respective class.
+  * You enforce invariants through structure and visibility; interfaces should not permit states the design forbids.
+  * For any non-trivial interfaces, you use interfaces that expect explicitly typed abstractions
+    rather than mere functions (i.e. use the strategy pattern, for example).
+    You avoid the use of low-level data structures in all cases where an object-oriented abstraction would be more appropriate.
+    For simple data storage, you use dataclasses instead of dictionaries or tuples.
 
-  Docstrings: You consistently use reStructuredText.
+  Testing:
+  You test externally observable behavior and guarantees, never implementation structure.
 
-  Comments:
-  When describing parameters, methods/functions and classes, you use a precise style, where the initial (elliptical) phrase
-  clearly defines *what* it is. Any details then follow in subsequent sentences.
+  Docstrings & Comments:
+  * You consistently use reStructuredText.
+  * You structure function implementations into functional blocks that are separated by blank lines.
+    Atop each functional block, you write an elliptical phrase (starting with lower-case letter) that describes the purpose of the 
+    block in a concise manner.
+  * When describing parameters, methods/functions and classes, you use a precise style, where the initial (elliptical) phrase
+    clearly defines *what* it is. Any details then follow in subsequent sentences.
+  * Each piece of information appears exactly once, at the element that owns it: callers do not
+    explain callees' internals, and callees do not describe their callers.
 
   Pull requests:
   Read `mem:creating_pull_requests` when asked to participate in the creation of a pull request.