feat: add bounded runtime readiness probes#47
Merged
Conversation
This was referenced Jul 10, 2026
ebarti
force-pushed
the
agent/stack-06-task-support
branch
from
a7b1e80 to
38e9f7c
Compare
ebarti
added a commit
that referenced
this pull request
Jul 10, 2026
## What - adds side-effect-free `TaskSupportReport` preflight for built-in and third-party runtimes - keeps `AgentRuntime` migration-compatible through the optional `TaskSupportProvider` protocol - reports granular task capability gaps, configured model allow-list mismatches, and static Antigravity constraints - makes built-in dispatch consume the same support report used by public preflight - adds a machine-readable compatibility manifest tied to `pyproject.toml` and exact `uv.lock` versions ## Why Capability booleans and per-adapter rejection branches had drifted apart. Callers could not discover all incompatible fields before starting a run, provider-specific rules were delayed until dispatch, and compatibility ranges/tested runtime binaries existed only as duplicated prose and package metadata. ## Root cause Task support was encoded in several imperative adapter paths rather than one additive preflight contract. An initial implementation also made `validate_task` mandatory on `AgentRuntime`, which would have broken existing structural third-party runtimes; this PR uses an optional extension plus a declared-capability fallback instead. ## Checks - `ruff check src tests` - `mypy` - `pytest -q --cov=agent_runtime_kit --cov-report=term-missing --cov-fail-under=85` (340 passed, 3 skipped; 90.86%) - installed SDK contracts: 19 passed - `uv lock --check` - `uv build` ## Stack - Base: #45 - Next: #47
ebarti
force-pushed
the
agent/stack-07-runtime-readiness
branch
from
b18fd9b to
4bcfab9
Compare
ebarti
added a commit
that referenced
this pull request
Jul 10, 2026
## What - delegates the no-override model choice to each provider instead of pinning library-owned names - preserves one precedence chain: task field > legacy metadata > constructor override > provider-native - omits vendor model kwargs when selection is provider-native - records `model_source` on every provider result and records `model` only when known - keeps `default_model=` as an explicit migration override - makes configured model allow-lists fail closed when provider-native selection cannot be verified ## Why Hard-coded adapter defaults age faster than the SDK and can override supported provider configuration. The SDK-evolution docs already described Claude and Antigravity as provider-native, but the adapters silently forced stale model names. ## Root cause Model resolution treated the library constructor default as mandatory rather than an optional override, and result metadata could not distinguish task, metadata, constructor, and provider-native selection. ## Compatibility This is an intentional pre-1.0 behavior change. Applications that need the prior pin can pass the same value through `default_model=`; task and metadata overrides keep their existing precedence. ## Checks - `ruff check src tests` - strict `mypy` - full all-extras suite: 396 passed, 3 skipped - model-policy coverage run: 356 passed, 3 skipped; 91.00% coverage - installed SDK contracts: 23 passed - `uv lock --check` - `uv build` ## Stack - Base: #47 - Next: #49
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
RuntimeReadiness,ReadinessStatus, optionalRuntimeReadinessProvider, and boundedcheck_readiness()Why
availability()mixed package presence with potentially blocking credential discovery. In particular, Antigravity could read files or contact Google metadata services from a synchronous setup check, while Claude/Codex package success was easy to misread as execution readiness.Root cause
One diagnostic type represented two different questions: “is the adapter installed?” and “is enough setup present to attempt a provider call?” Provider authentication mechanisms also differ in how safely they can be probed.
Semantics
availability(): synchronous, package-only, side-effect-freeREADY_TO_ATTEMPT: setup signal confirmed, not a guarantee of executionNOT_READY: a concrete package/credential problem was establishedINDETERMINATE: provider-owned/local chains, timeout, or probe failure require caller policyAgentRuntimeprotocol is unchangedChecks
ruff check src testsmypyuv lock --checkuv buildplus wheel/sdist content inspectionStack