@jwikman/bc-code-intelligence-mcp 1.5.7-dev.1

package/embedded-knowledge/domains/quinn-tester/samples/table-safety-validation-patterns.md

@@ -0,0 +1,101 @@
+# Table Safety Validation Patterns
+
+## IsTemporary Safeguard Implementation
+```al
+procedure ProcessBulkData(var DataBuffer: Record "Data Processing Buffer")
+begin
+    // Always validate temporary status before bulk operations
+    if not DataBuffer.IsTemporary then
+        Error('This procedure requires a temporary table to prevent data corruption.');
+        
+    DataBuffer.Reset();
+    if DataBuffer.FindSet() then
+        repeat
+            ProcessIndividualRecord(DataBuffer);
+            DataBuffer.Delete(); // Safe because table is confirmed temporary
+        until DataBuffer.Next() = 0;
+end;
+```
+
+## Database Write Protection
+```al
+procedure SafeDataManipulation(var TempCustomer: Record Customer temporary)
+var
+    Customer: Record Customer;
+begin
+    // Validate temporary status before any modifications
+    if not TempCustomer.IsTemporary then
+        Error('Database safety violation: Expected temporary table for data manipulation.');
+        
+    // Safe to perform destructive operations
+    TempCustomer.Reset();
+    TempCustomer.DeleteAll();
+    
+    // Load fresh data from permanent table
+    Customer.FindSet();
+    repeat
+        TempCustomer := Customer;
+        TempCustomer.Insert();
+    until Customer.Next() = 0;
+end;
+```
+
+## Bulk Operation Validation
+```al
+procedure ProcessLargeDataSet(var TempItem: Record Item temporary; ProcessingMode: Option Validate,Update,Delete)
+begin
+    // Critical safety check for bulk operations
+    if not TempItem.IsTemporary then
+        Error('Bulk processing operations require temporary tables. This prevents accidental permanent data modification.');
+        
+    case ProcessingMode of
+        ProcessingMode::Validate:
+            ValidateAllRecords(TempItem);
+        ProcessingMode::Update:
+            UpdateAllRecords(TempItem);
+        ProcessingMode::Delete:
+            TempItem.DeleteAll(); // Safe deletion
+    end;
+end;
+
+local procedure ValidateAllRecords(var TempItem: Record Item temporary)
+begin
+    TempItem.Reset();
+    if TempItem.FindSet() then
+        repeat
+            ValidateItemData(TempItem);
+        until TempItem.Next() = 0;
+end;
+```
+
+## Data Integrity Protection
+```al
+procedure SecureDataProcessing(var WorkingTable: Record "Working Data Buffer")
+var
+    OriginalFilters: Text;
+begin
+    // Mandatory safety validation
+    if not WorkingTable.IsTemporary then
+        Error('Data integrity protection: This operation requires a temporary working table.');
+        
+    OriginalFilters := WorkingTable.GetFilters();
+    
+    try
+        WorkingTable.Reset();
+        ProcessAllRecords(WorkingTable);
+    finally
+        // Restore original state
+        WorkingTable.Reset();
+        WorkingTable.SetView(OriginalFilters);
+    end;
+end;
+
+local procedure ProcessAllRecords(var WorkingTable: Record "Working Data Buffer")
+begin
+    if WorkingTable.FindSet(true) then
+        repeat
+            WorkingTable."Processing Status" := WorkingTable."Processing Status"::Completed;
+            WorkingTable.Modify();
+        until WorkingTable.Next() = 0;
+end;
+```

package/embedded-knowledge/domains/quinn-tester/samples/temporary-table-operation-validation.md

