Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Template scaffolds stale >=3.0.0 floors for agent-control-evaluators / agent-control-models

The rest of the PR moves in-repo contrib packages onto >=7.5.0 for agent-control-evaluators / agent-control-models, but evaluators/contrib/template/pyproject.toml.template (lines 10-11) still scaffolds new packages at >=3.0.0. Since scripts/contrib_packages.py verify only checks presence of wiring (not floor values), a template-copied package will silently ship metadata claiming compatibility with 3.x while using 7.5.0+ APIs - the failure surfaces at install/import for downstream users, not in CI.

(Posting as a general PR comment rather than inline because those two dependency lines are unchanged context between diff hunks in this PR, so GitHub will not accept an inline review comment there.)

Consider either (a) a literal placeholder like <minimum-compatible-version> so the choice is explicit (and can be grep-guarded), or (b) extending verify_contrib_packages to assert each contrib pyproject's internal floors parse as >=X.Y.Z above a documented minimum. The placeholder approach is cheaper; the verify-extension approach eliminates the drift class.

Addressing #193 (comment): I took the placeholder route here. The contrib template now uses <minimum-compatible-version> for the internal floors, and the template README calls out that authors need to replace it intentionally based on whether the package rides the shared monorepo release train or is maintained independently.

Since I replied on the review threads, I cleaned up a few more things:

• fixed the CI coverage upload path so it passes Codecov an explicit contrib coverage file list instead of relying on a glob
• removed the agent-control-server[galileo] install alias from the Galileo README since this repo does not publish that package in the in-repo release flow
• hardened the release workflow:
  • stage built dists into a stable release-dists/ tree before upload/download
  • publish builtin + contrib evaluator distributions together from one staged directory, so we do not create a bad builtin/contrib ordering hazard
  • keep SDK publish gated on successful evaluator publishing
  • upload GitHub release assets from the staged tree
• added direct tests for the contrib package-version fallback path and tightened those three evaluators to resolve package version through a small helper

I also ran a fresh review loop after that. No new blocking findings came back. The remaining nits are cleanup-level, not merge blockers.