Dead entries in GOOGLE_PROVIDER_IDS

"google-vertex" and "google-antigravity" can never be matched. Both call sites hardcode specific IDs — provider-registration.ts always passes "google", and gemini-cli-provider.ts always passes "google-gemini-cli". Since google-vertex and google-antigravity are hookAliases of "google", those models already receive the overlay through the "google" entry. The two extra entries are unreachable dead code that may mislead future maintainers into thinking these providers are independently wired.

This is a comment left during a code review.
Path: extensions/google/prompt-overlay.ts
Line: 3

Comment:
**Dead entries in `GOOGLE_PROVIDER_IDS`**

`"google-vertex"` and `"google-antigravity"` can never be matched. Both call sites hardcode specific IDs — `provider-registration.ts` always passes `"google"`, and `gemini-cli-provider.ts` always passes `"google-gemini-cli"`. Since `google-vertex` and `google-antigravity` are `hookAliases` of `"google"`, those models already receive the overlay through the `"google"` entry. The two extra entries are unreachable dead code that may mislead future maintainers into thinking these providers are independently wired.

```suggestion
const GOOGLE_PROVIDER_IDS = new Set(["google", "google-gemini-cli"]);
```

How can I resolve this? If you propose a fix, please make it concise.

Unused modelId parameter

modelId is accepted but never read — only modelProviderId influences the return value. If this parameter is reserved for future per-model differentiation, a short comment explaining that intent would prevent it from appearing as an oversight. Otherwise, removing it keeps the signature honest.

This is a comment left during a code review.
Path: extensions/google/prompt-overlay.ts
Line: 35-38

Comment:
**Unused `modelId` parameter**

`modelId` is accepted but never read — only `modelProviderId` influences the return value. If this parameter is reserved for future per-model differentiation, a short comment explaining that intent would prevent it from appearing as an oversight. Otherwise, removing it keeps the signature honest.

```suggestion
export function resolveGoogleSystemPromptContribution(params: {
  modelProviderId?: string;
  // modelId reserved for future per-model guidance differentiation
  modelId?: string;
}): { sectionOverrides: Record<string, string> } | undefined {
```

How can I resolve this? If you propose a fix, please make it concise.

resolveGoogleSystemPromptContribution returns sectionOverrides: Record<string, string>, which removes compile-time validation of section ids. Tighten this type (e.g., return { sectionOverrides: { tool_enforcement: string } } or a Partial<Record<...>>) so typos in section names don’t silently disable the overlay.

The overlay text starts with a level-1 markdown header (# ...). In the system prompt, level-1 headers are already used for special top-level sections like # Project Context; using another # here can make the prompt structure harder to scan and may collide with any logic that treats # ... as a top-level delimiter. Consider switching this to a ## ... heading (or otherwise matching the surrounding ## section style) while keeping the Hermes body text unchanged.

resolveSystemPromptContribution is now wired for the Google providers, but there’s no test asserting the new behavior (unlike the OpenAI prompt overlay which has dedicated tests). Please add a focused extension test that registers the Google providers and verifies resolveSystemPromptContribution returns a tool_enforcement override containing the Gemini directives for both google and google-gemini-cli (and not for unrelated providers).

New tool_enforcement section override is now assembled into the system prompt, but there’s no accompanying test to ensure this override is rendered (and placed) correctly. Please add/extend a unit test that provides promptContribution.sectionOverrides.tool_enforcement and asserts the resulting prompt includes that block (and that fallback behavior remains unchanged when it’s absent).

Restrict Google prompt overlay to Gemini models

resolveGoogleSystemPromptContribution only checks provider id, so it injects Gemini-specific directives for every model routed through the Google plugin, including hook-alias traffic like google-antigravity that can target non-Gemini ids (for example Claude-family ids used elsewhere in the repo). This means non-Gemini runs receive mismatched operational instructions and can regress response quality; the contribution should also gate on modelId (or another model-family check) before applying the Gemini overlay.

Useful? React with 👍 / 👎.