@@ -0,0 +1,91 @@
+# Temporary Table Operation Validation
+
+## Pre-Operation Validation
+```al
+procedure ValidateTemporaryTableOperation(var TempRecord: Record "Generic Record"; OperationType: Text)
+begin
+    if not TempRecord.IsTemporary then
+        Error('Operation "%1" requires a temporary table to ensure data safety. Current table is permanent.', OperationType);
+        
+    if TempRecord.IsEmpty() then
+        Error('Cannot perform "%1" operation on empty temporary table.', OperationType);
+end;
+```
+
+## Batch Processing Safety Check
+```al
+procedure ProcessTemporaryRecords(var TempSalesLine: Record "Sales Line" temporary)
+var
+    LineCount: Integer;
+begin
+    // Validate temporary status before bulk operations
+    if not TempSalesLine.IsTemporary then
+        Error('Batch processing requires temporary table to prevent permanent data corruption.');
+        
+    TempSalesLine.Reset();
+    LineCount := TempSalesLine.Count();
+    
+    if LineCount = 0 then
+        Error('No records found in temporary table for processing.');
+        
+    if LineCount > 10000 then
+        if not Confirm('Processing %1 records may take considerable time. Continue?', false, LineCount) then
+            exit;
+            
+    ProcessBatchRecords(TempSalesLine);
+end;
+```
+
+## Complex Operation Validation
+```al
+procedure ExecuteComplexDataOperation(var TempCustomer: Record Customer temporary; var TempVendor: Record Vendor temporary)
+begin
+    // Validate both tables are temporary
+    ValidateAllTablesTemporary(TempCustomer, TempVendor);
+    
+    // Validate data consistency
+    if TempCustomer.IsEmpty() and TempVendor.IsEmpty() then
+        Error('At least one temporary table must contain data for processing.');
+        
+    // Execute complex operation safely
+    ProcessCustomerVendorRelationship(TempCustomer, TempVendor);
+end;
+
+local procedure ValidateAllTablesTemporary(var TempCustomer: Record Customer temporary; var TempVendor: Record Vendor temporary)
+begin
+    if not TempCustomer.IsTemporary then
+        Error('Customer table must be temporary for this operation.');
+        
+    if not TempVendor.IsTemporary then
+        Error('Vendor table must be temporary for this operation.');
+end;
+```
+
+## Transaction Safety Validation
+```al
+procedure SafeTemporaryTableTransaction(var TempGLEntry: Record "G/L Entry" temporary)
+begin
+    if not TempGLEntry.IsTemporary then
+        Error('Financial data operations require temporary tables to prevent accidental posting.');
+        
+    // Validate data integrity before processing
+    ValidateFinancialData(TempGLEntry);
+    
+    // Process in transaction
+    if TempGLEntry.FindSet() then
+        repeat
+            ProcessGLEntry(TempGLEntry);
+        until TempGLEntry.Next() = 0;
+end;
+
+local procedure ValidateFinancialData(var TempGLEntry: Record "G/L Entry" temporary)
+var
+    TotalAmount: Decimal;
+begin
+    TempGLEntry.CalcSums(Amount);
+    TotalAmount := TempGLEntry.Amount;
+    
+    if Abs(TotalAmount) > 1000000 then
+        Error('Total amount %1 exceeds safety threshold for temporary table operations.', TotalAmount);
+end;
+```

package/embedded-knowledge/domains/quinn-tester/table-safety-validation-patterns.md

