Redesign allocation strategy feature hierarchy for true mutual exclusivity

[avrabe]

Problem Description

Current allocation strategies (static, bounded, managed, std) share capability features, preventing true mutual exclusivity and causing compilation conflicts.

Current Architecture Issues

• Shared capability features between strategies cause circular dependencies
• Type selection conflicts due to overlapping feature conditions
• Mutual exclusivity not properly enforced

Proposed Solution

Implement strategy-specific capability features:

# Strategy Level (mutually exclusive)
static-allocation-core = ["static-memory-layout", "static-capacity-limits"]
bounded-allocation-core = ["bounded-runtime-checks", "bounded-capacity-limits"] 
managed-allocation-core = ["managed-monitoring"]
std-allocation-core = ["std-collections", "std-dynamic-alloc"]

Implementation Plan

1. Create strategy-specific capability features
2. Remove cross-strategy dependencies
3. Implement clear capability inheritance
4. Update prelude system for clean type selection

Acceptance Criteria

• Each allocation strategy has independent capability features
• No shared features between strategies
• Clean type selection based on strategy precedence
• All safety levels work correctly with new architecture

Dependencies

Blocked by Issue #106 (critical fix must be completed first)

Priority

P1 - High priority architecture improvement

[avrabe]

🚀 STARTING PHASE 2: Architecture Redesign

Moving this issue to In Progress. Beginning implementation of strategy-specific capability system with clean separation between allocation strategies.

Goals for Phase 2:

1. Implement strategy-specific capability features
2. Remove cross-strategy dependencies completely
3. Clean up prelude type selection system
4. Validate improved architecture

Current Status: In Progress ⚠️

[avrabe]

✅ PHASE 2 COMPLETED - Architecture Redesign

Successfully implemented a clean strategy-specific capability system with proper separation between allocation strategies.

Changes Made

1. Strategy-Specific Capability Namespaces

   • Static allocation: , ,
   • Bounded allocation: , , ,
   • Managed allocation: ,
   • Standard allocation: ,

2. Eliminated Cross-Strategy Dependencies

   • Each allocation strategy now has independent capability features
   • No shared capability features between mutually exclusive strategies
   • Clean separation prevents circular dependencies

3. Updated Type Selection System

   • Updated prelude.rs to use new strategy-specific features
   • Maintained proper precedence: std-allocation > managed-dynamic-alloc > bounded-allocation > static-allocation
   • Legacy feature compatibility maintained during transition

4. Enhanced Safety Validation

   • Updated safety_features.rs to recognize new capability features
   • Fixed feature dependency validation to use strategy-specific names
   • Maintained compile-time safety constraint enforcement

Architecture Benefits

• ✅ True Mutual Exclusivity: Allocation strategies are now completely independent
• ✅ Clear Capability Ownership: Each strategy owns its capability features
• ✅ Extensible Design: Easy to add new allocation strategies without conflicts
• ✅ Maintainable Codebase: Clean separation makes the system easier to understand and modify

Test Results ✅

All safety levels continue to compile successfully with the new architecture:

• ✅ ISO 26262: QM, ASIL-A, ASIL-B, ASIL-C, ASIL-D
• ✅ DO-178C: DAL-E, DAL-D, DAL-C, DAL-B, DAL-A
• ✅ IEC 61508: SIL-1, SIL-2, SIL-3, SIL-4
• ✅ IEC 62304: Class A, Class B, Class C
• ✅ All other safety standards working correctly

Legacy Compatibility

The redesign maintains backward compatibility through deprecated feature aliases:

• →
• →
• →

Status: COMPLETE ✅

Phase 2 architecture redesign is now complete. The safety system has a clean, maintainable architecture with proper separation of concerns. Ready for Phase 3: Comprehensive validation and testing.

[avrabe]

✅ Completed in commit 695eb95

Architecture redesign phase successfully completed. Implemented clean four-layer safety architecture with strategy-specific capability namespaces.

Architecture improvements:

• Layer 1: Memory Management Strategy (static/bounded/managed/std-allocation)
• Layer 2: Safety Feature Capabilities (strategy-specific namespaces)
• Layer 3: Safety Standards (ISO 26262, DO-178C, IEC 61508, etc.)
• Layer 4: Safety Integrity Levels (ASIL-A through D, DAL-A through E, etc.)

Technical changes:

• Updated wrt-foundation/Cargo.toml with complete four-layer feature architecture
• Implemented safety-level-aware type selection in prelude.rs
• Added strategy-specific capability features preventing conflicts
• Clean feature propagation in wrt-component and wrt-runtime

Validation:
All 6 safety standards compile with all integrity levels. Ready for Phase 3 comprehensive testing.