Files
gps-denied-onboard/.cursor/skills/plan/steps/03_component-decomposition.md
T
Oleksandr Bezdieniezhnykh 1f634c2604
ci/woodpecker/push/02-build-push Pipeline failed
Update demo replay validation and testing documentation
- Modified the autodev state to reflect the current testing phase and details of the new `jetson-e2e` tests.
- Enhanced the "How to Test" documentation to provide clearer instructions on the demo replay validation process, including video and tlog alignment steps.
- Updated architectural documentation to include the new demo replay operator flow and its dependencies.
- Documented the removal of deprecated auto-sync features and clarified the operator-facing UI for replay validation.
- Added new entries in the dependencies table for upcoming tasks related to the demo replay flow.

These changes improve clarity and usability for operators and developers working with the demo replay system.
2026-06-20 11:24:43 +03:00

1.6 KiB

Step 3: Component Decomposition

Role: Professional software architect Goal: Decompose the architecture into components with detailed specs Constraints: No code; only names, interfaces, inputs/outputs. Follow SRP strictly.

  1. Identify components from the architecture; think about separation, reusability, and communication patterns
  2. Use blackbox test scenarios from Step 1 to validate component boundaries
  3. If additional components are needed (data preparation, shared helpers), create them
  4. For each component, write a spec using templates/component-spec.md as structure
  5. Generate diagrams:
    • draw.io component diagram showing relations (minimize line intersections, group semantically coherent components, place external users near their components)
    • Mermaid flowchart per main control flow
  6. Components can share and reuse common logic, same for multiple components. Hence for such occurences common-helpers folder is specified.

Self-verification:

  • Each component has a single, clear responsibility
  • No functionality is spread across multiple components
  • All inter-component interfaces are defined (who calls whom, with what)
  • Component dependency graph has no circular dependencies
  • All components from architecture.md are accounted for
  • Every blackbox test scenario can be traced through component interactions

Save action: Write:

  • each component components/[##]_[name]/description.md
  • common helper common-helpers/[##]_helper_[name].md
  • diagrams diagrams/

BLOCKING: Present component list with one-line summaries to user. Do NOT proceed until user confirms.