@@ -0,0 +1,79 @@
+---
+title: "Table Safety Validation Patterns for Error Prevention"
+domain: "quinn-tester"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["error-prevention", "table-safety", "validation", "defensive-programming", "data-protection"]
+prerequisites: ["error-handling", "al-tables"]
+samples: "samples/table-safety-validation-patterns.md"
+---
+# Table Safety Validation Patterns for Error Prevention
+
+## Overview
+
+Table safety validation patterns provide defensive programming approaches that prevent common data manipulation errors by validating table state, operation context, and business constraints before executing potentially destructive operations.
+
+**Prevention Strategy**: Implement validation barriers that catch dangerous operations before they can cause data corruption, performance issues, or business logic violations.
+
+## Strategic Framework
+
+### Proactive Error Prevention
+- **Validation gates**: Check conditions that could lead to errors before execution
+- **Safe defaults**: Design operations to fail safely when validation is incomplete
+- **Context awareness**: Validate operations against current business and technical context
+- **Recovery preparation**: Include error recovery information in validation failures
+
+### Risk Assessment Strategy
+- **Impact evaluation**: Assess potential damage from failed validations
+- **Probability analysis**: Focus validation on most likely error scenarios
+- **Cost-benefit balance**: Optimize validation overhead against error prevention value
+- **Monitoring integration**: Track validation patterns to improve error prevention
+
+## Architecture Patterns
+
+### Multi-Layer Validation Architecture
+Implement validation at multiple levels (table, operation, business rule) to create comprehensive error prevention coverage without excessive performance overhead.
+
+### Fail-Fast Pattern Implementation
+Design validation to detect and report errors as early as possible in operation execution, minimizing resource waste and simplifying error recovery.
+
+### Contextual Safety Checks
+Build validation that considers current operational context, user permissions, data state, and business rules to prevent context-inappropriate operations.
+
+## Implementation Guidelines
+
+### Validation Design Principles
+- **Specific error identification**: Provide precise information about validation failures
+- **Performance optimization**: Design efficient validation that doesn't significantly impact operation speed
+- **Maintainable validation**: Create validation rules that are easy to update as requirements change
+- **Comprehensive coverage**: Address common error scenarios systematically
+
+### Error Prevention Strategy
+Implement validation patterns that catch errors before they propagate through the system, focusing on operations that could cause data integrity issues or performance problems.
+
+### Recovery Planning Integration
+Design validation failures to include guidance for correcting the conditions that caused the validation to fail.
+
+## Best Practices
+
+### Defensive Programming Approach
+- **Assume input variability**: Validate all external inputs and parameters
+- **Check preconditions**: Verify system state meets operation requirements
+- **Validate postconditions**: Ensure operations completed as expected
+- **Monitor edge cases**: Pay special attention to boundary conditions and unusual scenarios
+
+### Systematic Validation Implementation
+Apply consistent validation patterns across similar operations, ensuring comprehensive error prevention coverage without creating maintenance overhead.
+
+### Documentation and Communication
+Clearly document validation logic and error prevention strategies to help team members understand and maintain safety measures.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Validation bypass**: Skipping safety checks for convenience or performance
+- **Generic error handling**: Non-specific error messages that don't help diagnosis
+- **Late validation**: Checking safety conditions after beginning operations
+- **Inconsistent application**: Using validation in some contexts but not others
+- **Over-validation**: Excessive checking that significantly impacts performance
+

package/embedded-knowledge/domains/quinn-tester/temporary-table-operation-validation.md

@@ -0,0 +1,79 @@
+---
+title: "Temporary Table Operation Validation Patterns"
+domain: "quinn-tester"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["validation", "temporary-tables", "data-integrity", "operation-safety", "preconditions"]
+prerequisites: ["al-tables", "validation-patterns"]
+samples: "samples/temporary-table-operation-validation.md"
+---
+# Temporary Table Operation Validation Patterns
+
+## Overview
+
+Temporary table operation validation ensures data manipulation procedures correctly identify and handle temporary versus permanent tables, preventing unintended data modifications and maintaining operation safety through systematic validation patterns.
+
+**Validation Principle**: Validate table characteristics and operational context before executing data modifications to ensure operations match intended scope and safety requirements.
+
+## Strategic Framework
+
+### Validation Layer Architecture
+- **Precondition validation**: Verify table state before operation execution
+- **Operation scoping**: Ensure operations match table characteristics
+- **Context awareness**: Validate operations against business rules and data constraints
+- **Safety enforcement**: Prevent operations that violate data integrity principles
+
+### Multi-Level Validation Strategy
+- **Table-level checks**: Validate table properties and characteristics
+- **Operation-level checks**: Ensure operation appropriateness for table type
+- **Data-level checks**: Verify data consistency and integrity requirements
+- **Business rule validation**: Confirm operations align with business logic
+
+## Architecture Patterns
+
+### Precondition Validation Framework
+Implement systematic validation that checks table properties, operation parameters, and business context before allowing data manipulation operations to proceed.
+
+### Conditional Operation Pattern
+Design operations that adapt their behavior based on table validation results, providing different execution paths for temporary versus permanent tables.
+
+### Validation Chain Architecture
+Build validation sequences that check multiple conditions in logical order, failing fast when validation criteria are not met.
+
+## Implementation Guidelines
+
+### Validation Sequence Design
+- **Early validation**: Check conditions before resource allocation or lock acquisition
+- **Logical ordering**: Validate quick checks before expensive operations
+- **Clear failure points**: Provide specific validation failure information
+- **Recovery guidance**: Include corrective action suggestions in validation messages
+
+### Table Characteristic Validation
+Implement checks for table temporariness, permissions, field availability, and other characteristics that affect operation safety and appropriateness.
+
+### Operation Context Validation
+Validate that proposed operations are appropriate for current business context, user permissions, and data state conditions.
+
+## Best Practices
+
+### Comprehensive Validation Coverage
+- **Complete condition checking**: Validate all relevant preconditions systematically
+- **Consistent validation patterns**: Apply similar validation approaches across related operations
+- **Performance optimization**: Balance thoroughness with execution efficiency
+- **Maintainable validation**: Design validation rules that are easy to update and extend
+
+### Error Communication Strategy
+Provide clear, specific error messages that help developers understand validation failures and guide them toward correct implementation approaches.
+
+### Testing Integration
+Include validation testing in unit test suites, ensuring validation logic correctly identifies valid and invalid operation scenarios.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Incomplete validation**: Missing critical precondition checks
+- **Late validation**: Checking conditions after beginning modifications
+- **Silent validation failures**: Not providing clear feedback when validation fails
+- **Inconsistent validation**: Different validation approaches for similar operations
+- **Performance-over-safety**: Skipping validation for perceived performance benefits
+

