Skip to content

test(model-access): qualify the pinned client and budgeted live Vertex calls #2334

Description

@Brad-Edwards

Parent design and full capability tracker: #681. Requirement: PLAT-202. Split out of #2124 (M07).

Requirements

  • PLAT-202 — Per-Range LLM Access Management

Why this exists

#2124 (M07) implements and hardens the Vertex invocation and usage adapter with tests that exercise real HTTP serialization, streaming, accounting and error framing. Two acceptance elements of M07 require live qualification evidence that cannot be produced from the code checkout alone and are tracked here so #2124 delivers the code hardening without a hand-authored fixture standing in for real evidence:

  • The architecture guidance is explicit that "a successful synthetic HTTP fixture alone is insufficient" and that qualification "must use sanitized requests captured from the exact pinned client and installed-settings contract, not hand-authored approximations" (see docs/architecture/model-access/vertex-adapter-preflight-2124.md).
  • A separately budgeted live positive call is required for every enabled project/alias before that target is activated.

Scope (live evidence only)

  • Capture a sanitized real wire corpus from the exact pinned released client during an ordinary multi-turn coding session: startup, model listing if used, count, non-stream JSON, SSE, useful local tool use/results, both logical aliases, each configured project, default headers/body features, budget edges, provider errors, malformed/truncated usage, slow/disconnected clients and unsupported-feature rejection. Corpus entries carry the client/config version metadata that produced them and contain no prompts, credentials or provider tokens.
  • Confirm the pinned client's installed-settings contract admits the qualified Messages subset with no manual client or guest change (the default configuration must work out of the box and must not need participant-side repair).
  • Run one separately budgeted live positive call for every enabled project/alias before activation. Record project/model/region, client/dependency/image digests, price/quota/retention prerequisites and safe outcome metadata in the protected evidence surface. Do not commit prompts, provider diagnostics, credentials or private operational identifiers.
  • Feed the qualified GCP slice forward per the delivery ledger; keep each future provider/tool profile's evidence separate.

Boundaries

This issue references the existing Ground Control requirement; it does not declare PLAT-202 implemented or tested. Reconcile actual implementation/test traceability through Ground Control when work lands.

Blocked by #2124.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    gcpGCP / GDC infrastructure work (vs default AWS)rangeRange provisioning

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions