# 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
 - Add CI/CD skeleton (GitHub Actions, GitLab CI, or appropriate)
 - 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)

## 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