package/embedded-knowledge/domains/roger-reviewer/al-begin-end-block-structure.md

@@ -0,0 +1,89 @@
+---
+title: "AL Begin/End Block Structure Conventions"
+domain: "roger-reviewer"
+difficulty: "beginner"
+bc_versions: "14+"
+tags: ["al-syntax", "code-structure", "triggers", "blocks"]
+samples: "samples/al-begin-end-blocks.md"
+type: "language-feature"
+category: "al-syntax"
+pattern_type: "good"
+severity: "low"
+impact_level: "medium"
+improvement_suggestion: "Use proper begin/end block structure for maintainable AL code"
+implementation_steps: ["understand-block-types", "apply-nesting-rules", "maintain-indentation"]
+validation_criteria: ["proper-block-nesting", "consistent-indentation", "clear-trigger-structure"]
+technical_areas: ["al-code", "syntax"]
+---
+
+# AL Begin/End Block Structure Conventions
+
+## Overview
+
+Begin/end blocks form the fundamental structure of AL code organization, defining scope boundaries for triggers, procedures, and control statements. Proper block structure ensures code readability, maintainability, and compiler compliance across all AL object types.
+
+**Key Principle**: Every begin statement must have a corresponding end statement, with consistent indentation and logical organization that reflects the code's hierarchical structure.
+
+AL uses begin/end blocks to group statements in triggers, procedures, and control structures. Unlike languages that use curly braces, AL's explicit begin/end syntax requires careful attention to matching pairs and proper nesting levels.
+
+## Strategic Framework
+
+### Block Types and Usage Patterns
+**Object Triggers**: Table, page, and report triggers use begin/end to define event handling logic with specific indentation conventions that reflect the trigger's scope within the object hierarchy.
+
+**Procedure Bodies**: Function and procedure definitions require begin/end blocks to encapsulate implementation logic, with parameter validation and return value handling organized within the block structure.
+
+**Control Structures**: If/then/else, case, while, and for statements use begin/end blocks to group multiple statements, enabling complex conditional and iterative logic organization.
+
+**Exception Handling**: Try/catch blocks and error handling patterns rely on proper begin/end structure to define exception scope and recovery logic boundaries.
+
+### Scope Management Principles
+Begin/end blocks establish variable scope boundaries and memory management contexts. Local variables declared within blocks have limited lifetime, while proper nesting ensures predictable variable accessibility patterns.
+
+Block structure directly impacts debugging capabilities, with debugger stepping behavior following begin/end boundaries. Well-structured blocks enable precise breakpoint placement and variable inspection at appropriate scope levels.
+
+## Architecture Focus
+
+### Trigger Structure Patterns
+Object triggers follow established conventions where the trigger keyword is followed by begin/end blocks containing the implementation logic. Primary triggers like OnInsert, OnModify, and OnDelete use consistent indentation patterns.
+
+Complex triggers may contain nested begin/end blocks for conditional logic, but excessive nesting indicates potential refactoring opportunities toward separate procedures or better logical organization.
+
+### Procedure Organization Standards
+Procedure definitions separate the signature line from the implementation block, with local variables declared between the signature and begin statement. This separation clarifies parameter contracts and local variable scope.
+
+Return statements within procedure blocks require careful placement, ensuring all code paths properly handle return values and that unreachable code warnings are addressed through proper block organization.
+
+### Control Flow Architecture
+Nested control structures require systematic indentation increases for each begin/end level, creating visual hierarchy that matches the logical structure. Deep nesting beyond three levels suggests architectural refactoring needs.
+
+Exception handling blocks integrate with normal control flow through try/catch patterns that maintain clear begin/end boundaries while providing comprehensive error recovery mechanisms.
+
+## Best Practices
+
+### Indentation and Formatting Standards
+- **Consistent Indentation**: Maintain four-space indentation for each begin/end nesting level, aligning begin and end keywords at the same indentation level
+- **Visual Block Boundaries**: Create clear visual block boundaries that match logical code organization
+- **Semicolon Placement**: Place semicolons correctly after end keywords to maintain AL syntax compliance
+
+### Block Boundary Management
+- **Matched Pairs**: Every begin statement requires a corresponding end statement at the same indentation level
+- **Meaningful Blocks**: Avoid empty begin/end blocks except where required by AL syntax
+- **Logical Organization**: Group related statements within begin/end blocks to create coherent units of work
+
+### Variable Scope Optimization
+- **Appropriate Scope**: Declare variables at the narrowest appropriate scope level using begin/end blocks
+- **Meaningful Names**: Use descriptive variable names that reflect their purpose within specific block contexts
+- **Memory Management**: Leverage begin/end blocks to limit variable lifetime and improve memory usage patterns
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Mismatched Pairs**: Missing or extra begin/end statements create compilation errors and logical inconsistencies
+- **Inconsistent Indentation**: Irregular indentation patterns obscure block boundaries and complicate maintenance
+- **Excessive Nesting**: Deep begin/end nesting beyond reasonable levels indicates architectural problems requiring refactoring
+- **Empty Blocks**: Unnecessary empty begin/end blocks add visual clutter without functional value
+- **Poor Exception Boundaries**: Exception handling blocks that don't align with logical begin/end boundaries create unclear error recovery patterns
+
+*Implementation examples: see samples/al-begin-end-blocks.md*
+*Related patterns: al-procedure-organization.md, al-error-handling-patterns.md*

