v0.1.0-rc.3

AgentAPI Doctor v0.1.0-rc.3

Summary

This release candidate makes Quick Check output budgets explicit per scenario
instead of applying one 64-token value to every request. The OpenAI Chat and
Responses terminal-status checks now request 512 output tokens so
default-thinking models have more room to reach a natural terminal state. The
other ten structural, envelope, and stream-lifecycle checks remain at 64.

A four-request Chat or Responses run therefore requests at most 704 output
tokens; Anthropic Messages remains at 256 because its selected checks do not
require a natural model stop. Default plans reserve those exact requested
amounts before network access. Provider-reported reasoning-token details are
included in truncation diagnostics, and absent provider usage is recorded as
unknown rather than as an observed zero. For budget enforcement, an unknown
output-token value is conservatively charged at the requested reservation and
remains marked unknown. Input-token usage also remains unknown because Doctor
has no provider-neutral input estimate; neither field is presented as
provider-reported consumption.

The request count remains four, retries remain disabled, and Doctor does not
disable thinking or branch on provider/model names. The pinned OpenAI Python SDK
loopback reproducer from rc.2 remains unchanged.

Compatibility and breaking changes

The CLI commands, configuration shape, report schema, stable exit codes, and
release archive set are unchanged. Output-limit termination remains
INCONCLUSIVE and never becomes a target finding merely because a provider used
the requested budget.

If a completed response pushes cumulative accounting beyond the approved run
budget, Doctor preserves the target assertion verdict but marks the aggregate
run INCONCLUSIVE with exit 4 and a durable run_budget_exhausted condition. A
last-scenario run-budget exhaustion can no longer produce a successful
aggregate run. A provider can still exceed one request estimate without
exhausting the cumulative run budget; that reservation overshoot remains
visible in accounting and is not silently redefined as provider incompatibility.

The built-in driver, evaluator, protocol pack, profile, resolver, and producer
identities advance from 0.1.0-candidate.2 to 0.1.0-candidate.3. Request
bodies and token reservations are part of the digest-bound execution contract,
so rc.2 and rc.3 Quick Check baselines are intentionally incomparable. This is
a pre-1.0 evidence-identity change, not a silent migration of old results.

Existing persisted plans and reports remain readable. The Requirement Catalog's
larger candidate metadata set is not regenerated by this change; its scenario
budgets are offline catalog metadata and are not the four runtime request
bodies used by Quick Check.

Migration

Replace an older binary with the exact archive for this release and confirm
doctor version --json reports 0.1.0-rc.3. Keep old reports when they are
needed as historical observations, but recapture any named baseline before
comparing it with a new rc.3 run. Do not edit an rc.2 baseline or digest to make
it appear compatible with the new built-in profile.

No configuration migration is required. The pinned real-SDK reproducer still
uses CPython 3.12.12 and OpenAI Python 2.38.0 on Linux amd64 with the same
wheel-only hash lock. Registry, reference-server, OCI, Homebrew, Scoop,
composite Action, reusable workflow, Python package, and hosted-service files
remain unpublished candidates rather than supported rc.3 channels.

Known issues

• A 512-token terminal-status request is a bounded default, not a guarantee
  that every reasoning model will finish. A model with a larger default
  reasoning budget may still produce an honest INCONCLUSIVE result.
• Provider request fields are not client-enforced cost ceilings. A provider can
  reject or ignore them; reported usage can also be absent or use
  provider-specific accounting semantics.
• Doctor does not inject a vendor-specific setting to disable thinking, infer a
  capability from a model name, or retry with a larger hidden request.
• The ordinary endpoint PASS still covers four selected raw-HTTP checks for one
  exact endpoint, model, and artifact set. It is not complete SDK, Agent, or
  vendor compatibility.
• The pinned SDK command remains a frozen loopback regression baseline, not an
  arbitrary-endpoint SDK driver. It does not run a proxy, Agent loop, tool
  execution, or vendor service.
• Redaction is not anonymization. Review structured model content, tool
  arguments, reports, and evidence bundles before sharing them.
• There is no project-operated hosted verifier, public Registry, compatibility
  matrix, telemetry service, verified external adopter set, or long-term
  support commitment.

Support window

Support for this release candidate begins when its GitHub Release becomes
public and ends on 2026-08-13 or when a newer release candidate or stable
release supersedes it, whichever occurs first. Security reports remain welcome
after that date, but fixes may require upgrading to a newer release.

Publication of v0.1.0-rc.3 supersedes the v0.1.0-rc.2 release-candidate support
window. The immutable rc.1 and rc.2 artifacts remain available for historical
reproduction.

Verification

The release tag identifies the exact source commit. doctor version --json
inside every archive reports the release version and that full commit ID.

Product tests freeze the twelve per-scenario request values, the 704/256 default
reservations, pre-network token-budget enforcement, output-limit INCONCLUSIVE
semantics, reasoning-detail diagnostics, conservative unknown-usage
accounting, and last-scenario run-budget exhaustion aggregation. The
complete local gate includes all Go tests, race tests, schema/catalog checks,
documentation links, integration tests, static analysis, and vendored-license
checks.

The tag workflow reconstructs the hash-locked Python environment and repeats
all four pinned real-SDK cases twice. It then builds six native Doctor archives,
publishes checksums.txt and one SPDX JSON SBOM, signs the checksum manifest
with Sigstore keyless signing, and records GitHub build-provenance attestations
for every file. Linux amd64, macOS arm64, and Windows amd64 runners verify the
asset set, archive identity, version, and credential-free demo before and
after publication; Linux also exercises the fixed-tag installer.

The canonical artifact-verification commands and certificate identity are in
docs/operations/release-verification.md. A failed workflow does not justify a
compatibility or publication claim.