mirror of
https://github.com/azaion/loader.git
synced 2026-04-22 22:46:32 +00:00
Oleksandr Bezdieniezhnykh
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.
|