package/embedded-knowledge/domains/roger-reviewer/al-binary-operator-spacing.md

@@ -0,0 +1,76 @@
+---
+title: "AL Binary Operator Spacing"
+domain: "roger-reviewer"
+difficulty: "beginner"
+bc_versions: "14+"
+tags: ["operators", "spacing", "expressions"]
+samples: "samples/al-binary-operator-spacing.md"
+type: "improvement-pattern"
+category: "code-formatting"
+pattern_type: "good"
+severity: "medium"
+impact_level: "medium"
+improvement_suggestion: "Use consistent spacing around binary operators to improve expression readability"
+implementation_steps: ["standardize-operator-spacing", "apply-consistent-patterns", "validate-readability"]
+validation_criteria: ["consistent-operator-spacing", "improved-expression-clarity"]
+technical_areas: ["al-code"]
+---
+
+# AL Binary Operator Spacing
+
+## Overview
+
+Consistent spacing around binary operators in AL expressions improves readability and helps developers quickly understand mathematical, logical, and comparison operations. Proper operator spacing is a fundamental formatting practice that enhances code clarity.
+
+**Key Principle**: Use consistent spacing around binary operators to create clear, readable expressions that are easy to understand and maintain.
+
+## Strategic Framework
+
+### Expression Clarity
+- **Visual Separation**: Clear spacing around operators for easy parsing
+- **Readability Focus**: Formatting that supports quick expression comprehension
+- **Consistency Standards**: Uniform spacing patterns across all expressions
+- **Mathematical Convention**: Spacing that follows standard mathematical notation
+
+### Code Comprehension
+Well-spaced operators help developers quickly identify expression structure, operator precedence, and logical relationships within complex calculations and conditions.
+
+## Architecture Focus
+
+### Operator Categories
+- **Arithmetic Operators**: +, -, *, /, mod with consistent spacing
+- **Comparison Operators**: =, <>, <, >, <=, >= with clear separation
+- **Logical Operators**: and, or, not with appropriate spacing
+- **Assignment Operators**: := with consistent formatting
+
+### Spacing Patterns
+Establish consistent spacing rules that work well with AL syntax and support effective expression formatting across different operator types and complexity levels.
+
+## Best Practices
+
+### Spacing Guidelines
+- **Single space before and after** binary operators
+- **Consistent application** across all expression types
+- **Clear operator separation** in complex expressions
+- **Parentheses coordination** with operator spacing
+- **Alignment consideration** in multi-line expressions
+
+### Expression Organization
+Structure complex expressions with appropriate spacing to maintain readability. Use consistent patterns for operator spacing that integrate well with overall code formatting.
+
+### Readability Optimization
+Format expressions to minimize cognitive load when understanding mathematical and logical operations. Use spacing to create natural reading flow in complex calculations.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **No spacing around operators** creating cramped expressions
+- **Inconsistent spacing** within single expressions
+- **Excessive spacing** disrupting expression flow
+- **Mixed spacing styles** across different AL objects
+- **Poor alignment** in multi-line expressions
+
+Poor operator spacing makes expressions harder to read and increases the likelihood of errors when understanding complex calculations and logical conditions.
+
+*Implementation examples: see samples/al-binary-operator-spacing.md*
+*Related patterns: al-comment-spacing-standards.md, al-readability-optimization.md*

