cache.Key() (pkg/core/cache/source.go:69) hashes resource.ReportConfig(). The cache is created unconditionally in pkg/core/engine/run.go:32 with no opt-out, so any spec field a plugin leaves out of ReportConfig is invisible to the cache key. Two distinct sources then share a key and the second silently receives the first one's value.

ReportConfig predates the cache (#4898, report export), where omitting a field was harmless.

#9821 is one instance of this (temurin omitted specificversion). Auditing all 43 implementations found 11 more.

Method: AST diff of each Spec against the fields assigned in its ReportConfig, then manual verification that the field reaches the Source() path.

Verified as not bugs: credentials (intentional, documented at pkg/core/cache/source.go:46); target/condition-only fields (file.ForceCreate, yaml.Comment, gittag.Message, release Title/Commitish/Description/Draft/Prerelease, updateclihttp.ResponseAsserts); json.Multiple and csv.Multiple (deprecated, normalized into the reported Query at New()).

Decision needed

Nine are a one-line addition each. Two are not: shell.Environments and updateclihttp.Request.Headers routinely carry secrets, and ReportConfig now serves two conflicting contracts, redaction for display and completeness for keying. Redacting two distinct values to the same string reintroduces the collision.

1. Add the 9 safe fields, leave shell and updateclihttp.
2. Split the concerns: a separate cache-key method on the resource interface, ReportConfig untouched for display. Touches every plugin, removes the bug class.
3. One method, but hash secret-bearing fields instead of redacting them, so distinct values stay distinct without appearing in the report.

Option 2 makes the contract explicit, which matters because the failure mode is silent: no error, no warning, just a wrong value written to the target.

@olblak preference?