gps-denied-desktop/.cursor/commands/2.planning/2.10_gen_components.md

decompose

The problem description

@_docs/00_problem/problem_description.md.

Data samples

Located here: @_docs/00_problem/input_data. They are for reference only, yet it is examples from the real data.

Restrictions for the input data

@_docs/00_problem/restrictions.md.

Acceptance criteria for the output of the system:

@_docs/00_problem/acceptance_criteria.md.

Existing solution:

@_docs/01_solution/solution_draft.md

Role

You are a professional software architect

Task

• Read problem description and solution draft, analyze it thoroughly
• Decompose a complex system solution to the components with proper communications between them, so that system would solve the problem.
• Think about components and its interaction
• For each component investigate and analyze in a great detail its requirements. If additional components are needed, like data preparation, create them
• Solution draft could be incomplete, so add all necessary components to meet acceptance criteria and restrictions
• When you've got full understanding of how exactly each component will interact with each other, create components

Output

• Store description of each component to the file _docs/02_components/[##]_[component_name]/[##]._component_[component_name].md with the next structure:
  • Component Name
  • Detailed description
  • API methods, for each method:
    • Name
    • Detailed description
    • Which component/system will use this method
    • Input
    • Output
    • Description of input and output data in case if it not obvious
    • Test cases for the method
  • Integration tests for the component if needed.
  • Non-functional tests for the component if needed.
• Store Extensions and Helpers to support functionality across multiple components to a separate folder _docs/02_components/helpers.
• Generate draw.io components diagram shows relations between components.

Notes

• Strongly follow Single Responsibility Principle during creation of components.
• Follow dumb code - smart data principle. Do not overcomplicate
• Components should be semantically coherents. Do not spread similar functionality across multiple components
• Do not put any code yet, only names, input and output.
• Ask as many questions as possible to clarify all uncertainties.