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

package/embedded-knowledge/domains/sam-coder/testfield-patterns.md

@@ -0,0 +1,101 @@
+---
+title: "TestField Best Practices and Patterns"
+domain: "sam-coder"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["best-practices", "validation", "code-quality", "maintainability"]
+prerequisites: ["testfield-basic-syntax", "testfield-error-handling"]
+samples: "samples/testfield-patterns.md"
+---
+# TestField Best Practices and Patterns
+
+## Overview
+
+Effective TestField usage follows established patterns that ensure data integrity while maintaining code readability and performance. These practices have evolved from real-world BC development experience.
+
+**Core Philosophy**: Use TestField for essential validations that prevent data corruption, complement with custom validation for business rule enforcement.
+
+## Fundamental Best Practices
+
+### Validation Placement Strategy
+Place TestField calls at the beginning of procedures to fail fast and provide immediate feedback. Early validation prevents complex processing with invalid data and provides clear error context.
+
+### Logical Validation Grouping
+Group related TestField calls to create clear validation blocks that represent business concepts. Organize validations by functional area (shipping, billing, customer data) for better code readability and maintenance.
+
+### Context-Appropriate Validation
+Match validation intensity to business context - more thorough validation for critical operations, lighter validation for routine operations.
+
+## Design Patterns
+
+### Mandatory Field Pattern
+Establish core validation procedures that verify essential fields for business entities. Focus on fields required for basic entity operation and integrity across all business scenarios.
+
+### Status-Driven Validation Pattern
+Apply different validation rules based on record workflow status. Each status level has specific field requirements that must be validated before status transitions or processing.
+
+### Conditional Validation Pattern
+Implement business rule-driven validation where field requirements depend on other field values or business context. Ensures data consistency while avoiding over-validation.
+
+## Advanced Patterns
+
+### Validation Factory Pattern
+Create generic validation procedures that route different record types to appropriate validation logic. Enables consistent validation interface across multiple entity types.
+
+### Progressive Validation Pattern
+Implement validation intensity levels based on business context. Basic operations require minimal validation while complex operations require comprehensive field validation.
+
+### Validation Chain Pattern
+Structure validation as sequential steps where each step must pass before proceeding. Provides clear validation progression and enables early exit when validation fails.
+
+## Integration Patterns
+
+### Event-Driven Validation
+Integrate TestField validation into table event subscribers for automatic validation during record operations. Ensures consistent validation across all insertion and modification paths.
+
+### API Validation Integration
+Adapt TestField validation for API scenarios using TryFunction patterns. Capture validation errors and convert them to structured API response messages rather than allowing system errors to propagate.
+
+## Code Quality Practices
+
+### Readable Validation Blocks
+Organize TestField calls with clear comments indicating validation purpose. Group related fields together and document business rationale for field requirements to improve code maintainability.
+
+### Validation Documentation
+Document validation rules and business reasons for TestField usage, especially for complex business scenarios.
+
+### Maintainable Validation Logic
+Structure validation procedures to be easily testable and maintainable as business rules evolve.
+
+## Common Anti-Patterns
+
+### Over-Validation
+Avoid excessive TestField calls that create poor user experience without meaningful business value.
+
+### Mixed Concerns
+Don't mix TestField validation with complex business logic in the same procedure.
+
+### Performance-Blind Validation
+Avoid TestField in tight loops without considering cumulative performance impact.
+
+### Context-Blind Validation
+Don't apply same validation rules across all scenarios without considering business context.
+
+## Testing Strategies
+
+### Validation Testing
+Create test procedures that validate both successful and failing TestField scenarios. Test mandatory field validation by attempting validation with empty records and verifying error conditions trigger correctly.
+
+For complete testing examples, see companion sample file with working AL test procedures.
+
+### Edge Case Testing
+Test validation behavior with edge cases like empty strings, special characters, and boundary values.
+
+## Evolution and Maintenance
+
+### Validation Rule Changes
+Plan for validation rule changes by structuring validation logic in dedicated procedures that can be easily modified.
+
+### Backward Compatibility
+When changing validation rules, consider impact on existing data and provide migration paths.
+

package/embedded-knowledge/domains/sam-coder/type-safe-operations-al.md

