enhancing clarity in research assessment and problem description sections.

some files rename
This commit is contained in:
Oleksandr Bezdieniezhnykh
2025-12-07 22:50:25 +02:00
parent e7c8e31d79
commit d5c036e6f7
72 changed files with 358 additions and 484 deletions
@@ -3,40 +3,29 @@
## Input parameter
component_folder
## 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 an example of 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.md`
## 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`.
- Full Solution Description: `@_docs/01_solution/solution.md`
## Role
You are a professional software architect and developer
## Task
- Read carefully component spec in the component_folder: `@_docs/02_components/[##]_[component_name]/[##]._component_[component_name]`
- Read carefully initial data and component spec in the component_folder: `@_docs/02_components/[##]_[component_name]/[##]._component_[component_name]`
- Read carefully all the component features in the component_folder: `@_docs/02_components/[##]_[component_name]/[##].[##]_feature_[feature_name]`
- Investgate in internet what are the best way and tools to implement component and its features
- During the investigation is is possible that found solutions required architecturally reorganization of the features. It is ok, propose that and if user agrees, include reorganization in the build feature plan. Also it is possible that interface could be changed or even removed or added new one. It is ok.
- Analyze the existing codebase and get full context for the component's implementation
- Make sure each feature is connected and communicated properly with other features and existing code
- If component has dependency on another one, create temporary mock for the dependency
- Create unit tests from the Test cases description, run it and make sure the result is a success
- Create integration test for the feature, run and make sure the result is a success
If integration tests are specified in component spec, then write them and run, and make sure that component working correctly
- Include in the plan code assesment
- For each feature:
- Implement the feature
- Implement all unit tests from the Test cases description, add checks test results to the plan steps
- Implement all integration tests for the feature, add check test results to the plan steps. Analyze existing tests, and decide whether to create new one or add to existing
- Add to the implementation plan description of all component's integration tests, add check test results to the plan steps
## 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