bug(trigger): recognize Google ADK LlmAgent tools=[...] changes as tool-surface changes

[pengfei-threemoonslab]

Reproduction target

google/adk-python#6605 adds the contributing/samples/agent_hooks Google ADK sample. Its root agent is:

root_agent = LlmAgent(
    name="support_agent",
    tools=[lookup_account, delete_account],
)

The PR therefore adds two directly reachable tool functions, one of which deletes an account.

Reproduction

With the base/head merge base and the sparse paths hydrated:

env AGENTS_SHIPGATE_AGENT_MODE=1 \
  PYTHONPATH=/Users/pengfeihu/code/shipgate/src \
  python -m agents_shipgate verify --preview \
  --workspace . --base origin/main --head HEAD --format json

Observed with source version 0.16.0b7:

{
  "changed_files": ["contributing/samples/agent_hooks/agent.py", "..."],
  "trigger": {
    "should_run": false,
    "run_shipgate": false,
    "skip_reason": "dry_run_only",
    "dry_run_recommended": true,
    "matched_rules": ["TRIGGER-FRAMEWORK-VERSION-BUMP"],
    "diff_tokens": ["google-adk"]
  }
}

The sole match is a raw google-adk diff token. It does not establish that the PR changed a Google ADK dependency version; the token can come from sample/documentation/install text. Meanwhile, the actual LlmAgent(..., tools=[...]) capability change is not recognized as a positive tool-surface trigger.

Expected

Add a conservative, static Google ADK trigger for changes that combine a Google ADK import/context with an Agent or LlmAgent construction whose tools argument is added or modified. The result should be a positive Shipgate route, not merely a framework-upgrade dry-run recommendation.

This must remain static: no imports, user-code execution, network calls, or LLM calls.

Acceptance criteria

• A fixture equivalent to #6605, with no framework-version mutation, returns should_run: true and run_shipgate: true.
• Documentation-only changes mentioning google-adk do not produce a false framework-version-bump classification.
• Existing Google ADK patterns such as FunctionTool / toolset changes retain coverage.
• The trigger rationale names the structural signal that matched, rather than implying a dependency upgrade from a bare token.

Why this matters

A trigger is only routing, not a release decision. But routing this real tool change as dry_run_only prevents normal adoption/verification workflows from starting and weakens the end-to-end value of a supported Google ADK adapter.

[pengfei-threemoonslab]

Confirmed at 527a0349 (v0.16.0b7), and the diagnosis is sharper than "add a rule": the engine already knows this pattern; only the trigger catalog does not.

cli/discovery/signals.py:101:

GOOGLE_ADK_AGENT_CLASSES = {"Agent", "LlmAgent"}

and inputs/google_adk.py:36-40 resolves LlmAgent, google.adk.agents.LlmAgent, and google.adk.agents.llm_agent.LlmAgent. Detection, the adapter, and the binding graph all handle LlmAgent(..., tools=[...]) — which is why #316 reports 2/2 catalog tools reachable on the same sample. The only component that does not recognize it is docs/triggers.json, which carries no ADK rule at all.

So this is drift between the trigger catalog and the engine's own detection signals, not a missing capability.

On the dry_run_only misclassification. Agreed, and it is the more interesting half. TRIGGER-FRAMEWORK-VERSION-BUMP fires on a bare diff_contains: "google-adk" token with no version-change evidence whatsoever, then reports the result as a framework upgrade. That is the same defect class as #308's no_match and #309's no_match: the trigger states a conclusion its evidence does not support. Worth fixing the rationale even independently of adding ADK coverage — a token match should say "a Google ADK token appeared in the diff," not "the framework version was bumped."

The acceptance criterion "documentation-only changes mentioning google-adk do not produce a false framework-version-bump classification" is the right bar and is achievable without new surface: it is a rule-precision fix inside the current schema_version.

Coverage note: FunctionTool( is already matched by TRIGGER-FUNCTION-TOOL-DECORATOR, so the retain-coverage criterion holds today; the gap is specifically plain functions passed to tools=[...], which carry no decorator to match on.

Labeled P1 / v0.17.0 — this breaks the entry point of the adoption flow for a fully supported adapter.