organize structure for .roo and for ai in general

rework rulels

.roo/commands/3.05_implement_initial_structure.md

@@ -0,0 +1,73 @@
+# Create Initial Structure
+
+## Initial data:
+ - Problem description: `@_docs/00_problem/problem_description.md`.
+ - Input data: `@_docs/00_problem/input_data`. They are for reference only, yet it is an example of the real data.
+ - Restrictions: `@_docs/00_problem/restrictions.md`.
+ - Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`.
+ - Security approach: `@_docs/00_problem/security_approach.md`.
+ - Full Solution Description: `@_docs/01_solution/solution.md`
+ - Components with Features specifications: `@_docs/02_components`
+  
+## Role
+  You are a professional software architect
+
+## Task
+ - Read carefully all the component specs and features in the components folder: `@_docs/02_components`
+ - Investigate in internet what are the best way and tools to implement components and its features
+ - Make a plan for the creating initial structure:
+   - DTOs
+   - component's interfaces
+   - empty implementations
+   - helpers - empty implementations or interfaces
+ - Add .gitignore appropriate for the project's language/framework
+ - Add .env.example with required environment variables
+ - Configure CI/CD pipeline with full stages:
+   - Build stage
+   - Lint/Static analysis stage
+   - Unit tests stage
+   - Integration tests stage
+   - Security scan stage (SAST/dependency check)
+   - Deploy to staging stage (triggered on merge to stage branch)
+ - Define environment strategy based on `@_docs/00_templates/environment_strategy.md`:
+   - Development environment configuration
+   - Staging environment configuration
+   - Production environment configuration (if applicable)
+ - Add database migration setup if applicable
+ - Add README.md, describe the project by @_docs/01_solution/solution.md
+ - Create a separate folder for the integration tests (not a separate repo)
+ - Configure branch protection rules recommendations
+
+## Example
+ The structure should roughly looks like this:
+  - .gitignore
+  - .env.example
+  - .github/workflows/ (or .gitlab-ci.yml)
+  - api
+  - components
+    - component1_folder
+    - component2_folder
+    - ...
+  - db
+    - migrations/
+  - helpers
+  - models
+  - tests
+    - unit_test1_project1_folder
+    - unit_test2_project2_folder
+    ...
+    - integration_tests_folder
+      - test data
+      - test01_file
+      - test02_file
+      ...
+        
+ Also it is possible that some semantically coherent components (or 1 big component) would be in its own project or project folder
+ Could be common layer or project consisting of all the interfaces (for C# or Java), or each interface in each component's folder (python) - depending on the language common conventions
+
+## Notes
+ - Follow SOLID principles
+ - Follow KISS principle. Dumb code - smart data.
+ - Follow DRY principles, but do not overcomplicate things, if code repeats sometimes, it is ok if that would be simpler
+ - Follow conventions and rules of the project's programming language
+ - Ask as many questions as needed, everything should be clear how to implement each feature