Skip to content

[P1][Contract] Track remaining public client contract gaps #65

Description

@linfangw

Purpose

Track only the remaining public client-contract gaps after the current QVeris API and toolkit releases. This issue is an umbrella for contract alignment, not a place to invent server fields or pre-announce run, eval, or replay commands.

Current public baseline — 2026-07-22

Completed in the toolkit:

  • Public OpenAPI artifacts, generated types, and contract checks are synchronized.
  • Discover exposes why_recommended, capability descriptors, cost class, expected cost, and opt-in routing projections.
  • Inspect exposes current parameter schemas, stats, billing_rule, examples, provider metadata, and capability tags.
  • Call exposes execution_id, success/error state, compact pre-settlement billing when available, and opt-in summary/field projections.
  • Usage history and credits ledger expose final audit and settlement semantics.
  • CLI doctor/init, first-call guidance, and explainable-routing recipes are implemented.
  • Zero-cost probe schema/quote client support is tracked by [Clients] Add zero-cost tools probe support across CLI, MCP, JavaScript, and Python #259 and implemented in feat: add zero-cost tool probe clients #260.

Remaining contract gaps

The following names are not currently declared as public Call/Discover/Inspect fields and must not be guessed by clients:

  • rank_components
  • quality_snapshot
  • pricing_snapshot
  • trace_id
  • billing_statement as a distinct response object

Existing public equivalents are deliberately preserved:

  • stats and capability metadata cover the currently published quality surface.
  • billing_rule, compact billing, usage history, and credits ledger cover published pricing and settlement surfaces.
  • execution_outcome belongs to UsageEventItem; it is an audit record, not a projected Call response field.

Separate follow-ups

Start conditions for any remaining item

  • The field or endpoint is present in the public OpenAPI or equivalent public contract.
  • Request, response, error, and compatibility semantics are specified.
  • Deterministic fixtures are available for supported public deployments.
  • CLI, MCP, JavaScript, and Python behavior can be aligned without client-side inference.

Acceptance criteria

  • Generated types and contract checks match the published contract.
  • Clients expose the same field names and error semantics.
  • Existing defaults and API-key behavior remain compatible.
  • Documentation describes public behavior only and does not depend on unpublished fields.

Metadata

Metadata

Assignees

Labels

priority: P1High priority roadmap itemstatus: blockedWaiting for an external contract or dependency before implementation can proceed

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions