Buyer/control-plane risk
Protected main currently documents and requires callers of .github/workflows/deploy-pages.yml to use secrets: inherit, while the reusable workflow actually needs only CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID. This creates unnecessary secret exposure at a reusable deployment boundary and contradicts the central explicit-secret contract documented in the active automation architecture line.
RCA
- Symptom: caller examples and the runtime guard require blanket inherited secrets.
- Immediate cause:
workflow_call declares no explicit secrets interface, so the documentation uses secrets: inherit as the transport.
- Root cause: the reusable deploy workflow predates the current least-privilege reusable-workflow contract.
- Current search evidence: organization code search finds no product caller of
deploy-pages.yml@... beyond the central workflow and Cloudflare documentation, so an explicit-interface migration is currently bounded to the central repository; this must be rechecked immediately before merge.
Required test-first correction
- Add a permanent contract test from protected
main that fails while workflow_call.secrets does not explicitly require exactly CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID, or while central examples/guard text require secrets: inherit.
- Verify RED on the test-only head before production changes.
- Declare the two exact reusable-workflow secrets and reference only those names in the job.
- Replace
secrets: inherit examples with explicit caller mappings.
- Keep workflow-level
contents: read, immutable action pins, caller-repository checkout behavior, Cloudflare token purpose, and deployment semantics unchanged.
- Re-search the organization for consumers before merge; if any appear, update those thin callers explicitly rather than restoring inheritance.
- Run focused test, full central suite, workflow syntax, security/supply-chain gates,
git diff --check, and current review.
Acceptance
- No
secrets: inherit remains in the authoritative deploy-pages workflow or its central usage docs.
- The reusable workflow exposes only the two Cloudflare secret names it consumes.
- Missing either secret fails closed without printing values.
- No unrelated secret becomes addressable merely because a caller invokes the deploy workflow.
- Consumer search/migration evidence and rollback are documented.
Refs the explicit-secret-contract debt in the canonical automation documentation PR.
Buyer/control-plane risk
Protected
maincurrently documents and requires callers of.github/workflows/deploy-pages.ymlto usesecrets: inherit, while the reusable workflow actually needs onlyCLOUDFLARE_API_TOKENandCLOUDFLARE_ACCOUNT_ID. This creates unnecessary secret exposure at a reusable deployment boundary and contradicts the central explicit-secret contract documented in the active automation architecture line.RCA
workflow_calldeclares no explicitsecretsinterface, so the documentation usessecrets: inheritas the transport.deploy-pages.yml@...beyond the central workflow and Cloudflare documentation, so an explicit-interface migration is currently bounded to the central repository; this must be rechecked immediately before merge.Required test-first correction
mainthat fails whileworkflow_call.secretsdoes not explicitly require exactlyCLOUDFLARE_API_TOKENandCLOUDFLARE_ACCOUNT_ID, or while central examples/guard text requiresecrets: inherit.secrets: inheritexamples with explicit caller mappings.contents: read, immutable action pins, caller-repository checkout behavior, Cloudflare token purpose, and deployment semantics unchanged.git diff --check, and current review.Acceptance
secrets: inheritremains in the authoritative deploy-pages workflow or its central usage docs.Refs the explicit-secret-contract debt in the canonical automation documentation PR.