feat(eventing): Phase 2 — make event signing deployable on a cluster

[mrsabath]

Phase / scope

Phase	Phase 2 — identity on the event path (DESIGN_PHASE2.md), the deployment half
What this changes	Makes Phase 2's signing switchable on a cluster. #879 wired it in both directions; none of it could be turned on in Kubernetes, because no Deployment mounted a seed and the ConfigMap shipped the paths empty.
Phase 2 sections it implements	§4.3 (Ed25519 over HMAC, and why the two services must not share a seed), §4.4 (the two-flag rollout), §5 (the Secret-vs-ConfigMap rule)
Phases it does not touch	Phase 0/1's wire contract and KEDA model are unchanged. Nothing here is Phase 3: no tenancy, no per-user topics, no userkey.
Relationship to the other drafts	#890 (Phase 2 docs) — no overlap, that PR changes only agentdocs/ and this one changes none of it. #883 (Phase 3 tenancy) — no overlap in files; it does add EB_/ER_ variables, so whichever merges second re-runs test_manifests.py's Secret-vs-ConfigMap classification.

Draft — about half the plan. The key material is generated, mountable and applied at deploy time; the preflight check, e2e assertions, the forged-response demo stage and the README_PHASE1 rewrite are still to come (list at the bottom). Opening early because the Secret-handling and manifest decisions are where review is cheapest, and because one of them deviates from a documented convention on purpose.

The problem

#879 wired signing in both directions, but none of it could be switched on in a cluster. The ConfigMap shipped ER_/EB_VERIFY_KEYSET_PATH and *_SIGNING_KID as empty strings and configmap.yaml:54 said seed paths "belong in the Deployment beside the volume" — except no Deployment had one. The only volume in either was data: emptyDir, and grep -rn "secretName\|configMap:" k8s/ returned nothing. So the feature worked with local file paths on a laptop and was unreachable in Kind or OpenShift.

