Phase 1: Refactor wrt-foundation Cargo.toml for Four-Layer Safety Architecture

[avrabe]

Overview

Refactor the core wrt-foundation/Cargo.toml feature definitions to implement the four-layer safety architecture, removing mixed allocation/safety level features and establishing clean separation of concerns.

Parent Issue: #101

Current Problems

• Mixed features like asil-b = ["runtime-bounds-checking", "basic-monitoring", "bounded-collections"]
• No clear separation between memory strategies and safety levels
• Automotive-only focus, no multi-standard support

Required Changes

1. Memory Management Strategy Features (Layer 1)

# Pure deterministic allocation (highest safety levels)
static-allocation = [
    "no-runtime-allocation",
    "compile-time-memory-layout", 
    "compile-time-capacity-limits"
]

# Bounded deterministic allocation (medium safety levels)
bounded-allocation = [
    "alloc",
    "runtime-bounds-checking",
    "memory-budget-enforcement",
    "bounded-collections"
]

# Managed dynamic allocation (lower safety levels)
managed-allocation = [
    "alloc", 
    "dynamic-allocation",
    "basic-monitoring"
]

# Unqualified allocation (non-safety-critical only)
std-allocation = [
    "std",
    "dynamic-allocation"
]

2. Safety Feature Capabilities (Layer 2)

# Memory safety capabilities
compile-time-capacity-limits = []
runtime-bounds-checking = []
memory-budget-enforcement = []
stack-overflow-protection = []
buffer-overflow-protection = []

# Execution safety capabilities
control-flow-integrity = []
instruction-validation = []
execution-monitoring = []
deterministic-timing = []

# Data integrity capabilities
redundant-computation = []
error-detection-codes = []
checksums-verification = []
data-flow-monitoring = []

# Verification capabilities
formal-verification-required = ["dep:kani-verifier"]
mathematical-proofs = ["formal-verification-required"]
coverage-analysis = []
fault-injection-testing = []

# Isolation capabilities
memory-isolation = ["memory-budget-enforcement"]
process-isolation = ["memory-isolation"]  
hardware-isolation = ["process-isolation"]

3. Safety Standards Support (Layer 3)

# International safety standards
iso-26262 = [
    "automotive-hazard-analysis",
    "asil-decomposition-support",
    "functional-safety-concept"
]

do-178c = [
    "structural-coverage-analysis", 
    "requirements-traceability",
    "configuration-management"
]

iec-61508 = [
    "systematic-capability", 
    "random-hardware-failures",
    "common-cause-failures"
]

iec-62304 = [
    "risk-management-process",
    "software-lifecycle-process", 
    "clinical-evaluation"
]

en-50128 = [
    "railway-specific-hazards",
    "tolerable-hazard-rate",
    "systematic-failures"
]

iso-25119 = [
    "agricultural-machinery-safety",
    "operator-protection",
    "environmental-conditions"
]

4. Safety Integrity Levels (Layer 4)

# ISO 26262 - Automotive Safety Integrity Levels
qm = ["managed-allocation"]
asil-a = ["managed-allocation", "basic-monitoring"]  
asil-b = ["bounded-allocation", "runtime-bounds-checking"]
asil-c = ["bounded-allocation", "memory-isolation", "control-flow-integrity"] 
asil-d = ["static-allocation", "redundant-computation", "mathematical-proofs", "hardware-isolation"]

# DO-178C - Design Assurance Levels (Aerospace)
dal-e = ["managed-allocation"]
dal-d = ["managed-allocation", "basic-monitoring"]
dal-c = ["bounded-allocation", "execution-monitoring"] 
dal-b = ["bounded-allocation", "formal-verification-required", "coverage-analysis"]
dal-a = ["static-allocation", "mathematical-proofs", "redundant-computation"]

# IEC 61508 - Safety Integrity Levels (Industrial)
sil-1 = ["managed-allocation", "basic-monitoring"]
sil-2 = ["bounded-allocation", "error-detection-codes"] 
sil-3 = ["bounded-allocation", "redundant-computation", "formal-verification-required"]
sil-4 = ["static-allocation", "mathematical-proofs", "fault-injection-testing"]

# IEC 62304 - Medical Device Safety Classes
class-a = ["managed-allocation", "basic-monitoring"]
class-b = ["bounded-allocation", "error-detection-codes"]
class-c = ["static-allocation", "redundant-computation"]

# EN 50128 - Railway Safety Integrity Levels  
railway-sil-0 = ["managed-allocation"]
railway-sil-1 = ["managed-allocation", "basic-monitoring"]
railway-sil-2 = ["bounded-allocation", "error-detection-codes"]
railway-sil-3 = ["bounded-allocation", "redundant-computation", "formal-verification-required"] 
railway-sil-4 = ["static-allocation", "mathematical-proofs", "fault-injection-testing"]

# ISO 25119 - Agricultural Performance Levels
agpl-a = ["managed-allocation", "basic-monitoring"]
agpl-b = ["managed-allocation", "error-detection-codes"]
agpl-c = ["bounded-allocation", "redundant-computation"]
agpl-d = ["bounded-allocation", "formal-verification-required"]
agpl-e = ["static-allocation", "mathematical-proofs"]

Implementation Tasks

• Back up current wrt-foundation/Cargo.toml
• Remove existing mixed allocation/safety features (lines 62-87)
• Add Layer 1: Memory Management Strategy features
• Add Layer 2: Safety Feature Capabilities (composable)
• Add Layer 3: Safety Standards Support
• Add Layer 4: Safety Integrity Levels per standard
• Update legacy compatibility features as deprecated
• Add clear comments explaining the four-layer architecture
• Validate feature dependencies and prevent circular references

Testing Requirements

• Compile test with various feature combinations
• Verify no std library dependencies leak into safety-critical features
• Test that static-allocation + asil-d works without runtime allocation
• Test that bounded-allocation + sil-3 provides proper bounds checking
• Ensure existing ASIL compliance tests still pass

Acceptance Criteria

• Clean four-layer feature architecture implemented
• No mixed allocation/safety level features remain
• All 6 international safety standards supported
• Clear qualification constraints documented
• Existing functionality preserved through legacy compatibility features
• Feature dependency graph is acyclic and logical

Notes

• Preserve existing safety_system.rs multi-standard infrastructure
• Legacy features marked as deprecated with clear migration path
• New architecture must support all existing ASIL compliance requirements
• Documentation should clearly explain qualification constraints for each layer