[v2] Implement InvariantEvolver

[SHAURYASANYAL3]

Phase 6: Invariant Evolution

The Context

Static invariants are powerful, but they can produce false positives on novel, safe workflows. The system needs a feedback loop to automatically tune its boundaries.

Tasks

• Implement InvariantEvolver class.
• Track blocked actions and near-misses during execution.
• Provide APIs (suggest_relaxation(invariant), suggest_tightening(invariant)) that can adjust threshold parameters dynamically based on historical false-positive markers.
• (Optional) Persist evolved invariant configurations to disk for future sessions.

Part of Epic #651

[prasiddhi-105]

Hii please assign this issue to me under SSOC26!!

[SHAURYASANYAL3]

@prasiddhi-105 Thanks for volunteering! Since you're a newer contributor, we ask that you briefly outline your proposed approach or solution for this issue before we formally assign it. What's your plan?

[prasiddhi-105]

@prasiddhi-105 Thanks for volunteering! Since you're a newer contributor, we ask that you briefly outline your proposed approach or solution for this issue before we formally assign it. What's your plan?

Thank you, @SHAURYASANYAL3 Here's my planned approach:

• I'll first review the existing invariant-related components to understand how invariants are currently defined, evaluated, and managed within the runtime.
• I'll implement the InvariantEvolver class with a clear separation between data collection (execution history) and evolution logic.
• I'll track blocked actions and near-miss events during execution, recording only the metadata necessary to identify recurring false positives without impacting the normal execution path.
• I'll implement the suggest_relaxation(invariant) and suggest_tightening(invariant) APIs to generate threshold adjustment recommendations based on accumulated historical false-positive markers, ensuring recommendations are driven by consistent patterns rather than isolated events.
• I'll keep the implementation modular so future evolution strategies or heuristics can be incorporated without changing the public API.
• If appropriate for the current architecture, I'll also implement the optional persistence layer to save evolved invariant configurations for reuse across future sessions while maintaining backward compatibility.
• Finally, I'll verify that the evolution logic behaves deterministically and does not interfere with existing invariant evaluation.

Please let me know if there are any project-specific design preferences or conventions you'd like me to follow before I begin.

[SHAURYASANYAL3]

Your approach looks solid. You're officially assigned! Since our contributor rules limit everyone to 2 active issues at a time, you are currently at your cap. Let us know if you need any pointers while implementing.