Update README.md

README.md

@@ -48,7 +48,7 @@ Please avoid using Qt Design Studio version 4.3 (which utilizes Qt 6.6) due to a
 
 Qleany's primary goal is to automate the generation of a structured project environment for C++/Qt6 applications. This is achieved by interpreting a simple manifest file, named `qleany.yaml`, located at the root of the project. The framework generates a comprehensive structure including folders, CMakeLists.txt, and more than essential C++ files: it will generate whole libraries adapted to your needs. The generated projects support both QWidget and QML GUIs or a combination of both. Upon initial generation, the projects are immediately compilable, requiring developers only to design GUIs and implement custom use cases.
 
-The framework acknowledges the repetitive nature of file creation in Clean Architecture and addresses this by automating the generation of similar files. Tha simplest of the examples in Qleany have 500+ files in 170+ folders, all generated by this tool. 
+The framework acknowledges the repetitive nature of file creation in Clean Architecture and addresses this by automating the generation of similar files. Tha simplest of the examples in Qleany have 500+ files in 170+ folders, all generated by this tool. So, Sleany generator id doing some heavy lifting, but some places will have to be polished by you.
 
 Additional features include:
 
@@ -103,7 +103,7 @@ Libraries and their respective functionalities are organized as follows:
 
 - **Presenter**: Maintains Qt models and representations of unique entities (referred to as `Singles`), enhancing their integration and usage within the GUI.
 
-- **UI**: The structure allows the simultaneous use of different fronts, each in its own binary. QML and QWidgets UIs can coexist without any conflict. Same for a CLI, an API ... All these fronts will use the same models and interactors. You can have a single main.cpp file for all fronts, or one for each front. It's up to you. Qleany will only generate one for each front.
+- **UI**: The structure allows the simultaneous use of different fronts, each in its own binary. QML and QWidgets UIs can coexist without any conflict. Same for a CLI, an API ... All these fronts will use the same models and interactors. You can have a single main.cpp file for all fronts, or one for each front. It's up to you. Qleany will only generate one for each front. 
 
 Another related point:
 
@@ -247,6 +247,17 @@ You can add custom commands and queries for each feature in the `application.fea
 When you take into account the classes offered by the Qleany library, `persistence` iis actually composed by a `repository` part and a `database`part, respectively situated in the "Interface Adapters" layer and in the "Frameworks & Drivers" layer of the Clean Architecture circle diagram.
 
 `database` classes are represented by `InterfaceDatabaseTableGroup` and `InterfaceDatabaseContext` interfaces. If the SQLite database management classes provided by Qleany are not enough for your needs, you can implement your own classes and swap the provided ones with yours.
+
+### Quick rules and troubleshooting 
+
+- To allow smooth generation of a list model or single, allow generation of the entire CRUD of the targeted entity in its own feature. If the list is "in_relation_of" another entity, apply this rule to this other entity too. 
+- For read-only single and list models, only "get" and "get_all" CRUD functions are needed.
+- In a feature, don't mix entities in DTO's entity_mappable_with and CRUD's entity_mappable_with.
+- Respect the case for names. It's very often in pascal case. Ex: PascalCase. Only field names are in camel case ( camelCase ). 
+- Use "qleany check" deliberately
+
+And lastly, if you think that there is a strange behavior, you only have to create an issue and join the qleany.yaml
+
 
 ## Qleany GUI