Detailed Design (DLD) Review
Review Detailed Design documents for implementation readiness and technical completeness.Command
Description
Performs comprehensive review of Detailed Design documents to ensure all technical details are specified and the design is ready for implementation. This is the final gate before coding begins.Arguments
- Project ID or DLD path: Project identifier or path to DLD document (e.g., ‘001’, ‘vendors/acme/dld-v1.md’)
When to Use
- After HLD approval
- Before implementation begins
- During detailed design review gates
- For vendor deliverable validation
- Before code development approval
Required Context
- HLD Review (ARC--HLDR-.md) - MANDATORY (DLD follows HLD)
- Architecture Principles (ARC-000-PRIN-*.md) - MANDATORY
- Requirements (ARC--REQ-.md) - MANDATORY
- Data Model (ARC--DATA-.md) - Recommended
- Risk Register (ARC--RISK-.md) - Recommended
Prerequisites
HLD Approval Required
- ✅ HLD must be approved before DLD review
- ✅ All HLD conditions must be addressed
- ❌ No new architectural changes (requires HLD re-review)
Review Criteria
A. Component Design
For each component/service:- Interface definition: APIs, events, messages
- Data structures: Request/response schemas, DTOs
- Business logic: Algorithms and workflows
- Error handling: Exception handling strategy
- Dependencies: External services, libraries
B. API Design
- API specifications: OpenAPI/Swagger docs?
- Endpoint design: RESTful conventions?
- Request validation: Input validation rules?
- Response formats: JSON schemas, error responses?
- Authentication: Auth flows, token formats?
- Rate limiting: Throttling strategy?
- Versioning: API versioning strategy?
C. Data Model
- Database schema: ERD provided?
- Relationships: Foreign keys, indexes, constraints?
- Data types: Appropriate types?
- Normalization: Proper normalization?
- Migrations: Schema migration strategy?
- Partitioning: Sharding if needed?
- Archival: Data retention approach?
D. Security Implementation
- Authentication: OAuth flows, JWT structure?
- Authorization: RBAC/ABAC model, permissions?
- Encryption: Algorithms (AES-256), key management?
- Secrets management: Vault, AWS Secrets Manager?
- Input sanitization: XSS, SQL injection prevention?
- Audit logging: What gets logged? Retention?
- Compliance mapping: Controls to requirements?
E. Integration Design
- Integration patterns: Sync/async? REST/gRPC?
- Error handling: Retry logic, circuit breakers?
- Data transformation: Mapping between systems?
- API contracts: Contract testing?
- Service discovery: How services find each other?
- Message formats: Event schemas?
F. Performance Design
- Caching strategy: What, TTL, invalidation?
- Database optimization: Indexes, queries?
- Connection pooling: Pool sizes, timeouts?
- Async processing: Background jobs, queues?
- Batch processing: Batch sizes, scheduling?
- Load testing plan: Performance test scenarios?
G. Operational Design
- Monitoring: Metrics, dashboards, alerts?
- Logging: Log levels, structured logging?
- Tracing: Distributed tracing (Jaeger, X-Ray)?
- Health checks: Liveness/readiness probes?
- Configuration: Config management?
- Deployment: CI/CD pipeline, deployment strategy?
H. Testing Strategy
- Unit testing: Coverage targets, frameworks?
- Integration testing: Test scenarios?
- Contract testing: API contract tests?
- Performance testing: Load/stress tests?
- Security testing: SAST/DAST tools, pentesting?
- UAT approach: User acceptance criteria?
Implementation Readiness
Critical questions:- ✅ Can developers start coding immediately?
- ✅ Are all technical ambiguities resolved?
- ✅ Are all dependencies identified?
- ✅ Is the test strategy comprehensive?
- ✅ Are deployment procedures clear?
Review Output
Executive Summary
Status:- ✅ APPROVED
- ⚠️ APPROVED WITH CONDITIONS
- ❌ REJECTED
- 🔄 NEEDS HLD RE-REVIEW
Detailed Findings
- Component design assessment
- API design review
- Data model evaluation
- Security implementation review
- Integration review
- Performance considerations
- Operational readiness
- Testing strategy assessment
Action Items
BLOCKING (must fix before implementation):- Critical technical gaps
- Security vulnerabilities
- Missing specifications
- Performance optimizations
- Documentation improvements
- Future refactoring needs
Output
Creates:projects/{project}/vendors/{vendor}/ARC-{PROJECT_ID}-DLDR-v1.0.md
Example Review
Input
Assessment
- ✅ HLD approved, conditions met
- ✅ Payment Service: Well-defined API
- ❌ Fraud Service: Missing ML model spec (BLOCKING)
- ✅ OpenAPI 3.0 spec provided
- ❌ Missing data retention strategy (BLOCKING)
- ✅ OAuth 2.0 + JWT detailed
- ⚠️ Performance test plan incomplete
Outcome
Status: APPROVED WITH CONDITIONS Blocking Items:- Specify fraud detection ML model
- Define data retention policy (7 years PCI)
Related Commands
arckit hld-review- Review HLD firstarckit diagram- Validate with component diagramsarckit data-model- Cross-check data models
Important Notes
- DLD review is the FINAL gate before implementation
- HLD must be approved before DLD review starts
- Any architectural changes require HLD re-review
- DLD must be detailed enough for ANY developer to implement
- This is the last chance to catch design issues before expensive code changes
Next Steps
After DLD approval:- Vendor addresses blocking items
- Implementation can begin
- Code review checks DLD compliance
- Testing validates DLD specifications
- Update traceability matrix