That blocks the demo track: S6, S8 and S9 (#2596/#2598/#2599) are each defined as "reproducible on a local Kind cluster", and S9 is the forged-event teaching moment.

There was also no way to make a key. shared/signing.py has public_key(seed) but nothing anywhere generated one — enabling signing meant hand-rolling os.urandom(32).hex() and deriving public keys in a REPL.

What's here

scripts/gen_signing_keys.py — seeds at mode 0600 under a 0700 directory, and an agents.json whose public keys are derived from those seeds rather than typed, so the keyset cannot disagree with the keys it authorizes. Never prints a seed on either stream; only kids and public keys, because a pasted terminal transcript is the most likely way a demo key escapes. Refuses to overwrite an existing seed without --force, since that key may already be deployed and in an approved keyset.

Both Deployments mount a seed Secret at /etc/ce-signing and the keyset ConfigMap at /etc/ce-keyset, both optional: true — without that, every signing-less overlay would block in ContainerCreating waiting for a Secret that will never exist.

k8s/base/keyset-configmap.yaml ships empty. "There is never a key in this file" is checkable; "only public keys in this file" is not, and a 32-byte seed is indistinguishable from a public key by length.

k8s/overlays/kind-signed/ flips enforcement on. Separate overlay rather than a patch on kind, because S3/S5 are explicitly unsigned milestones and the before/after contrast is the demo.

k8s_deploy.py --signing-keys DIR applies one seed Secret per service plus the keyset ConfigMap, via stdin so the seed never reaches ps through argv — modelled on ensure_ntfy_secret, including the no-op-when-absent behaviour so a redeploy can't silently switch enforcement off and strand a signed topic. It validates first, because every one of these produces a cluster that refuses all traffic with no local symptom: the directory and each named seed must exist, agents.json must parse and approve at least one kid, and the kid each service signs under must be in that keyset.

One deliberate deviation, and one bug caught before it shipped

Per-service Secrets, not the documented single one. Both Deployments initially mounted the same event-signing-key, which would have given the two services one shared seed. That collapses the asymmetry the design rests on — EventBridge would hold the key it verifies runner responses with and could forge them, which is the exact property that made HMAC unacceptable (DESIGN_PHASE2.md §4.3). Now eventbridge-signing-key and eventrunner-signing-key, with a test asserting they never match.

This deviates from a runbook, not a design — a correction from review worth stating
plainly, because I had written it up as a bigger decision than it is. DESIGN_PHASE2.md
§4.4 and §5 say nothing about Secret names or count, and DESIGN_PHASE1.md §11's
"Ed25519 keys in a read-only Secret" is satisfied by two as easily as by one. So it costs
the README rewrite already owed, not a design amendment.

It deviates from event-signing-key as documented at README_PHASE1.md:704-722. That section needs rewriting regardless — it tells the operator to write a seed to /tmp/seed.hex and rm it, contradicting the stdin-only rule stated 230 lines earlier at :475, and it says "have the publisher sign with the same seed", describing the symmetric setup §4.3 explicitly rejected. The rewrite is in the remaining work; flagging it now so the name change isn't a surprise.

Logging asymmetry is intentional. Seeds are logged as a length only — not even a prefix, unlike the API token, because 4 hex chars of a 32-byte seed is 16 bits of a private key and there's nothing to gain from identifying it. Kids are logged in full, because "the operator deployed yesterday's key set" is otherwise invisible until it surfaces as an unexplained rejection.

Also fixed a pre-existing leak: --purge listed eventbridge-ntfy in neither the doomed preview nor the delete tuple, so a "purged" namespace kept an ntfy topic — a capability that lets anyone who learns it both read and publish your notifications.

Testing

568 passed, 5 skipped (5 cluster-gated). 17 new tests. ruff check and ruff format --check clean.

The three manifest tests this could have broken all still pass, and they're why the design looks the way it does: test_no_credential_is_ever_rendered_into_a_manifest (so the Secret is applied by the script, never declared — no secretGenerator), test_the_test_overlay_mounts_no_credential_so_mock_mode_is_automatic (so enforcement stays out of the shared overlays), and test_no_manifest_sets_run_as_user (so no defaultMode: 0400, which would be root-only given OpenShift assigns the UID).

Verified by rendering rather than assumed:

• data is still volume index 0 in all three existing overlays, so the demo overlay's op: replace on /spec/template/spec/volumes/0 still targets the PVC swap it means to.
• No overlay renders a kind: Secret.
• kind stays fully off; kind-signed renders enforcement plus both key paths, and those values map onto the real Cfg fields.
• Keys from the generator verify through verify_with_keyset after a to_kafka_binary/from_kafka_binary round trip.

Not verifiable in my sandbox, and not claimed: kubectl apply --dry-run=client needs a reachable cluster to fetch the OpenAPI schema and fails even with --validate=false, and Kind can't run here (podman has no VM; creating one fails on the proxy's download cap). So schema validity of the new volume stanzas and the actual mount behaviour are unproven — covered by test_every_object_is_accepted_by_the_api_server when run against a real cluster.

Still to do on this branch

• k8s_preflight.py check 14 — Secret present, keyset parses, every kid the ConfigMap names is in it
• k8s_e2e_test.py — assert the terminal response carries ce_signature and the startup banner says signing is ON
• k8s_demo_flow.py --forge — publish an unsigned event to the responses topic and assert it lands as phase="error" with the payload retained under data["rejected"]. Mechanism already validated against a live broker: kafka-console-producer.sh --property parse.headers=true yields a CloudEvent the consumer parses and the verifier rejects (binary mode matters — a structured-mode body gives attrs == {})
• Rewrite README_PHASE1.md §"Signed events"

Question for review

Is kind-signed the right shape? The alternative is a --signed flag on the existing kind overlay. I went with a separate overlay so the unsigned path keeps working for S3/S5 and so the test overlay's no-credential assertion keeps meaning something — but the name is about to get baked into three more files (preflight, e2e, demo flow), so it's cheap to change now and annoying later.