@@ -0,0 +1,149 @@
+---
+title: "Type-Safe Operations in AL"
+domain: "sam-coder"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["type-safety", "compile-time-validation", "strong-typing", "error-prevention"]
+prerequisites: ["al-data-types", "variable-declaration", "procedure-design"]
+samples: "samples/type-safe-operations.md"
+related_topics: ["generic-method-patterns-al", "template-method-pattern-al"]
+---
+
+# Type-Safe Operations in AL
+
+## Overview
+
+Type-Safe Operations in AL leverage the language's strong typing system to prevent runtime errors through compile-time validation. These patterns ensure operations are performed on compatible data types and help catch potential issues during development rather than runtime.
+
+**Key Benefit**: Prevents runtime type errors through compile-time validation, improving code reliability and reducing debugging time in production systems.
+
+## Core Type Safety Principles
+
+### Strong Typing Enforcement
+Leverage AL's strong typing system to ensure variables and parameters are used consistently with their declared types throughout the codebase.
+
+### Compile-Time Validation
+Design code patterns that enable the compiler to catch type mismatches and incompatible operations before code execution.
+
+### Explicit Type Declarations
+Use explicit type declarations and avoid implicit conversions that might hide potential type compatibility issues.
+
+## Essential Type Safety Patterns
+
+### Strongly-Typed Identifiers
+Create specific types for different kinds of identifiers (customer IDs, item numbers, etc.) to prevent mixing incompatible identifier types.
+
+### Type-Safe Enumerations
+Use enumeration types instead of generic integers or strings to represent limited sets of values with compile-time validation.
+
+### Parameter Type Validation
+Design method signatures that use specific types rather than generic types to ensure callers provide appropriate data.
+
+## Advanced Type Safety Techniques
+
+### Type-Safe Builder Patterns
+Implement builder patterns that use the type system to enforce correct construction sequences and prevent invalid object states.
+
+### Phantom Type Patterns
+Use phantom types to track additional information in the type system without runtime overhead, enabling compile-time validation of complex constraints.
+
+### Type-Safe State Machines
+Design state machine implementations that use the type system to prevent invalid state transitions and operations.
+
+## Data Conversion Safety
+
+### Safe Casting Patterns
+- Implement safe type casting that validates compatibility before conversion
+- Use explicit casting methods that provide clear error handling for invalid conversions
+- Design conversion patterns that preserve data integrity during type changes
+- Provide clear error messages for conversion failures
+
+### Validation-First Conversions
+- Validate data compatibility before performing type conversions
+- Implement pre-conversion validation that checks data ranges and formats
+- Design conversion methods that fail fast for incompatible data
+- Support conversion result validation to ensure successful transformation
+
+## Compile-Time Validation Strategies
+
+### Interface-Based Type Safety
+Use interfaces to define type contracts that ensure objects provide required capabilities before being used in specific operations.
+
+### Generic Type Constraints
+Apply generic type constraints to limit generic methods to types that support required operations, enabling compile-time validation.
+
+### Type System Integration
+Integrate custom types with AL's type system to leverage built-in validation and conversion capabilities.
+
+## Error Prevention Patterns
+
+### Null Safety Patterns
+Design patterns that minimize null reference exceptions through careful use of optional types and null checking strategies.
+
+### Range Validation Types
+Create types that enforce valid ranges for numeric values, preventing out-of-range errors through type system constraints.
+
+### Format Validation Types
+Implement types that enforce specific format requirements (email addresses, phone numbers) through type system validation.
+
+## Testing Type Safety
+
+### Compile-Time Test Validation
+- Design tests that validate compile-time error detection for type safety violations
+- Test that invalid type combinations are rejected by the compiler
+- Validate that type constraints are properly enforced
+- Ensure type safety doesn't compromise performance
+
+### Type Compatibility Testing
+- Test type conversion scenarios to ensure safe handling of different data types
+- Validate that type-safe patterns work correctly with edge cases
+- Test integration scenarios where multiple type-safe patterns interact
+- Ensure type safety works correctly across module boundaries
+
+## Integration with AL Features
+
+### Record Type Safety
+Leverage AL record types to ensure type-safe database operations and prevent field type mismatches.
+
+### API Type Safety
+Design API interfaces that use strong typing to ensure callers provide correct data types and receive predictable responses.
+
+### Event Type Safety
+Implement type-safe event handling patterns that ensure event handlers receive correctly typed event data.
+
+## Performance Considerations
+
+### Type Safety Overhead
+Balance type safety benefits with potential performance overhead from additional validation and type checking operations.
+
+### Optimization Strategies
+Implement type safety patterns that compile to efficient code without runtime overhead when possible.
+
+### Validation Caching
+Cache type validation results where appropriate to minimize repeated validation overhead in performance-critical scenarios.
+
+## Best Practices
+
+### Design Guidelines
+- Use the most specific type appropriate for each variable and parameter
+- Implement explicit validation for external data before type conversion
+- Design type hierarchies that support both safety and flexibility
+- Document type safety requirements and constraints clearly
+
+### Code Organization
+- Group related type-safe operations into focused modules
+- Create utility methods for common type-safe operations
+- Implement consistent error handling for type safety violations
+- Provide clear examples of correct type-safe usage patterns
+
+## Common Pitfalls
+
+### Over-Engineering Types
+Avoid creating unnecessarily complex type hierarchies that make code harder to understand and maintain.
+
+### Performance Impact
+Be mindful of performance implications when implementing extensive type validation in high-frequency operations.
+
+*Complete type safety examples: samples/type-safe-operations.md*
+*Generic method patterns: generic-method-patterns-al.md*
+*Template method safety: template-method-pattern-al.md*

