feat(harness): add Python provider preflight#756
Conversation
Performance
✓ No regressions detected |
AbirAbbas
left a comment
There was a problem hiding this comment.
Ran a multi-agent review over this (PR-AF on AgentField, findings hand-verified before posting). The Python preflight/doctor implementation itself is solid and well-tested — the issues are all at the edges: docs promising APIs that don't exist yet, and the Go CLI's provider table disagreeing with the Python SDK about what claude-code even is. Three inline comments below.
One structural suggestion, no action required: the provider spec table now lives twice (sdk/python/agentfield/harness/_availability.py and control-plane/internal/cli/harness_doctor.go) with no sync check — a tiny parity test (or generating one from the other) would stop them drifting further, which is exactly how the claude-code divergence below crept in.
santoshkumarradha
left a comment
There was a problem hiding this comment.
Pulled this into a clean clone and reran the new harness coverage locally. go test ./internal/cli/... passed, and the Python harness suite passed under uv run --python 3.12 --extra dev pytest for the new doctor and provider tests.
…, KeyError fallback Address the three unresolved review threads on Agent-Field#756: - docs/harness-providers.md: drop the TypeScript/Go doctor examples — those APIs (agent.harnessDoctor, harness.Doctor) do not exist yet. Document the Python SDK + af CLI surface that actually ships and note TS/Go as planned follow-ups of Agent-Field#685. - control-plane/internal/cli/harness_doctor.go: the claude-code row now mirrors the Python doctor (_doctor.py::_claude_health). It probes a Python interpreter for the claude_agent_sdk pip package (which bundles its own CLI) instead of looking for a global `claude` binary, and hints `pip install 'agentfield[harness-claude]'` instead of npm. Interpreter candidates (python3/python/py) are run-probed so dead launcher stubs are skipped; issues are wrapper_not_installed / python_not_found. - sdk/python/agentfield/harness/_availability.py: provider_unavailable() falls back to a generic ProviderSpec via .get() so providers without a PROVIDER_SPECS entry (claude-code, or any future provider) raise the helpful HarnessProviderUnavailable instead of a bare KeyError. Regression test added for both provider_unavailable and ensure_cli_available. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Maintainer takeover to get this merge-ready — pushed to this branch (thanks for
Verification:
|
📊 Coverage gateThresholds from
✅ Gate passedNo surface regressed past the allowed threshold and the aggregate stayed above the floor. |
📐 Patch coverage gateThreshold: 80% on lines this PR touches vs
✅ Patch gate passedEvery surface whose lines were touched by this PR has patch coverage at or above the threshold. |
|
recheck |
Pull request was closed
Summary
This is the Python-first phase of #685. It adds a reusable harness availability contract and the
af harness doctorpreflight without starting a paid provider run.Related issues
Part of #685.
Changes
harness-allbundle.ProviderHealthreports separating binary/wrapper installation, version, auth signal, usability, install command, and machine-readable issues.Agent.harness_doctor()and theaf harness doctor [--provider ...] [--json]control-plane command.HarnessProviderUnavailableerrors.auth="unknown"represents providers that may use local login state which cannot be proven without a paid liveness probe.Verification
Python tests pass with 94% configured coverage. The Go CLI tests pass. The focused formatter output is empty.
Checklist