package/embedded-knowledge/domains/roger-reviewer/al-blank-line-organization.md

@@ -0,0 +1,76 @@
+---
+title: "AL Blank Line Organization"
+domain: "roger-reviewer"
+difficulty: "beginner"
+bc_versions: "14+"
+tags: ["formatting", "readability", "code-organization"]
+samples: "samples/al-blank-line-organization.md"
+type: "improvement-pattern"
+category: "code-formatting"
+pattern_type: "good"
+severity: "medium"
+impact_level: "medium"
+improvement_suggestion: "Use strategic blank lines to organize AL code into logical sections"
+implementation_steps: ["identify-logical-sections", "insert-separating-blank-lines", "validate-consistency"]
+validation_criteria: ["logical-grouping-clear", "consistent-spacing-applied"]
+technical_areas: ["al-code"]
+---
+
+# AL Blank Line Organization
+
+## Overview
+
+Strategic blank line placement in AL code creates visual separation between logical sections, improving readability and maintainability. Proper blank line organization helps developers quickly identify code structure and navigate complex procedures and functions.
+
+**Key Principle**: Use blank lines to separate distinct logical operations, not arbitrary code segments.
+
+## Strategic Framework
+
+### Visual Code Organization
+- **Logical Grouping**: Separate variable declarations, business logic sections, and error handling
+- **Functional Boundaries**: Use blank lines before and after major functional blocks
+- **Context Switching**: Insert blank lines when switching between different data operations
+- **Method Structure**: Consistent spacing patterns within methods and triggers
+
+### Readability Enhancement
+Blank lines act as visual punctuation, allowing developers to parse code structure quickly. They reduce cognitive load by creating natural reading breaks and highlighting important transitions.
+
+## Architecture Focus
+
+### Code Structure Patterns
+- **Declaration Blocks**: Separate variable declarations from executable code
+- **Business Logic Sections**: Group related operations with clear boundaries
+- **Error Handling**: Isolate error handling code with appropriate spacing
+- **Data Processing**: Separate input validation, processing, and output operations
+
+### Consistency Principles
+Establish team-wide conventions for blank line usage to ensure consistent code appearance across all AL objects. Consistent formatting reduces context switching overhead when reviewing code.
+
+## Best Practices
+
+### Effective Blank Line Placement
+- **After variable declarations** before first executable statement
+- **Between major functional blocks** within procedures
+- **Before and after loops** containing significant logic
+- **Around error handling blocks** for clear separation
+- **Between related but distinct operations** for logical grouping
+
+### Grouping Strategies
+Group related variable declarations together, separate business logic sections clearly, and use blank lines to emphasize important transitions in code flow.
+
+### Consistency Rules
+Apply blank line patterns consistently across all AL objects in your extension. Document team conventions for blank line usage in coding standards.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Excessive blank lines** that fragment code unnecessarily
+- **Random spacing** without logical organization principles
+- **No blank lines** creating dense, hard-to-read code blocks
+- **Inconsistent patterns** across different AL objects
+- **Blank lines within tightly coupled operations** that should remain grouped
+
+Inconsistent blank line usage creates visual noise and makes code harder to scan effectively. Avoid both extremes of no spacing and excessive spacing.
+
+*Implementation examples: see samples/al-blank-line-organization.md*
+*Related patterns: al-formatting-consistency-patterns.md, al-readability-optimization.md*

