Arckit Dld Review

Read existing artifacts from the project context:

MANDATORY (warn if missing):

• HLDR (HLD Review) — Extract: HLD review findings, conditions, outstanding actions
  • If missing: warn that DLD review should follow HLD review
• PRIN (Architecture Principles, in 000-global) — Extract: all principles with validation gates
  • If missing: warn user to run $arckit-principles first
• REQ (Requirements) — Extract: NFR/INT/DR requirements for detailed technical verification
  • If missing: warn user to run $arckit-requirements first

RECOMMENDED (read if available, note if missing):

• DATA (Data Model) — Extract: entity schemas, data types, relationships for data model review
• RISK (Risk Register) — Extract: technical risks that DLD should address

OPTIONAL (read if available, skip silently):

• SECD (Secure by Design) — Extract: security controls for security implementation review

Read the template (with user override support):

• First, check if .arckit/templates/dld-review-template.md exists in the project root
• If found: Read the user's customized template (user override takes precedence)
• If not found: Read .arckit/templates/dld-review-template.md (default)

Tip: Users can customize templates with $arckit-customize dld-review

Verify HLD approval:

• Check that HLD was approved (DLD cannot proceed without HLD approval)
• Verify all HLD conditions were addressed
• Confirm no new architectural changes were introduced (if yes, needs HLD re-review)

Read external documents and policies:

• Read any vendor DLD submissions in projects/{project-dir}/vendors/{vendor}/ — extract detailed component specifications, API contracts, database schemas, deployment configurations, security implementation details
• Read any external documents listed in the project context (external/ files) — extract performance test results, security scan reports, infrastructure specifications
• Read any enterprise standards in projects/000-global/external/ — extract enterprise design standards, implementation guidelines, cross-project technical architecture patterns
• If no vendor DLD found, ask: "Please provide the DLD document path or paste key sections. I can read PDFs, Word docs, and images directly. Place them in projects/{project-dir}/vendors/{vendor}/ and re-run, or provide the path."
• Citation traceability: When referencing content from external documents, follow the citation instructions in .arckit/references/citation-instructions.md. Place inline citation markers (e.g., [PP-C1]) next to findings informed by source documents and populate the "External References" section in the template.

Obtain the DLD document:

• Ask: "Please provide the DLD document path or paste key sections"
• Or: "Is the DLD in projects/{project-dir}/vendors/{vendor}/dld-v*.md?"
• Or: "Please share detailed design diagrams, sequence diagrams, ERDs"

Perform detailed technical review:

A. Component Design Review

For each component/service:

• Interface definition: APIs, events, messages clearly defined?
• Data structures: Request/response schemas, DTOs documented?
• Business logic: Core algorithms and workflows specified?
• Error handling: Exception handling strategy defined?
• Dependencies: External services, libraries, frameworks listed?

B. API Design Review

• API specifications: OpenAPI/Swagger docs provided?
• Endpoint design: RESTful conventions followed? Proper HTTP methods?
• Request validation: Input validation rules specified?
• Response formats: JSON schemas defined? Error responses documented?
• Authentication: Auth flows detailed? Token formats specified?
• Rate limiting: Throttling strategy defined?
• Versioning: API versioning strategy clear?

C. Data Model Review

• Database schema: ERD provided? Tables, columns, types defined?
• Relationships: Foreign keys, indexes, constraints documented?
• Data types: Appropriate types for each field?
• Normalization: Proper normalization (or justified denormalization)?
• Migrations: Schema migration strategy defined?
• Partitioning: Sharding or partitioning strategy if needed?
• Archival: Data retention and archival approach?

D. Security Implementation Review

• Authentication implementation: OAuth flows, JWT structure, session management?
• Authorization implementation: RBAC/ABAC model, permission matrix?
• Encryption details: Algorithms (AES-256, RSA), key management (KMS)?
• Secrets management: How are secrets stored? (AWS Secrets Manager, Vault)
• Input sanitization: XSS prevention, SQL injection prevention?
• Audit logging: What gets logged? Log retention policy?
• Compliance mapping: How does each control map to compliance requirements?

E. Integration Design Review

• Integration patterns: Sync/async? REST/gRPC/message queue?
• Error handling: Retry logic, circuit breakers, timeouts?
• Data transformation: Mapping between systems defined?
• API contracts: Contract testing approach?
• Service discovery: How services find each other?
• Message formats: Event schemas, message structures?

F. Performance Design Review

• Caching strategy: What gets cached? TTL? Invalidation strategy?
• Database optimisation: Indexes defined? Query optimisation?
• Connection pooling: Pool sizes, timeout configs?
• Async processing: Background jobs, queue workers?
• Batch processing: Batch sizes, scheduling?
• Load testing plan: Performance test scenarios defined?

G. Operational Design Review

• Monitoring: Metrics to track? Dashboards defined? Alert thresholds?
• Logging: Log levels, structured logging, log aggregation?
• Tracing: Distributed tracing implementation (Jaeger, X-Ray)?
• Health checks: Liveness/readiness probes defined?
• Configuration: Config management approach (ConfigMaps, Parameter Store)?
• Deployment: CI/CD pipeline defined? Deployment strategy (blue-green, canary)?

H. Testing Strategy Review

• Unit testing: Coverage targets? Testing frameworks?
• Integration testing: Test scenarios defined?
• Contract testing: API contract tests specified?
• Performance testing: Load/stress test plans?
• Security testing: SAST/DAST tools? Penetration testing plan?
• UAT approach: User acceptance test criteria?

Implementation Readiness Check:

Ask these critical questions:

• ✅ Can developers start coding immediately with this DLD?
• ✅ Are all technical ambiguities resolved?
• ✅ Are all third-party dependencies identified?
• ✅ Is the test strategy comprehensive?
• ✅ Are deployment procedures clear?

Generate Review Report:

Executive Summary:

• Status: APPROVED / APPROVED WITH CONDITIONS / REJECTED / NEEDS HLD RE-REVIEW
• Implementation readiness score (0-100)
• Top risks or gaps

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 issues (must fix before implementation)
• Non-blocking improvements (fix during implementation)
• Technical debt to track

Implementation Guidance:

• Development sequence recommendations
• Critical path items
• Risk mitigation during implementation