Separately: S6 (#2596) specifies ES256 + a SPIFFE-derived ce-source + rotation, and this is Ed25519 + a static keyset. The eventing design docs never commit to ES256 — only the issue does, and §4.3 argues Ed25519 on merits with SPIRE as a later swap that leaves verification logic unchanged. Worth an explicit decision rather than a surprise at demo time; I'll comment on #2596.

Assisted-By: Claude Code

[aslom]

Reviewed at 21d49c9 with design conformance as the primary lens. The diagnosis is
right and well evidenced — grep -rn "secretName\|configMap:" k8s/ returning nothing
against a ConfigMap that shipped *_KEYSET_PATH as empty strings is exactly the gap, and
configmap.yaml:54 really does promise a Deployment stanza that no Deployment had.

Design conformance: where it lines up

I checked every citation in the diff against the documents. They resolve, and the
reasoning is faithful:

Claim	Document	Verdict
seeds → Secret, keyset → ConfigMap	DESIGN_PHASE2.md §5	✔ exactly as written, including why the location is the control
one seed per service, never shared	§4.3 — "EventBridge would hold the key it verifies with, so it could forge any agent's response"	✔ the strongest argument in the PR, and it is the design's own
Ed25519, not ES256	§4.3	✔ grep -rniE "es256" over agentdocs/ returns nothing — your read is right, only the issue commits to it, and §4.3 names SPIRE as the upgrade that leaves verification unchanged
ER_REQUIRE_SIGNATURE, both *_KEYSET_PATH, both *_SIGNING_KID	DESIGN_PHASE1.md §11 + DESIGN_PHASE2.md §5	✔ every name matches, and all six op: replace targets exist in the base
EB_SIGNING_KID is the only kid accepted on group events	§4.4 item 5 / §5	✔ the overlay comment restates it correctly
bare §N = DESIGN_PHASE1.md	pre-existing # §8.4 in eventrunner-deployment.yaml	✔ consistent with the house convention

Your three README claims are also accurate and, if anything, understated: :713 does say
event-signing-key, :710-716 does write a seed to /tmp and rm it against the
stdin-only rule at :474-477, and :715 does describe the symmetric setup §4.3 rejects.
It also says ER_VERIFY_KEY_PATH=/keys/seed.hex and mounts at /keys, so the mount path
drifts too.

One correction in your favour: the single-Secret convention you are deviating from is a
runbook, not a design. DESIGN_PHASE2.md §4.4 and §5 — the authoritative signing
design — say nothing about Secret names or count. The only design-level sentence nearby is
DESIGN_PHASE1.md §11's "Ed25519 keys in a read-only Secret", which two Secrets satisfy
as easily as one. So the deviation costs a README rewrite you already owe, not a design
amendment. Worth saying in the body so it does not read as a bigger decision than it is.

Where it does not line up

Three places, one of them with teeth.

1. The seed paths go into the ConfigMap, which configmap.yaml:54-55 says they must
   not — and the overlay quotes that sentence immediately before doing it. Not a leak
   (the value is a path), but it is a rule the repo states, the patch cites, and the patch
   breaks. It also collides with #883, open right now: that PR adds
   test_no_phase3_secret_is_inlined_into_a_manifest, asserting f"{var}:" not in rendered for seed-path variables. Its SECRET_PATH_VARS is scoped to Phase 3's three,
   so it does not fail today — but §8.3 states the rule as "continuing Phase 2 §5's", so
   ER_/EB_SIGNING_KEY_PATH joining that tuple is the obvious next edit, and it would
   fail against this overlay. Inline comment with both options.

2. test_the_test_overlay_mounts_no_credential_so_mock_mode_is_automatic now passes for
   a narrower reason than it documents. Its docstring says "NOTHING can inject a
   credential into these pods: no Secret is referenced" — and the test overlay now
   renders secretName: eventrunner-signing-key. Only the literal secretRef spelling in
   the assertion keeps it green. You cite this test as a constraint that shaped the design,
   so it is worth keeping it able to mean that.

3. DESIGN_PHASE1.md §12's preflight table documents 12 checks; the script has 13
   (check_claude_cli_image), which IMPLEMENTATION_REPORT1.md:360,776 and
   README_PHASE1.md:189 all reference by number. §13 step 0 also still reads "checks 1-8,
   10-12". Pre-existing drift, not yours — but you are about to add check 14, so the
   §12 table and the §13 step list are two more lines for the same rewrite pass. Worth
   folding in rather than discovering later that the design documents 12 of 14.

Also: /etc/ce-signing, /etc/ce-keyset, seed.hex, eventing-keyset and the two
Secret names appear in no document in agentdocs/. That is fine for a draft, and your
README rewrite covers the runbook half — but note the feature's design lives in
DESIGN_PHASE2.md §4 while the rewrite target is README_PHASE1.md, and README_PHASE2.md
is already owed (it came up on #883). Putting the signed-deployment runbook into the Phase 1
document is the kind of choice that is cheap now and confusing in a month.

The must-fix

ensure_signing_material validates everything except the one thing that matters. It
checks the directory, that agents.json parses, that it approves at least one kid, that
each seed file exists, and that the kid is in the keyset — but never that the seed
derives the public key the keyset holds for that kid. A divergent pair passes every
check and produces precisely the cluster the function exists to prevent: pods start, both
volumes are optional: true, enforcement is on, and every event is refused with nothing
local to look at.

That state is reachable without hand-editing, which is the second finding: write_seeds
writes kid-by-kid and raises mid-loop on an existing seed, while agents.json is only
rewritten after it returns. Both reproduced below. Three lines in the deploy script
closes the whole class however the divergence arose — including the likeliest real case,
an agents.json copied from a teammate while the seeds are local.

Verification I ran

Check	Result
python -m pytest in eventing/ @ 21d49c9	566 passed, 7 skipped (573 total — your 568/5 agrees; 2 extra skips are this sandbox's subprocess block)
17 new tests in test_signing_deploy.py	confirmed
ruff check . / ruff format --check . @ 0.11.4	clean, 135 files formatted
kustomize build on all four overlays	all four build
data is volume index 0 everywhere	✔ ['data', 'signing-key', 'keyset'] in all four; demo's index 0 is the PVC, so its op: replace still lands on data
no overlay renders kind: Secret	✔
kind-signed renders enforcement + both key paths	✔ all eight values, and they map onto real Cfg fields
kind stays fully off	✔ both flags "false", all four paths empty, no *_SIGNING_KEY_PATH key at all
CI	12/12 green
Commits	2, both Signed-off-by, Assisted-By not Co-Authored-By
.claude/ / .vscode/ changes	none

I also applied both code suggestions to a scratch worktree: 566 passed, 7 skipped,
ruff still clean, and three tests written against the fixed behaviour pass — a
mismatched pair is now refused with nothing applied, a matching directory still applies
all three objects, and a refused regenerate leaves the directory byte-identical. Each
fails against its own revert.

kustomize build succeeding is weaker than kubectl apply --dry-run=server, which I
also cannot run — so your "schema validity of the new volume stanzas is unproven" stands.
It does rule out the failure mode I most expected: a replace op against a key that does
not exist in the base.

On your question

kind-signed as a separate overlay is the right shape. Two reasons beyond the ones
you give. A --signed flag on kind would have to mutate the ConfigMap at deploy time,
which puts enforcement outside the §14.1 manifest digest — the thing you correctly argue
the values belong inside. And the forged-event demo (S9) wants both overlays deployable
back to back in one session, which a flag on one overlay makes awkward. The name is fine;
kind-signed reads as "kind, plus signing" and that is what it is.

REQUEST_CHANGES for the missing seed/keyset agreement check only. Everything else is a
suggestion or a note on the rewrite you have already scheduled.

[mrsabath]

All four findings addressed in 803ccd9, each reproduced against 21d49c9 first and
each fix verified by reverting it. Thread replies have the detail; three things belong
here instead.

Your correction, accepted and now in the body. You are right that the single-Secret
convention I deviated from is a runbook, not a design — DESIGN_PHASE2.md §4.4 and §5
say nothing about Secret names or count, and DESIGN_PHASE1.md §11's "Ed25519 keys in a
read-only Secret" is satisfied by two as easily as by one. I had written it up as a
bigger decision than it is. It costs the README rewrite I already owe, not a design
amendment, and the PR body says so now.

§12/§13 preflight drift, folded in. You were right that this is pre-existing and
right that it was mine to fix anyway, since check 14 is on this branch's list and
discovering the design documents 12 of 14 later is worse. Added row 13 for
check_claude_cli_image with its reasoning — it runs on a cluster node because the CLI's
bundled bun aborts under QEMU user-mode emulation, so a cross-built image cannot execute
it on an arm64 builder — and corrected "checks 1-8, 10-12" to "10-13" in §13 step 0 and
both places k8s_deploy.py repeats it.

On the runbook target, which I think you are right about and I want to flag rather than
quietly decide. You note the feature's design lives in DESIGN_PHASE2.md §4 while the
rewrite target is README_PHASE1.md, and that README_PHASE2.md is already owed. I agree,
and it is the better home: a signed-deployment runbook in the Phase 1 document is exactly
the kind of filing that is cheap now and confusing in a month.

So the plan is README_PHASE2.md carrying the signed-deployment runbook, rather than
rewriting README_PHASE1.md §"Signed events" in place — which also means the undocumented
names you listed (/etc/ce-signing, /etc/ce-keyset, seed.hex, eventing-keyset and
the two Secret names) land in the Phase 2 document where the rest of their design is.
README_PHASE1.md §"Signed events" then gets a pointer and loses the three wrong claims
you confirmed, rather than a rewrite.

That makes the remaining work on this branch:

• k8s_preflight.py check 14 — Secret present, keyset parses, every kid the ConfigMap
  names is in it and its seed derives the approved key (the must-fix generalised
  to preflight, where it catches the problem before deploy rather than during)
• k8s_e2e_test.py — assert the terminal response carries ce_signature and the
  startup banner says signing is ON
• k8s_demo_flow.py --forge
• README_PHASE2.md with the signed-deployment runbook; README_PHASE1.md
  §"Signed events" reduced to a pointer with its three wrong claims removed
• §12 table row 14

On kind-signed as a separate overlay — thank you for the two extra arguments, both
of which are better than mine. The §14.1 digest one in particular: a --signed flag would
have to mutate the ConfigMap at deploy time, putting enforcement outside the digest,
which contradicts the reason I argued the values belong in the manifest. Name and shape
stay.

On ES256 vs Ed25519 — your grep -rniE "es256" over agentdocs/ returning nothing
confirms the read, so I will comment on #2596 proposing the design documents win and the
issue is amended, rather than changing the implementation. §4.3 argues Ed25519 on merits
and names SPIRE as the later swap; switching to ES256 to match an issue nobody has
defended on technical grounds would be the wrong direction.

Tests: 575 passing (+7), ruff clean, all four overlays build.

[aslom]

Verified at 803ccd9. All four round-1 findings are fixed, and I checked each against
the tree rather than against the replies — including mutation-reverting every fix.

#	Finding	Fix	Verified by
1	ensure_signing_material never checked pub(seed) == ks[kid]	the check, with both remedies in the message	mutation: 4 failures; my own round-1 repro now refuses the mismatched pair with nothing applied
2	write_seeds could leave a new seed beside the old public key	whole-set pre-check, "Nothing was written"	mutation: 2 failures (one more than you claimed); ran the first-kid-missing case — seed not re-created, agents.json untouched
3	seed paths in the ConfigMap contradicted configmap.yaml:54-55	moved to container env on both Deployments	rendered all four overlays: no overlay has a *_SIGNING_KEY_PATH key in eventing-config, and kind-signed carries both on the Deployments
4	the test-overlay assertion passed for a narrower reason than it documented	secretName: allowlist by name, plus an anthropic-shaped reject	read; see the note below on what exercises it

Two things you did beyond what I asked, both right:

• load_seed rather than bytes.fromhex, so a corrupt or wrong-length seed is a
  named check failure instead of a traceback — and it means a public key accidentally
  placed in seed.hex is caught by the derivation check rather than silently decoding.
• DESIGN_PHASE1.md §12 now documents check 13 and §13 step 0 reads "checks 1-8,
  10-13". That was in my review body with no commentable line, so thank you for picking
  it up from prose.

Your reasoning on finding 3 is also the one I'd have argued for: following the rule costs
one extra patch block, while changing it would have meant coordinating a carve-out across
two open PRs and three statements of the same sentence. And you are right that #883
needs no change as a result — I re-checked, its SECRET_PATH_VARS tuple can be extended
to ER_/EB_SIGNING_KEY_PATH freely now and this overlay stays green.

Verification I ran

Check	Result
python -m pytest in eventing/ @ 803ccd9	573 passed, 7 skipped (was 566/7)
ruff check . / ruff format --check . @ 0.11.4	clean, 135 files formatted
kustomize build on all four overlays	all four build
Seed-path keys in any rendered eventing-config	none, in all four
kind-signed Deployment env	EB_SIGNING_KEY_PATH / ER_SIGNING_KEY_PATH, enforcement still in the ConfigMap where §14.1's digest covers it
kind still fully unsigned	both flags "false", all paths empty, no env entries
demo's three env entries intact	yes — see the one nit below, which is about a future overlay, not this one
My round-1 fixed-behaviour tests	3/3 pass
New tests in test_signing_deploy.py	17 → 23
Commits	3, all Signed-off-by, Assisted-By not Co-Authored-By
.claude/ / .vscode/ changes	none

Ready to merge? The code is. CI is not — and it is not your fault

Almost nothing has actually run on 803ccd9, and what shows as failed was cancelled
rather than failing. Job-level detail from the Security Scans run (37366549985):

trivy-scan         cancelled   19:55:44Z -> 20:27:32Z   failed steps: (none)
hadolint           cancelled   19:55:44Z -> 20:28:09Z   failed steps: (none)
codeql             cancelled   19:55:44Z -> 20:30:12Z   failed steps: (none)
dependency-review  success     20:08:51Z -> 20:08:58Z

Three jobs sat queued for ~32 minutes and were cancelled with zero failed steps — they
never executed. dependency-review ran as soon as a runner freed up and passed in 7 s. The
whole CI workflow (lint, test, eventing-test, test-startup) is still queued
~35 minutes after creation, and PR Verifier recorded startup_failure twice. hadolint
and trivy-scan passed on 21d49c9 in 7 s and 33 s, and this PR touches no Dockerfile and
adds no dependency.

So the gate is unresolved, not red: this is runner starvation, not a result. Re-trigger the runs and confirm 12/12 before
merging — an empty push or closing and reopening the draft will do it. If eventing-test
comes back failing after a genuine run, that would be new information and worth a look,
but locally it is 573 passed with the same pytest and kafka-python CI installs.

One more gating item, unrelated to CI: this is still a draft, so the merge decision is
yours either way. If you want the remaining four items on your own list (preflight check
14, the e2e assertions, --forge, the README_PHASE1 rewrite) in this PR rather than a
follow-up, say so and I will hold the approval for them; I would rather see them land
separately with their own tests.

Approving the code. Both must-fix mechanisms are closed and reproduced closed, the
three suggestions are implemented, the design-conformance contradiction is resolved in the
direction that keeps all three statements of the rule aligned, and nothing regressed. The
nit below is about an overlay that does not exist yet.

[aslom]

[nit] This comment warns about the failure that is loud and not about the one that is
silent — which matters because the PR plans to copy this patch into three more files.

env/- failing with "path does not exist" is correct and you are right to record it. The
hazard worth the comment is the other direction: op: add on /…/containers/0/env
replaces the list when one already exists. It is safe here because kind-signed
builds on ../kind, whose containers have no env — I rendered all four overlays to
confirm:

kind         eventrunner  env=[]
kind-signed  eventrunner  env=[('ER_SIGNING_KEY_PATH', '/etc/ce-signing/seed.hex')]
demo         eventrunner  env=[('ER_MOCK_CLAUDE','false'), ('HOME','/data/home'),
                               ('CLAUDE_CONFIG_DIR','/data/home/.claude')]

demo is the one that has entries. I built a throwaway demo-signed overlay by changing
nothing but the base — - ../kind → - ../demo — with this patch block verbatim:

hypothetical demo-signed eventrunner env = ['ER_SIGNING_KEY_PATH']
demo's own                              = ['ER_MOCK_CLAUDE', 'HOME', 'CLAUDE_CONFIG_DIR']
-> demo's three entries are LOST, silently

kustomize build succeeds, nothing warns, and ER_MOCK_CLAUDE=false is gone — so a
demo-signed built the obvious way would quietly run the demo in mock mode, which is
precisely what test_the_test_overlay_mounts_no_credential_so_mock_mode_is_automatic
exists to keep honest at the other end.

Not a defect in this PR, and I am not asking for a demo-signed overlay. Just the half-
sentence, since whoever writes it will start from this file:

Suggested change

	# `env` does not exist on the base container (only `envFrom`), so this adds the
	# whole list rather than appending to it. A trailing-slash `env/-` op would fail
	# with "path does not exist" at render time.
	# `env` does not exist on the base container (only `envFrom`), so this adds the
	# whole list rather than appending to it. A trailing-slash `env/-` op would fail
	# with "path does not exist" at render time.
	#
	# NOTE for anyone basing a signed overlay on `demo` instead: `add` on this path
	# REPLACES an existing list rather than extending it, and silently — `demo`'s
	# container has three entries (`ER_MOCK_CLAUDE=false`, `HOME`,
	# `CLAUDE_CONFIG_DIR`), and a copy of this block drops all three while
	# `kustomize build` still succeeds. `ER_MOCK_CLAUDE=false` going missing puts the
	# demo back in mock mode. From `demo`, append with `op: add` on `env/-` per entry.

[aslom]

[nit] This is the right assertion and nothing automated runs it.

The allowlist-by-name is what I was asking for — secretName: only, so the signing-key
volume name is not mistaken for a Secret reference, and that trap is worth the comment
you put on it. I could not mutation-verify it, though: the test is @needs_kubectl and
skips without a cluster, so it is 1 of the 5 no reachable cluster skips both here and in
CI. Reverting the three new lines leaves tests/test_manifests.py at 29 passed, 5 skipped
— unchanged.

Your manual check (patching a credential Secret into the test overlay and watching it go
red) is the right verification and I believe it; I am noting the gap rather than disputing
the fix, because this is the same shape as IMPLEMENTATION_REPORT3.md §2's note about the
claude --help skip: a promise that currently only holds on a laptop.

render() is the thing that needs kubectl, and kustomize is a separate binary that
this sandbox has — so if render() could fall back to kustomize build when kubectl is
absent, this test and the four other manifest assertions would start running in CI with no
cluster. That is a bigger change than this PR should carry; worth an issue alongside
#885-#889 so it is not rediscovered the next time a manifest assertion silently stops
meaning anything.