mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-06-23 09:21:13 +00:00
Oleksandr Bezdieniezhnykh
1f634c2604
ci/woodpecker/push/02-build-push Pipeline failed
- 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.
39 lines
1.7 KiB
Markdown
39 lines
1.7 KiB
Markdown
## Step 4: Architecture Review & Risk Assessment
|
|
|
|
**Role**: Professional software architect and analyst
|
|
**Goal**: Validate all artifacts for consistency, then identify and mitigate risks
|
|
**Constraints**: This is a review step — fix problems found, do not add new features
|
|
|
|
### 4a. Evaluator Pass (re-read ALL artifacts)
|
|
|
|
Review checklist:
|
|
- [ ] All components follow Single Responsibility Principle
|
|
- [ ] All components follow dumb code / smart data principle
|
|
- [ ] Inter-component interfaces are consistent (caller's output matches callee's input)
|
|
- [ ] No circular dependencies in the dependency graph
|
|
- [ ] No missing interactions between components
|
|
- [ ] No over-engineering — is there a simpler decomposition?
|
|
- [ ] Security considerations addressed in component design
|
|
- [ ] Performance bottlenecks identified
|
|
- [ ] API contracts are consistent across components
|
|
|
|
Fix any issues found before proceeding to risk identification.
|
|
|
|
### 4b. Risk Identification
|
|
|
|
1. Identify technical and project risks
|
|
2. Assess probability and impact using `templates/risk-register.md`
|
|
3. Define mitigation strategies
|
|
4. Apply mitigations to architecture, flows, and component documents where applicable
|
|
|
|
**Self-verification**:
|
|
- [ ] Every High/Critical risk has a concrete mitigation strategy
|
|
- [ ] Mitigations are reflected in the relevant component or architecture docs
|
|
- [ ] No new risks introduced by the mitigations themselves
|
|
|
|
**Save action**: Write `risk_mitigations.md`
|
|
|
|
**BLOCKING**: Present risk summary to user. Ask whether assessment is sufficient.
|
|
|
|
**Iterative**: If user requests another round, repeat Step 4 and write `risk_mitigations_##.md` (## as sequence number). Continue until user confirms.
|