fix: prose-lint allowlist for synthetic credential example
PR Pipeline — Authorize → Validate → Review → Merge / auth (pull_request) Successful in 13s
PR Pipeline — Authorize → Validate → Review → Merge / validate (pull_request) Successful in 5s
PR Pipeline — Authorize → Validate → Review → Merge / lint (pull_request) Successful in 23s
PR Pipeline — Authorize → Validate → Review → Merge / ai-review (pull_request) Successful in 11s
PR Pipeline — Authorize → Validate → Review → Merge / gate (pull_request) Successful in 1s
PR Pipeline — Authorize → Validate → Review → Merge / auth (pull_request) Successful in 13s
PR Pipeline — Authorize → Validate → Review → Merge / validate (pull_request) Successful in 5s
PR Pipeline — Authorize → Validate → Review → Merge / lint (pull_request) Successful in 23s
PR Pipeline — Authorize → Validate → Review → Merge / ai-review (pull_request) Successful in 11s
PR Pipeline — Authorize → Validate → Review → Merge / gate (pull_request) Successful in 1s
The synthetic example 'sk-synthetic-litellm-' in hermes-key-enforcement.prose.md:217 was flagged by the secret-assign rule as a credential-shaped assignment. The existing allowlist entry only covered openai-key, so secret-assign still failed. Fix: Change the rule from openai-key to * (matches any rule) and update the reason to explain why (2026-10-03: secret-assign also matches the credential-shaped assignment). This restores prose-lint on master, which was RED and blocking every open PR's lint job (including PR #149's lint job 2160). Chose option (b) (allowlist) over option (a) (restructure) because: - The existing entry already documented the synthetic example - Changing the rule to * is the minimal, honest fix - Restructuring the command would risk weakening the enforcement check Correlation: corr=7c202734ec6c452a
This commit is contained in:
@@ -35,7 +35,7 @@ bearer-token agent-zero-fix-summary.md «vault: agents/production OPENROUTER_API
|
||||
# example is always an explicit exception, never a pattern-level exemption.
|
||||
* hermes-key-enforcement.prose.md sk-synthetic-external-example Rule 15 illustration of a hardcoded external key that is tolerated; fabricated, never a live key.
|
||||
* hermes-key-enforcement.prose.md sk-synthetic-example-12345 Rule 15 illustration of a forbidden hardcoded key; fabricated, never a live key.
|
||||
openai-key hermes-key-enforcement.prose.md sk-synthetic-litellm- Fabricated key name inside a `grep 'LITELLM_API_KEY=...'` example; not a live key.
|
||||
* hermes-key-enforcement.prose.md sk-synthetic-litellm- Fabricated key name inside a `grep 'LITELLM_API_KEY=...'` example; not a live key. (2026-10-03: changed rule from openai-key to * because secret-assign also matches the credential-shaped assignment)
|
||||
secret-assign hermes-key-enforcement.prose.md sk-NEW_KEY Placeholder standing for the rotated key in an `infisical secrets set` command; not a literal key.
|
||||
openrouter-key agent-zero-openrouter-key.prose.md sk-or-v1-synthetic Synthetic key prefix in the contract's example response; the real key is read from the vault.
|
||||
openai-key litellm-api-keys.prose.md sk-synthetic-tanko-example Fabricated key name in migration history prose; not a live key.
|
||||
|
||||
|
Can't render this file because it contains an unexpected character in line 23 and column 25.
|
Reference in New Issue
Block a user