package/embedded-knowledge/domains/roger-reviewer/al-case-action-formatting.md

@@ -0,0 +1,76 @@
+---
+title: "AL Case Action Formatting"
+domain: "roger-reviewer"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["case-statements", "formatting", "control-flow"]
+samples: "samples/al-case-action-formatting.md"
+type: "improvement-pattern"
+category: "code-formatting"
+pattern_type: "good"
+severity: "medium"
+impact_level: "medium"
+improvement_suggestion: "Format case statement actions with consistent indentation and clear action boundaries"
+implementation_steps: ["standardize-case-indentation", "align-action-blocks", "validate-readability"]
+validation_criteria: ["consistent-indentation", "clear-action-separation"]
+technical_areas: ["al-code"]
+---
+
+# AL Case Action Formatting
+
+## Overview
+
+Proper formatting of case statement actions in AL code ensures clear visual separation between different case branches and improves code readability. Consistent case action formatting helps developers quickly understand control flow logic and reduces errors in complex decision structures.
+
+**Key Principle**: Each case action should be clearly separated and consistently indented to highlight the decision structure.
+
+## Strategic Framework
+
+### Case Statement Structure
+- **Visual Hierarchy**: Clear indentation showing case relationship to parent statement
+- **Action Boundaries**: Distinct separation between different case actions
+- **Consistent Patterns**: Uniform formatting across all case statements in codebase
+- **Readability Focus**: Format that supports quick visual parsing of decision logic
+
+### Control Flow Clarity
+Case formatting should make the decision structure immediately apparent to code reviewers and maintainers. Well-formatted case statements reduce cognitive overhead when understanding complex business logic.
+
+## Architecture Focus
+
+### Indentation Standards
+- **Case Labels**: Consistent alignment with case keyword
+- **Action Blocks**: Proper indentation for multi-line actions
+- **Nested Structures**: Clear hierarchy for nested case statements
+- **Code Organization**: Logical grouping of related case branches
+
+### Visual Consistency
+Establish consistent patterns for case action formatting that work well with AL language structure and team coding practices. Consistent formatting improves code review efficiency.
+
+## Best Practices
+
+### Formatting Patterns
+- **Consistent indentation** for all case actions within statement
+- **Clear separation** between case labels and actions
+- **Aligned case labels** for easy visual scanning
+- **Proper spacing** around case statement boundaries
+- **Multi-line action formatting** with appropriate indentation
+
+### Action Organization
+Group related case actions logically, use consistent formatting for single-line versus multi-line actions, and maintain clear visual boundaries between different branches.
+
+### Readability Optimization
+Format case statements to support quick visual parsing of decision logic. Use whitespace effectively to create clear visual separation between different execution paths.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Inconsistent case label alignment** making structure unclear
+- **Poor action block indentation** obscuring code hierarchy
+- **Cramped formatting** without adequate spacing
+- **Mixed formatting styles** within single case statement
+- **Unclear action boundaries** between different cases
+
+Poor case formatting makes decision logic harder to follow and increases the likelihood of errors during code maintenance and enhancement.
+
+*Implementation examples: see samples/al-case-action-formatting.md*
+*Related patterns: al-keyword-indentation-rules.md, al-separate-if-else-formatting.md*