What
CI's "Secret Detection (whole tree)" check fails on essentially every open PR (confirmed on #16927, #16444) with:
detect-secrets rescan read 1360 finding(s); committed baseline holds 1358; floor 1300
::error::potential secret not in the audited baseline: autobot-frontend/src/i18n/locales/en.json:9086: Secret Keyword
::error::potential secret not in the audited baseline: autobot-frontend/src/i18n/locales/ur.json:9086: Secret Keyword
Root cause: autobot-frontend/src/i18n/locales/en.json/ur.json line 9086 is "authApiKey": "API key" (and the Urdu translation) — a connector-credential auth-method label, not a secret. This key already landed on main (likely via the #16428 connector-credential-bridge work), but its .secrets.baseline entry was never added before merge. Every subsequent PR's whole-tree scan re-discovers it as unaudited and fails, regardless of that PR's own diff — one shared cause, not many.
This exact false positive was already diagnosed and fixed on the still-open #16899 branch (a .secrets.baseline-only fix), but that branch hasn't merged, so the gap persists on main itself.
Fix
Add the two missing baseline entries (is_secret: false, matching the existing labeling style for the other 56/57 legitimate entries already baselined in these same two files) via the scoped-splice technique: full-tree scan separately, diff against the pristine baseline, splice in only the new entries for these two files, verify every other file's hash set is unchanged.
Why filed instead of fixed silently
Per standing policy, findings that block the queue get fixed immediately in a dedicated PR (unblock base in one PR, then the queue can proceed) — this issue documents the root cause for the record.
What
CI's "Secret Detection (whole tree)" check fails on essentially every open PR (confirmed on #16927, #16444) with:
Root cause:
autobot-frontend/src/i18n/locales/en.json/ur.jsonline 9086 is"authApiKey": "API key"(and the Urdu translation) — a connector-credential auth-method label, not a secret. This key already landed onmain(likely via the #16428 connector-credential-bridge work), but its.secrets.baselineentry was never added before merge. Every subsequent PR's whole-tree scan re-discovers it as unaudited and fails, regardless of that PR's own diff — one shared cause, not many.This exact false positive was already diagnosed and fixed on the still-open #16899 branch (a
.secrets.baseline-only fix), but that branch hasn't merged, so the gap persists onmainitself.Fix
Add the two missing baseline entries (
is_secret: false, matching the existing labeling style for the other 56/57 legitimate entries already baselined in these same two files) via the scoped-splice technique: full-tree scan separately, diff against the pristine baseline, splice in only the new entries for these two files, verify every other file's hash set is unchanged.Why filed instead of fixed silently
Per standing policy, findings that block the queue get fixed immediately in a dedicated PR (unblock base in one PR, then the queue can proceed) — this issue documents the root cause for the record.