gps-denied-onboard/.cursor/commands/3.implementation/3.05_implement_initial_structure.md

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