package/embedded-knowledge/domains/sam-coder/vs-code-al-keyboard-shortcuts.md

@@ -0,0 +1,107 @@
+---
+title: "VS Code AL Extension Keyboard Shortcuts"
+domain: "sam-coder"
+difficulty: "beginner"
+bc_versions: "14+"
+tags: ["vs-code", "productivity", "shortcuts", "al-extension", "navigation"]
+prerequisites: ["vs-code-setup", "al-extension-basics"]
+---
+
+# VS Code AL Extension Keyboard Shortcuts
+
+## Overview
+
+Master essential keyboard shortcuts for AL development in VS Code to dramatically increase coding speed and navigation efficiency. These shortcuts are specifically optimized for Business Central AL development workflows.
+
+**Key Principle**: Muscle memory for these core shortcuts reduces context switching and maintains coding flow state.
+
+## Essential AL Development Shortcuts
+
+### Code Generation & IntelliSense
+- **Ctrl+Space**: Trigger IntelliSense suggestions for AL objects and properties
+- **Ctrl+Shift+Space**: Parameter hints for procedure calls and method signatures
+- **Tab**: Accept IntelliSense suggestion and move to next parameter
+- **Ctrl+.**: Quick actions and refactoring suggestions (AL-specific fixes)
+
+### Navigation & Symbol Management
+- **F12**: Go to definition of AL object, procedure, or variable
+- **Alt+F12**: Peek definition in popup window without navigation
+- **Ctrl+F12**: Go to implementation (useful for interface implementations)
+- **Shift+F12**: Find all references to current symbol across workspace
+- **Ctrl+T**: Quick symbol search across entire AL workspace
+- **Ctrl+Shift+O**: Navigate to symbol within current file
+- **Ctrl+G**: Go to specific line number
+
+### AL Object Operations
+- **Ctrl+Shift+P → "AL: Go!"**: Quick navigation to any AL object by name
+- **Ctrl+Shift+P → "AL: Download symbols"**: Refresh symbol references
+- **F7**: Compile current AL file and show diagnostics
+- **Ctrl+Shift+F7**: Compile entire AL project
+- **F5**: Start debugging session with AL debugger
+
+## Code Editing Efficiency
+
+### Selection & Manipulation
+- **Ctrl+D**: Select next occurrence of current word (multi-cursor editing)
+- **Ctrl+Shift+L**: Select all occurrences of current word
+- **Alt+Click**: Add cursor at click position (multi-cursor)
+- **Ctrl+Shift+K**: Delete entire line
+- **Alt+Up/Down**: Move line or selection up/down
+- **Shift+Alt+Up/Down**: Copy line or selection up/down
+
+### Code Structure Navigation
+- **Ctrl+Shift+\\**: Jump to matching bracket/begin-end block
+- **Ctrl+]**: Indent selected lines (AL code formatting)
+- **Ctrl+[**: Outdent selected lines
+- **Ctrl+K, Ctrl+C**: Comment selected lines
+- **Ctrl+K, Ctrl+U**: Uncomment selected lines
+
+### AL-Specific Formatting
+- **Shift+Alt+F**: Format entire AL document according to AL formatting rules
+- **Ctrl+K, Ctrl+F**: Format selected AL code block
+- **Ctrl+Shift+I**: Format selection with AL-specific indentation
+
+## Debugging & Problem Solving
+
+### Debugging Navigation
+- **F9**: Toggle breakpoint on current line
+- **F5**: Start/continue debugging
+- **F10**: Step over (next line in same procedure)
+- **F11**: Step into (enter called procedure)
+- **Shift+F11**: Step out (return to calling procedure)
+- **Ctrl+Shift+F5**: Restart debugging session
+
+### Problem Diagnosis
+- **Ctrl+Shift+M**: Open Problems panel to view AL compilation errors
+- **F8**: Go to next error/warning in current file
+- **Shift+F8**: Go to previous error/warning in current file
+- **Ctrl+Shift+U**: Open Output panel for AL compilation details
+
+## Customization & Productivity
+
+### Workspace Management
+- **Ctrl+Shift+E**: Focus file explorer (AL object tree)
+- **Ctrl+Shift+F**: Global search across AL workspace
+- **Ctrl+Shift+H**: Global find and replace across AL files
+- **Ctrl+,**: Open settings for AL extension configuration
+
+### Custom Keybinding Patterns
+Most AL developers customize these common patterns:
+- **AL object creation shortcuts**: Quick access to create new tables, pages, codeunits
+- **Snippet triggers**: Custom shortcuts for frequently used AL code patterns
+- **Build and deploy combinations**: Single-key publishing to sandbox environments
+
+## Best Practices
+
+### Learning Strategy
+Start with 5-7 core shortcuts and add 2-3 new ones weekly until they become automatic. Focus on navigation shortcuts first, then code generation, finally debugging workflows.
+
+### Muscle Memory Development
+Practice shortcuts during routine tasks rather than trying to memorize them separately. The most valuable shortcuts save 3+ seconds per use and occur multiple times per hour.
+
+### Team Consistency
+Establish team standards for essential shortcuts to enable pair programming and knowledge sharing. Document custom keybindings in project documentation.
+
+*Complete shortcut reference: samples/vs-code-shortcuts.md*
+*Keybinding customization: samples/keybindings-json.md*
+*AL extension configuration: sam-coder-index.json#vs-code-setup*

package/embedded-knowledge/domains/seth-security/al-temporary-table-safety.md

@@ -0,0 +1,95 @@
+---
+title: "AL Temporary Table Safety"
+domain: "seth-security"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["temporary-tables", "data-protection", "memory-management", "security"]
+type: "improvement-pattern"
+category: "security"
+pattern_type: "good"
+severity: "high"
+impact_level: "high"
+improvement_suggestion: "Implement secure temporary table handling to prevent data leakage and ensure proper cleanup"
+implementation_steps: ["validate-data-scope", "implement-secure-cleanup", "test-isolation"]
+validation_criteria: ["secure-data-handling", "proper-memory-cleanup"]
+technical_areas: ["al-code", "data-management"]
+samples: "samples/al-temporary-table-safety.md"
+---
+
+# AL Temporary Table Safety
+
+## Overview
+
+Temporary tables in AL provide in-memory data processing capabilities but require careful security considerations to prevent data leakage, unauthorized access, and memory management issues. Proper implementation ensures data protection while leveraging temporary table performance benefits.
+
+**Key Principle**: Temporary tables must be properly scoped, cleared, and protected to prevent sensitive data exposure across user sessions or security contexts.
+
+## Strategic Framework
+
+### Data Isolation Requirements
+**Session Isolation**: Temporary tables must not leak data between user sessions
+**Permission Boundaries**: Temporary table data access respects underlying table permissions
+**Memory Cleanup**: Sensitive data in temporary tables requires explicit clearing
+**Scope Management**: Temporary tables should have minimal necessary lifetime
+
+### Security Context Preservation
+Temporary tables inherit security context from their source data but require additional protection when crossing procedure boundaries or user contexts.
+
+### Data Protection Lifecycle
+1. **Creation**: Secure initialization with appropriate permissions
+2. **Population**: Controlled data access respecting source permissions
+3. **Processing**: Secure manipulation within authorized scope
+4. **Cleanup**: Explicit clearing of sensitive temporary data
+
+## Architecture Focus
+
+### Memory Security
+**Data Residue Prevention**: Explicitly clear temporary tables containing sensitive information
+**Scope Limitation**: Keep temporary table lifetime as short as possible
+**Access Control**: Implement proper access controls for temporary table procedures
+**Audit Considerations**: Log access to temporary tables containing sensitive data when required
+
+### Permission Integration
+Temporary tables don't automatically inherit all security restrictions of their source tables. Additional validation may be required for sensitive operations.
+
+### Cross-Context Safety
+When passing temporary tables between procedures or objects, ensure security context is properly maintained and validated.
+
+## Best Practices
+
+### Secure Initialization
+- **Permission Validation**: Verify user permissions for underlying data before populating temporary tables
+- **Data Filtering**: Apply appropriate filters based on user security context
+- **Minimal Data**: Include only necessary fields and records in temporary tables
+- **Clear Purpose**: Document temporary table purpose and expected data sensitivity
+
+### Lifecycle Management
+- **Explicit Clearing**: Clear temporary tables containing sensitive data after use
+- **Scope Control**: Limit temporary table accessibility to minimum required procedures
+- **Error Handling**: Ensure temporary table cleanup occurs even in error scenarios
+- **Resource Management**: Monitor temporary table memory usage in high-volume scenarios
+
+### Data Protection Patterns
+- **Sensitive Data Identification**: Clearly identify and mark temporary tables containing sensitive information
+- **Access Logging**: Log temporary table access for sensitive data when required for compliance
+- **Encryption Consideration**: Consider additional protection for highly sensitive temporary data
+- **Cleanup Verification**: Implement verification that sensitive temporary data is properly cleared
+
+### Error Scenario Handling
+- **Finally Blocks**: Use try-finally patterns to ensure cleanup in error scenarios
+- **Exception Safety**: Maintain data protection even when exceptions occur
+- **Rollback Procedures**: Implement proper rollback for partially processed temporary data
+- **Recovery Mechanisms**: Design recovery procedures for temporary table corruption scenarios
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Persistent Temporary Data**: Failing to clear sensitive temporary table data after use
+- **Permission Bypass**: Using temporary tables to circumvent normal data access controls
+- **Cross-Session Leakage**: Temporary table data accessible across user sessions
+- **Uncontrolled Scope**: Temporary tables accessible from unauthorized code contexts
+
+Using temporary tables to access data that users shouldn't normally see violates security principles and may expose sensitive information inappropriately.
+
+*Related patterns: al-data-isolation.md, al-memory-management.md*
+*Implementation examples: see samples/al-temporary-table-safety.md*

package/embedded-knowledge/domains/seth-security/api-permission-model.md

@@ -0,0 +1,115 @@
+---
+title: "API Page Permission Model"
+domain: "seth-security"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["api-permissions", "access-control", "security"]
+samples: "samples/api-permission-model.md"
+---
+# API Page Permission Model
+
+## Overview
+
+API Pages in Business Central implement a comprehensive permission model that controls access to data and operations through OData endpoints. Understanding this permission model is essential for implementing secure API solutions that properly protect business data.
+
+The permission system operates at multiple levels including page access, table permissions, field-level security, and operation-specific restrictions. Each level contributes to the overall security posture of API implementations.
+
+Proper permission configuration ensures API consumers can only access authorized data and perform permitted operations, while maintaining system security and compliance requirements.
+
+## Page-Level Access Control
+
+API Page access requires explicit permissions through the standard BC permission system. Users or service accounts accessing API endpoints must have appropriate permissions assigned through permission sets.
+
+Page permissions control whether an API endpoint is accessible to a particular user or service account. Without proper page permissions, API requests will be rejected with authentication errors.
+
+Consider the principle of least privilege when assigning page permissions. Grant only the minimum access required for legitimate API operations to reduce security exposure.
+
+## Table Permission Requirements
+
+API Pages inherit table permissions from their source tables, requiring appropriate read, insert, modify, or delete permissions based on supported operations. Table permissions directly control what data operations are available through the API.
+
+Different permission levels enable different OData operations. Read permissions enable GET operations, while insert permissions enable POST operations for creating new records through the API.
+
+Table permissions may be filtered or restricted based on field values, enabling row-level security implementations. This allows fine-grained control over which records are accessible through API endpoints.
+
+## Field-Level Security
+
+Individual field permissions control which table fields are accessible through API Pages. Fields without appropriate permissions are automatically excluded from API responses and cannot be modified through API operations.
+
+Field security enables selective data exposure through APIs without requiring separate table structures. Sensitive fields can be protected while allowing access to general business data.
+
+Consider field permission inheritance and dependencies when designing API security models. Related fields or calculated fields may require additional permission considerations.
+
+## Operation-Specific Permissions
+
+Different OData operations require specific permission configurations. GET operations require read permissions, POST operations require insert permissions, and PATCH/PUT operations require modify permissions.
+
+DELETE operations through API Pages require explicit delete permissions on the source table. Not all API implementations need to support delete operations, allowing for read-only or append-only API designs.
+
+Permission requirements may vary based on API operation complexity. Operations that modify multiple tables or trigger business logic may require additional permission grants.
+
+## Service Account Security
+
+API integrations typically use dedicated service accounts with restricted permission sets designed for specific integration scenarios. Service accounts should follow security best practices for automated system access.
+
+Service account permissions should be regularly reviewed and maintained to ensure they remain appropriate for current integration requirements. Unused permissions should be removed to minimize security exposure.
+
+Consider using Azure AD application registrations for API authentication when possible. This provides better audit trails and credential management compared to traditional BC user accounts.
+
+## Authentication and Authorization Flow
+
+API Page security integrates with BC authentication mechanisms including basic authentication, OAuth 2.0, and Azure AD authentication. Choose authentication methods appropriate for security requirements and integration scenarios.
+
+Authorization occurs after successful authentication, verifying that the authenticated account has appropriate permissions for the requested API operations. Failed authorization results in access denied responses.
+
+Implement proper error handling for authentication and authorization failures to provide appropriate feedback to API consumers while avoiding security information disclosure.
+
+## Multi-Tenancy Security Considerations
+
+In multi-tenant environments, permission models must ensure proper tenant isolation. API consumers should only access data within their authorized tenant boundaries.
+
+Permission sets may need tenant-specific configurations to address different security requirements across tenants. Consider centralized permission management approaches for consistency.
+
+Monitor cross-tenant access patterns to detect potential security issues or configuration errors that could compromise tenant data isolation.
+
+## Compliance and Audit Requirements
+
+API permission models must support compliance requirements including data access auditing, permission change tracking, and access review processes.
+
+Implement proper logging for API access patterns to support security monitoring and compliance reporting. Log both successful and failed access attempts for comprehensive audit trails.
+
+Consider implementing automated permission review processes to ensure API access remains appropriate over time and changes in business requirements.
+
+## Dynamic Permission Scenarios
+
+Some API implementations require dynamic permission evaluation based on data values, business logic, or contextual factors beyond standard BC permission sets.
+
+Dynamic permissions may be implemented through custom business logic in API Pages or source tables. This enables complex security scenarios but requires careful implementation to avoid security vulnerabilities.
+
+Consider performance impact of dynamic permission evaluation, especially for high-volume API scenarios where permission checks could become performance bottlenecks.
+
+## Security Monitoring and Alerting
+
+Implement monitoring for unusual API access patterns that might indicate security issues or unauthorized access attempts. Monitor both successful and failed API requests for security indicators.
+
+Set up alerting for permission-related errors or unusual access patterns that require investigation. Early detection of security issues enables rapid response and mitigation.
+
+Regular security reviews should include analysis of API access patterns and permission effectiveness to identify optimization opportunities and potential security improvements.
+
+## Integration with External Security Systems
+
+API permission models may need to integrate with external security systems, identity providers, or access management solutions. Plan integration approaches that maintain security effectiveness.
+
+Consider federated identity scenarios where API consumers authenticate through external systems but require BC permissions for data access. Implement proper token validation and permission mapping.
+
+External security integration should maintain audit trails and support compliance requirements while providing seamless authentication experiences for API consumers.
+
+## Best Practices
+
+Follow the principle of least privilege when designing API permission models. Grant only the minimum permissions required for legitimate API operations.
+
+Implement defense in depth through multiple security layers including authentication, authorization, field-level security, and business logic validation.
+
+Document permission requirements and security assumptions for API implementations. This documentation supports security reviews and helps maintain consistent security practices.
+
+Regularly review and validate API permission configurations to ensure they remain appropriate for current business requirements and security standards.

package/embedded-knowledge/domains/seth-security/istemporary-safeguard-pattern.md

@@ -0,0 +1,78 @@
+---
+title: "IsTemporary Table Safeguard Pattern for Data Protection"
+domain: "seth-security"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["data-protection", "temporary-tables", "safeguards", "data-integrity", "error-prevention"]
+prerequisites: ["al-tables", "data-access-patterns"]
+---
+# IsTemporary Table Safeguard Pattern for Data Protection
+
+## Overview
+
+The IsTemporary table safeguard pattern prevents accidental data modifications to permanent database tables by validating table state before performing destructive operations, protecting against data corruption and unintended database changes.
+
+**Safety Principle**: Always verify table temporariness before bulk operations, modifications without keys, or destructive actions to prevent permanent data loss.
+
+## Strategic Framework
+
+### Data Protection Strategy
+- **Validation gates**: Check IsTemporary before bulk insert/modify/delete operations
+- **Operation scoping**: Restrict dangerous operations to temporary tables only
+- **Error prevention**: Fail fast when permanent tables are used inappropriately
+- **Developer safety**: Provide clear feedback for incorrect table usage patterns
+
+### Risk Mitigation Approach
+- **Bulk operation safety**: Prevent mass data changes to production tables
+- **Development protection**: Guard against test code affecting live data
+- **Integration safety**: Validate table state in data import/export routines
+- **Maintenance protection**: Ensure cleanup operations target appropriate tables
+
+## Architecture Patterns
+
+### Precondition Validation
+Implement validation checks that verify table temporariness before executing operations that could affect large data sets or bypass normal business logic constraints.
+
+### Defensive Programming Pattern
+Build safeguards into reusable procedures and functions that work with table data, ensuring they cannot accidentally corrupt permanent database tables.
+
+### Operation Context Awareness
+Design data manipulation routines that understand whether they're working with temporary or permanent data and adjust their behavior accordingly.
+
+## Implementation Guidelines
+
+### Validation Implementation
+- **Early validation**: Check IsTemporary at procedure entry points
+- **Clear error messages**: Provide specific feedback about safeguard violations
+- **Conditional operations**: Use IsTemporary state to determine operation safety
+- **Logging integration**: Record safeguard violations for debugging and auditing
+
+### Bulk Operation Protection
+Implement mandatory IsTemporary checks before DeleteAll, ModifyAll, and other bulk operations that could affect large numbers of records without individual validation.
+
+### Development Workflow Safety
+Build IsTemporary validation into development and testing procedures to prevent test code from accidentally targeting production tables.
+
+## Best Practices
+
+### Safeguard Implementation
+- **Consistent application**: Apply safeguards uniformly across similar operations
+- **Performance consideration**: Balance safety checks with execution efficiency
+- **Clear documentation**: Document why and when safeguards are required
+- **Team training**: Ensure developers understand safeguard importance and usage
+
+### Error Handling Strategy
+Provide clear, actionable error messages when safeguard violations occur, helping developers understand both the problem and the correct solution.
+
+### Code Review Integration
+Include IsTemporary safeguard checks in code review checklists, especially for procedures that manipulate table data in bulk.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Skipping validation**: Bypassing IsTemporary checks for "performance" reasons
+- **Silent failures**: Not providing clear error messages when safeguards trigger
+- **Inconsistent application**: Using safeguards in some functions but not others
+- **Late validation**: Checking IsTemporary after beginning data modifications
+- **Generic error handling**: Non-specific error messages that don't help debugging
+