Fix dspy.GEPA(max_steps=...) crash on DSPy 3.2+

[0xDecay]

Problem

evolve_skill.py:157 calls dspy.GEPA(metric=..., max_steps=iterations). DSPy 3.2 removed max_steps in favor of max_metric_calls (total metric evaluations across optimization).

Since pyproject.toml pins dspy>=3.0.0 with no upper bound, a fresh pip install -e . on a clean venv pulls dspy==3.2.1 and the first GEPA call crashes:

TypeError: GEPA.__init__() got an unexpected keyword argument 'max_steps'

The downstream MIPROv2 fallback then crashes too (missing optuna), so the whole pipeline fails.

Fix

Swap max_steps=iterations for max_metric_calls=max(iterations * 10, 30):

• 10x is a reasonable equivalent budget (one old-API GEPA step ~= ~10 metric evaluations under the new model)
• Floor at 30 so --iterations 1 and --iterations 2 don't trivialize the optimization

Testing

Reproduced and verified on:

• DSPy 3.2.1
• Python 3.12.3 (Ubuntu 24.04)
• anthropic/claude-sonnet-4-6 (optimizer) + anthropic/claude-haiku-4-5 (eval)
• --iterations 3 --eval-source synthetic against a real SKILL.md

Optimization now runs to completion (148s, 11 candidates scored, best 68.75) and constraint validation fires correctly.

Notes

• Real fix is probably to support both APIs via inspect.signature detection, but this single-line swap is the minimum change to unblock the 3.2 path. Happy to expand to a version-aware shim if you'd prefer.
• DSPy 3.2 also moved GEPA behind dspy.experimental — the existing MIPROv2 fallback handles this gracefully (once optuna is installed). May be worth adding optuna as an explicit dep.