alfresco-ng2-components/.github/copilot-instructions.md

General Code Review Instructions

Review Priorities

When performing a code review, prioritize issues in the following order:

🔴 CRITICAL (Block merge)

• Security: Vulnerabilities, exposed secrets, authentication/authorization issues, injection, XSS
• Memory/resource leaks
• Crashes or undefined behavior
• Correctness: Logic errors, data corruption risks, race conditions, missing error handling
• Data Loss: Risk of data loss or corruption

🟡 IMPORTANT (Requires discussion)

• Code Quality: Severe violations of SOLID principles, excessive duplication
• Test Coverage: Missing tests for critical paths or new functionality
• Performance: Obvious performance bottlenecks (N+1 queries, memory leaks)
• Architecture: Significant deviations from established patterns

🟢 SUGGESTION (Non-blocking improvements)

• Readability: Poor naming, complex logic that could be simplified
• Optimization: Performance improvements without functional impact
• Best Practices: Minor deviations from conventions
• Documentation: Missing or incomplete comments/documentation

General Review Principles

When performing a code review, follow these principles:

• Be specific: Reference exact lines, files, and provide concrete examples
• Be pragmatic: Not every suggestion needs immediate implementation
• Provide context: Explain WHY something is an issue and the potential impact
• Suggest solutions: Show corrected code when applicable, not just what's wrong
• Be constructive: Focus on improving the code, not criticizing the author
• Recognize good practices: Acknowledge well-written code and smart solutions
• Group related comments: Avoid multiple comments about the same topic
• Ask clarifying questions when code intent is unclear

Code Quality Standards

When performing a code review, check for:

Clean Code

• Descriptive and meaningful names for variables, functions, and classes
• Single Responsibility Principle: each function/class does one thing well
• DRY (Don't Repeat Yourself): no code duplication
• Functions should be small and focused (ideally < 20-30 lines)
• Avoid deeply nested code (max 3-4 levels), unit tests should be an exception from this rule
• Avoid magic numbers and strings (use constants)
• Code should be self-documenting; comments only when necessary
• Code follows consistent style and conventions
• No commented-out code or TODO without tickets

Error Handling

• Proper error handling at appropriate levels
• Meaningful error messages
• No silent failures or ignored exceptions
• Fail fast: validate inputs early
• Use appropriate error types/exceptions

Testing Standards

When performing a code review, verify test quality:

• Coverage: Critical paths and new functionality must have tests
• Test Names: Descriptive names that explain what is being tested
• Independence: Tests should not depend on each other or external state
• Assertions: Use specific assertions, avoid generics
• Edge Cases: Test boundary conditions, null values, empty inputs
• Mock Appropriately: Mock external dependencies, not domain logic
• New code has appropriate test coverage
• No tests that always pass or are commented out

Architecture and Design

When performing a code review, verify architectural principles:

• Separation of Concerns: Clear boundaries between layers/modules
• Dependency Direction: High-level modules don't depend on low-level details
• Interface Segregation: Prefer small, focused interfaces
• Loose Coupling: Components should be independently testable
• High Cohesion: Related functionality grouped together
• Consistent Patterns: Follow established patterns in the codebase