ci: guard that runbook commands do not hardcode a prefixed resource name

[douglasmun]

Closes the last item from the Codex review — the one I deferred out of #116 because it needed a real false-positive story rather than a grep.

Why this is a security guard, not a docs nit

Lambda, SNS topic, DLQ, IAM role/policy, EventBridge rule and alarm names all derive from ResourcePrefix. The runbook tells operators not to deploy at the cdr default, because a live askkaifbot service already owns those names in ap-southeast-1. So a command hardcoding cdr-<suffix> is wrong for precisely the readers who followed the runbook's own advice — best case ResourceNotFoundException mid-incident, worst case they inspect an unrelated production service and draw conclusions from it.

That shipped twice for the EventBridge rule (fixed in #116). This makes the class non-recurring.

What it checks

Suffixes are derived from src/template.yaml and terraform/main.tf at runtime — 13 of them — never hand-listed. That is pitfall #61's lesson applied one commit later: the #60 cap audit enumerated from memory, missed one, and shipped a fail-open. A resource added to either IaC file is covered without touching this script.

A cdr-<suffix> is flagged only where it is passed to a command:

--rule cdr-s3-object-created                     an argument value
--dimensions Name=FunctionName,Value=cdr-lambda  a Key=Value argument
/aws/lambda/cdr-lambda                           a log-group path

Prose, parameter tables and S3 tag names (cdr-status=sanitised) are deliberately not flagged. The runbook must be able to say "do not leave ResourcePrefix at the cdr default" and show cdr-staging-source-<alias> as a suggested value — a guard that flags its own advice gets silenced rather than fixed.

The exemption

Section 8's ResourceExistenceCheck block investigates the foreign cdr-lambda the reader did not deploy. There the literal is correct and $PREFIX-lambda would be actively wrong. No syntactic rule tells that apart from a bug, so the doc declares it inline:

<!-- prefix-literal-ok: this whole block investigates the FOREIGN cdr-lambda … -->

A marker with no reason fails. A marker inside a fenced block fails — an HTML comment there is not a comment; it renders literally and lands mid-command when the command is line-continued (I wrote it that way first, which is how I found it). Every exemption is printed in the summary, so a growing pile is visible rather than quietly normal.

Negative controls — two caught real guard bugs

A guard never shown failing is an assumption (#57). Five controls run:

Control	Expect	Result
Pre-fix runbook (4dc275a^)	FAIL	✅ catches both real bugs
Exemption with empty reason	FAIL	✅
Marker inside a fence	FAIL	✅
Newly injected Value=cdr-lambda	FAIL	✅ (after fix)
Current runbook	PASS	✅ canary clean

Two bugs this caught in my own guard:

1. The first regex matched only a name immediately after --opt, so an injected --dimensions Name=FunctionName,Value=cdr-lambda — the form the runbook's own CloudWatch commands use — passed clean. Now matches the whole argument run.
2. The harness initially counted grep -c 'hardcodes', which also matched the help text, so a failing control looked like it fired. A guard shown failing by a broken harness is worse than one never shown failing, because it looks like evidence.

Verification

• 454 tests pass
• All 8 CI guards pass (was 7)
• Recorded as pitfall terraform: add resource_prefix and wire the four missing CDR caps #62

🤖 Generated with Claude Code