mirror of
https://github.com/block/buzz.git
synced 2026-08-18 06:50:31 +02:00
Goose drives Gemini through its own `google` provider (native
`streamGenerateContent`, `x-goog-api-key`), authenticated with
GOOGLE_API_KEY — distinct from buzz-agent's OpenAI-compatible `gemini`
provider (GEMINI_API_KEY). Offer `google` (labelled "Google Gemini") in
the provider picker for the Goose runtime only, and make Goose readiness
require GOOGLE_API_KEY for it.
- agentConfigOptions.tsx: GOOSE_ONLY_PROVIDER_IDS = {google}; add google
to the provider list, credential config, KNOWN_LLM_PROVIDER_IDS, and
providerRequiresExplicitModel. Picker/credential gating is symmetric —
gemini is buzz-agent-only, google is goose-only — and a persisted value
still renders via the `(current)` tail.
- readiness.rs: goose `google` requires GOOGLE_API_KEY from the env layer
only. Goose keeps the key in its own secret store, never in
config.yaml, so the file config cannot silence it. buzz-agent is
unchanged.
- config_bridge/goose.rs: verify the persisted `active_provider: google`
+ `providers.google.model` path parses to provider/model and never
surfaces GOOGLE_API_KEY from the file.
- readiness_tests.rs: the accumulated `mod tests` stays extracted here
(agent_models precedent) so readiness.rs remains under the default
file-size ceiling; check-file-sizes.mjs override retargeted.
No silent GEMINI_API_KEY->GOOGLE_API_KEY migration — the two contracts
stay independent.
Co-authored-by: Atish Patel <atish@squareup.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Atish Patel <atish@squareup.com>