fix(prompt): generic matched-value precedence over downstream use

Generalise the 'judge the matched value, not the surrounding code' rule
to any reference-or-expression match (bare variable, named-argument
pass-through, field/attribute access, config/env/secrets lookup, call,
or interpolation) across languages, and make it take precedence over how
the value is used downstream. A bare-variable argument pass-through
(token=token) was confirmed ~10% of the time under sampling
non-determinism because the value flowed into an API call; the
precedence rule dismisses it 40/40 while the confirm fixtures still
confirm 30/30. Adds the kwarg_passthrough corpus fixture.

Author: juanfont

CHANGELOG.md

@@ -4,6 +4,24 @@ Format: [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). Versioning: [S
 
 ## [Unreleased]
 
+### Changed
+
+- Hardened the gemma4 system prompt so the "judge the matched value, not
+  the surrounding code" rule explicitly takes precedence over downstream
+  use, and generalised it to cover any reference-or-expression match
+  (bare variable, named-argument pass-through, field/attribute access,
+  config/env/secrets lookup, call, or interpolation) across languages,
+  rather than the Python-shaped examples it carried before. The trigger
+  was a `token=token` argument pass-through: the aggressive rule
+  captures the bare variable `token`, and the model — acknowledging it
+  was "a variable being passed to a function call" — still confirmed it
+  ~10% of the time (4/40 runs at conf 0.7-0.9) because the value flows
+  into an API call. vLLM is non-deterministic even at temperature 0, so
+  that tail surfaced as a spurious alert. With the precedence rule the
+  same finding dismisses 40/40; the three confirm fixtures still confirm
+  30/30, so recall is unaffected. New `kwarg_passthrough` corpus fixture
+  guards it.
+
 ## [0.5.0], 2026-06-18
 
 ### Fixed

internal/integration/testdata/diffs/code_expression.expect.json

@@ -1,5 +1,5 @@
 {
-  "description": "The aggressive gitleaks rule matches `access_token = token_incl_metadata.get(` because 'token' appears in the variable name and the captured value is a method call. The value is code, not a credential (the real token is fetched at runtime, never in the diff). The LLM should dismiss. Real-world false positive from an OIDC token-handling commit.",
+  "description": "The aggressive gitleaks rule matches `access_token = token_incl_metadata.get(` because 'token' appears in the variable name and the captured value is a method call. The value is code, not a credential (the real token is fetched at runtime, never in the diff). The LLM should dismiss. Modelled on a real-world OIDC token-handling false positive.",
   "min_after_dedup": 1,
   "expectations": [
     { "match": "token_incl_metadata.get(", "verdict": "dismissed" }

internal/integration/testdata/diffs/kwarg_passthrough.diff

@@ -0,0 +1,14 @@
+diff --git a/services/objects/client.py b/services/objects/client.py
+index 1111111..2222222 100644
+--- a/services/objects/client.py
++++ b/services/objects/client.py
+@@ -680,6 +680,14 @@ def fetch_object_properties(app, object_id):
+     params = {"filter": build_filter(object_id)}
++    token = app.settings["API_TOKEN"]
++    base_url = app.settings["API_URLBASE"]
++    response = http_get_with_retries(
++        f"{base_url}/api/objects",
++        params=params,
++        token=token,
++    )
++    return response.json()["data"]

internal/integration/testdata/diffs/kwarg_passthrough.expect.json

@@ -0,0 +1,8 @@
+{
+  "description": "The aggressive gitleaks rule fires twice on this snippet: on `token = app.settings[\"API_TOKEN\"]` (a config lookup) and on `token=token` (a keyword-argument pass-through, captured value `token,`). Neither is a literal credential. The pass-through is the dangerous one: its captured value is a bare variable reference, and before the precedence-rule prompt hardening the model confirmed it ~10% of the time under sampling non-determinism (it acknowledged the variable but confirmed on the 'used in an API call' cue). Both must dismiss.",
+  "min_after_dedup": 2,
+  "expectations": [
+    { "match": "app.settings[", "verdict": "dismissed" },
+    { "match": "token,", "verdict": "dismissed" }
+  ]
+}

prompts/gemma4_system.tmpl

@@ -18,20 +18,32 @@ your-key-here), documentation examples, and known vendor sentinels
 (AKIAIOSFODNN7EXAMPLE, ya29.dummy, sk-test-...).
 
 Judge the matched value itself, not the words around it. The match must
-BE a literal credential to be confirmed. Dismiss when the matched value
-is code that references or produces a credential rather than the
-credential itself: a variable or attribute name, a function or method
-call, an environment-variable lookup, or a format/template string. For
-example `access_token = token_data.get("access_token")`,
-`password = config.get("db_password")`, `key = os.environ["API_KEY"]`,
-and `secret = f"{prefix}-{suffix}"` all assign a credential that is
-computed at runtime and never appears in the diff, so there is nothing
-to leak. A variable named after a secret is not a secret.
-
-Confirm strings that ARE a credential of some format and appear at a
-call site that uses them: database connections, API client
-initialisation, request header construction, environment-variable
-defaults bound to production hostnames.
+BE a literal credential to be confirmed. This is language-independent.
+Dismiss when the matched value is a reference or expression that yields
+a credential at runtime rather than the literal credential itself. Such
+matches include: a bare variable or identifier; an argument or
+parameter passed through by name; a field, property, or attribute
+access; an index or key lookup into a config, settings, or secrets
+object; an environment-variable read; a function or method call; or a
+string interpolation, format, or template. These shapes recur across
+languages, for example `token=token`, `cfg.Token`, `config["TOKEN"]`,
+`process.env.API_KEY`, `os.environ["API_KEY"]`, `System.getenv("KEY")`,
+`ENV.fetch("SECRET")`, and `"${PREFIX}-${SUFFIX}"`. In every case the
+real credential is held or computed at runtime and never appears in the
+diff, so there is nothing to leak. A variable named after a secret is
+not a secret.
+
+This takes precedence over how the value is used later. If the matched
+value is a reference or expression rather than a literal, dismiss it
+even when the resulting variable is then passed to a credential-using
+call site. Forwarding a variable into an API call, or a config/env
+lookup into an authorization header, does not turn the reference into a
+literal secret. Judge the matched expression, not the downstream use.
+
+Confirm only when the matched value is ITSELF a literal credential of
+some format and appears at a call site that uses it: database
+connections, API client initialisation, request header construction,
+environment-variable defaults bound to production hostnames.
 
 When in doubt, prefer confirmed with lower confidence. A missed real
 secret is more expensive than a noisy alert.