rcf-lite 0.23.0 → 0.24.0

package/blueprints/edge-cloudflare-rate-limiting/contributions/tacs/tac-3701-edge-cloudflare-rate-limiting-manifest-schema.json

@@ -0,0 +1,31 @@
+{
+  "tacId": "TAC-3701-edge-cloudflare-rate-limiting-manifest-schema",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "name": "Rate-limit rule manifest schema and manifest layout",
+  "purpose": "The shipped JSON Schema (draft-07) at blueprints/edge-cloudflare-rate-limiting/contributions/schemas/rate-limit-rule.schema.json is the single source of truth for the shape of one manifest file under the elicited rate-limit-rules-dir. The schema names the seven Cloudflare WAF rate-limiting rules fields per https://developers.cloudflare.com/waf/rate-limiting-rules/ (id, expression, threshold, period, characteristics, action, duration), their types (string, string, positive integer, positive integer, non-empty string array, enum of block/challenge/log/managed_challenge, positive integer), and the additionalProperties: false stance. The manifest-schema-validate probe reads every file in the fixture manifest directory and validates against this schema; the manifest-presence probe asserts the seven required fields are all present. This TAC anchors AC-36101-1, AC-36106-1 and AC-36108-1.",
+  "responsibilities": [
+    "Ship a JSON Schema (draft-07) at contributions/schemas/rate-limit-rule.schema.json naming the seven required fields, their types and additionalProperties: false (AC-36101-1, AC-36106-1).",
+    "Ship the shape used by the manifest-presence probe to assert every manifest file carries the seven required fields (AC-36101-1).",
+    "Ship the shape used by the manifest-schema-validate probe to refuse a manifest file with a missing threshold under SIMULATE_SCHEMA_INVALID=true (AC-36106-1).",
+    "Ship the layout used by the manifest-presence probe under SIMULATE_MANIFEST_MISSING=true to name the missing file's basename in the detail (AC-36108-1)."
+  ],
+  "internalStructure": "One JSON Schema file (contributions/schemas/rate-limit-rule.schema.json). One shipped example manifest directory in the cf-edge fixture with two files (cloudflare/rate-limits/example.json, cloudflare/rate-limits/api-writes.json). Two induced-failure switches in the fixture: SIMULATE_MANIFEST_MISSING=true moves one manifest file to a scratch location so manifest-presence fails; SIMULATE_SCHEMA_INVALID=true writes a manifest file with a missing threshold so manifest-schema-validate fails. Both switches restore before commit; the anatomy test verifies the negative path.",
+  "interfaces": [
+    {
+      "name": "rate-limit-rule.schema.json",
+      "kind": "schema",
+      "summary": "JSON Schema (draft-07) for one rate-limit rule manifest file."
+    },
+    {
+      "name": "cloudflare/rate-limits/",
+      "kind": "layout",
+      "summary": "Elicited manifest directory, one JSON file per rule."
+    }
+  ],
+  "dependencies": [],
+  "createdAt": "2026-09-07T22:00:00.000Z",
+  "updatedAt": "2026-09-07T22:00:00.000Z"
+}

package/blueprints/edge-cloudflare-rate-limiting/contributions/tacs/tac-3702-edge-cloudflare-rate-limiting-management-surface-doc.json

@@ -0,0 +1,25 @@
+{
+  "tacId": "TAC-3702-edge-cloudflare-rate-limiting-management-surface-doc",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "name": "Operator-facing management surface documentation (wrangler and Cloudflare dashboard flows)",
+  "purpose": "The shipped guide at blueprints/edge-cloudflare-rate-limiting/guide/edge-cloudflare-rate-limiting.md documents both a wrangler command flow and a Cloudflare dashboard flow for applying one rule from a manifest file to the elicited zone. The guide is the sole management-surface artefact the blueprint ships; no committed script writes rules to the live zone. The elicited rate-limit-management-surface value records the flow the operator chose. The guide also names the composition with security-auth-magic-link per ADR-3702 and shows a copy-paste example. This TAC anchors AC-36102-1 and AC-36105-1.",
+  "responsibilities": [
+    "Ship a guide with a wrangler command flow and a Cloudflare dashboard flow, both walking through the apply of one rule from a manifest file (AC-36102-1).",
+    "Reference https://developers.cloudflare.com/waf/rate-limiting-rules/ as the vendor doc for the rule shape (AC-36102-1).",
+    "Ship a Composition with security-auth-magic-link section naming ADR-3702 explicitly, stating the zone rule characteristic (IP-per-URL) and the application rule characteristic (per-email per-minute) with a copy-paste example (AC-36105-1)."
+  ],
+  "internalStructure": "One guide file (guide/edge-cloudflare-rate-limiting.md) with three named sections: Manifest, Management surface (wrangler and dashboard subsections) and Composition with security-auth-magic-link. Every section links back to the corresponding REQ and ADR.",
+  "interfaces": [
+    {
+      "name": "guide/edge-cloudflare-rate-limiting.md",
+      "kind": "documentation",
+      "summary": "Operator-facing management surface guide with both wrangler and dashboard flows plus the composition example."
+    }
+  ],
+  "dependencies": [],
+  "createdAt": "2026-09-07T22:00:00.000Z",
+  "updatedAt": "2026-09-07T22:00:00.000Z"
+}

package/blueprints/edge-cloudflare-rate-limiting/contributions/tacs/tac-3703-edge-cloudflare-rate-limiting-drift-audit-runner.json

@@ -0,0 +1,26 @@
+{
+  "tacId": "TAC-3703-edge-cloudflare-rate-limiting-drift-audit-runner",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "name": "Drift-audit runner: read live zone rules via the Cloudflare API and diff against the local manifest",
+  "purpose": "The single project-side module realising the scheduled drift-audit runner. It fetches the live rate-limiting rules on the elicited zone via the Cloudflare API (GET /client/v4/zones/{zone_id}/rulesets), diffs the returned rule set against the local manifest file-by-file, and constructs one drift-audit record per mismatched rule. Records write through the applied logger's audit sink with the metadata-only shape {ruleId, clientIpHash, outcome, timestamp, diff}; no record carries a full IP, a request body or a user agent (event-secrecy discipline per REQ-004 and AC-36107-1). The runner is factory-driven for testability: probes and the anatomy test inject a fake fetch that returns a synthetic live-zone response. This TAC anchors AC-36104-1 and AC-36107-1.",
+  "responsibilities": [
+    "Export createDriftAuditRunner({env, eventSink, fetch, clock, cadence}) returning {runOnce, schedule, stop} matching the drift-audit shape (AC-36104-1).",
+    "Diff every manifest rule against every live rule and construct one drift record per mismatched rule, with the metadata-only shape {ruleId, outcome, timestamp, diff} (AC-36104-1, AC-36107-1).",
+    "Emit exactly one audit event per drift record on the injected sink, Object.frozen at the boundary (AC-36107-1).",
+    "Refuse to run when the elicited cadence is off (AC-36104-1)."
+  ],
+  "internalStructure": "One shipped runner module the blueprint contributes at guide-installation time (the runner code is copy-paste from the guide into the applying project; the shipped fixture at packages/rcf-lite/test/fixtures/cf-edge/src/drift-audit-runner.mjs realises the shape the guide names). The runner constructs one drift record per mismatched rule; the record is Object.frozen at the boundary so a downstream handler cannot enrich it with a leaked field.",
+  "interfaces": [
+    {
+      "name": "createDriftAuditRunner",
+      "kind": "factory",
+      "summary": "Drift-audit runner factory over env, eventSink, fetch, clock and the elicited cadence."
+    }
+  ],
+  "dependencies": [],
+  "createdAt": "2026-09-07T22:00:00.000Z",
+  "updatedAt": "2026-09-07T22:00:00.000Z"
+}

package/blueprints/edge-cloudflare-rate-limiting/contributions/user-stories/edge-cloudflare-rate-limiting-us-36101.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-rate-limiting-US-36101",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-rate-limiting-REQ-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Rules manifest present in the applying project as one JSON file per rule under the elicited manifest directory",
+  "asA": "shelf consumer applying the edge-cloudflare-rate-limiting v1.0.0 blueprint on a Workers project using the cf-edge fixture",
+  "iWant": "the elicited rate-limit-rules-dir to contain at least one committed JSON file per rate-limit rule the applying project intends to run, each file matching the elicited rule shape and none referencing a secret in plaintext",
+  "soThat": "the applying project's rate-limit rules are source-controlled and reviewable, and the operator has a stable source of truth to apply to the live zone through the wrangler or dashboard flow",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-36101-1",
+      "description": "The rate-limit manifest directory (default cloudflare/rate-limits/) exists in the applied project and holds at least one JSON file per rule; every file parses as JSON and carries the seven documented Cloudflare WAF rate-limiting rules fields (id, expression, threshold, period, characteristics, action, duration); no file body contains a plaintext Cloudflare API token or the elicited zone id (the zone id is elicited and stored via the applied secretsManagement companion).",
+      "given": "the cf-edge fixture with the two committed manifest files under cloudflare/rate-limits/",
+      "when": "the manifest-presence probe scans the fixture directory",
+      "then": "every manifest file parses, every file carries the seven required fields, and no file references a secret in plaintext",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-3701-edge-cloudflare-rate-limiting-manifest-schema"
+  ],
+  "createdAt": "2026-09-07T22:00:00.000Z",
+  "updatedAt": "2026-09-07T22:00:00.000Z"
+}

package/blueprints/edge-cloudflare-rate-limiting/contributions/user-stories/edge-cloudflare-rate-limiting-us-36102.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-rate-limiting-US-36102",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-rate-limiting-REQ-002",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Guide documents the operator-facing management surface with both wrangler and dashboard flows",
+  "asA": "operator on the applying project preparing to push rate-limit rules from the local manifest to the live Cloudflare zone",
+  "iWant": "a documented step-by-step flow that walks me through both a wrangler command sequence and a Cloudflare dashboard sequence for applying each manifest rule",
+  "soThat": "I can pick the flow that suits the project's operating discipline and reproduce the apply from the manifest at any cadence without inventing a bespoke tool",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-36102-1",
+      "description": "The blueprint guide at blueprints/edge-cloudflare-rate-limiting/guide/edge-cloudflare-rate-limiting.md documents an operator-facing management surface with both a wrangler command flow and a Cloudflare dashboard flow; each flow names the exact steps to apply one rule from a manifest file to the elicited zone; the guide references https://developers.cloudflare.com/waf/rate-limiting-rules/ as the vendor doc for the rule shape.",
+      "given": "the shipped guide file in the blueprint tree",
+      "when": "the anatomy test scans the guide for the wrangler headings, the dashboard headings and the vendor URL",
+      "then": "both flow headings are present and the vendor URL appears",
+      "testable": true,
+      "scope": "documentation"
+    }
+  ],
+  "tacIds": [
+    "TAC-3702-edge-cloudflare-rate-limiting-management-surface-doc"
+  ],
+  "createdAt": "2026-09-07T22:00:00.000Z",
+  "updatedAt": "2026-09-07T22:00:00.000Z"
+}

package/blueprints/edge-cloudflare-rate-limiting/contributions/user-stories/edge-cloudflare-rate-limiting-us-36103.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-rate-limiting-US-36103",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-rate-limiting-REQ-003",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Over-threshold burst returns 429 with Retry-After and Cf-Ray on the (N+1)th request within the elicited duration",
+  "asA": "operator running the real-account burst probe against a scheduled HQ-owned URL configured with the manifest rule",
+  "iWant": "the probe to fire an undici burst above the rule threshold and observe the (N+1)th and subsequent requests return HTTP 429 with a Retry-After header consistent with the elicited duration and a Cf-Ray header for the CF edge that served the refusal",
+  "soThat": "the shipped over-threshold behaviour is verified against a real Cloudflare account and, in CI without CI_HAS_CLOUDFLARE_ACCOUNT, the probe records accountBound: skipped per ruling 6",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-36103-1",
+      "description": "When CI_HAS_CLOUDFLARE_ACCOUNT is true and CF_RATE_LIMIT_URL is set to a scheduled HQ-owned URL configured with the manifest rule, the real-account-burst-and-429 probe fires the elicited threshold plus one requests within the rule period and observes the (N+1)th and subsequent requests within the elicited duration return HTTP 429 with a Retry-After header value consistent with the elicited duration and a Cf-Ray header naming the CF edge; when either env var is absent the probe records accountBoundSkipped: true and the aggregate verdict is pass per spec section 3.5 and ruling 6.",
+      "given": "a scheduled HQ-owned URL configured with the manifest rule (or the accountBound: skipped fallback in CI)",
+      "when": "the real-account-burst-and-429 probe fires the burst (or records the skip)",
+      "then": "the probe returns 429 with the two required headers on the over-threshold requests, or records accountBoundSkipped: true and aggregates to pass",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-3701-edge-cloudflare-rate-limiting-manifest-schema"
+  ],
+  "createdAt": "2026-09-07T22:00:00.000Z",
+  "updatedAt": "2026-09-07T22:00:00.000Z"
+}

package/blueprints/edge-cloudflare-rate-limiting/contributions/user-stories/edge-cloudflare-rate-limiting-us-36104.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-rate-limiting-US-36104",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-rate-limiting-REQ-004",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Drift-audit runner reads live zone rules via the Cloudflare API and diffs against the local manifest, constructing metadata-only records",
+  "asA": "operator on the applying project running the scheduled drift-audit runner behind the elicited cadence (daily or hourly)",
+  "iWant": "the runner to fetch the live rule set from the Cloudflare API for the elicited zone and diff every rule against the local manifest, constructing one drift-audit record per mismatched rule with the metadata-only shape and writing a report to .rcf/reports/blueprints/edge-cloudflare-rate-limiting/",
+  "soThat": "manifest drift (a rule changed on the dashboard without a manifest update, or vice versa) is surfaced through the logging companion at the elicited cadence rather than lingering unnoticed",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-36104-1",
+      "description": "Given a synthetic drift scenario (a fixture manifest file that names threshold 10 and a fake live-zone response that reports threshold 20 on the same rule id), the drift-audit runner's diff step constructs one drift record per mismatched rule; the record carries {ruleId, outcome: driftDetected, timestamp, diff: [field: threshold, manifestValue: 10, liveValue: 20]} and NO full IP, NO request body, NO user agent; when the cadence elicit is off the runner is not wired and no report is written.",
+      "given": "the cf-edge fixture with the committed manifest and a synthetic Cloudflare API response with one mismatched rule",
+      "when": "the drift-audit runner's diff step runs against the pair",
+      "then": "one drift record is constructed per mismatched rule with the metadata-only shape and the report writes to .rcf/reports/blueprints/edge-cloudflare-rate-limiting/",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-3703-edge-cloudflare-rate-limiting-drift-audit-runner"
+  ],
+  "createdAt": "2026-09-07T22:00:00.000Z",
+  "updatedAt": "2026-09-07T22:00:00.000Z"
+}

package/blueprints/edge-cloudflare-rate-limiting/contributions/user-stories/edge-cloudflare-rate-limiting-us-36105.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-rate-limiting-US-36105",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-rate-limiting-REQ-005",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Composition with security-auth-magic-link: zone rate rule layers over the per-email application rule",
+  "asA": "operator applying both edge-cloudflare-rate-limiting and security-auth-magic-link on the same project",
+  "iWant": "the guide to name the ADR-3702 layering explicitly, showing that the zone rule refuses IP-per-URL bursts at the CF edge before they reach the origin and the security-auth-magic-link per-email application rule continues to run on requests that pass the edge gate",
+  "soThat": "I understand the composition at apply time rather than discovering that both blueprints operate on separate characteristic sets by trial and error",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-36105-1",
+      "description": "The guide contains a section titled Composition with security-auth-magic-link that names ADR-3702 explicitly, states the zone rule characteristic (IP-per-URL) and the application rule characteristic (per-email per-minute) verbatim, and shows a copy-paste example of both blueprints applied on the same project.",
+      "given": "the shipped guide at blueprints/edge-cloudflare-rate-limiting/guide/edge-cloudflare-rate-limiting.md",
+      "when": "the anatomy test scans the guide for the composition section and ADR-3702 reference",
+      "then": "the section heading, ADR-3702 reference, both characteristic strings and the copy-paste example are present",
+      "testable": true,
+      "scope": "documentation"
+    }
+  ],
+  "tacIds": [
+    "TAC-3702-edge-cloudflare-rate-limiting-management-surface-doc"
+  ],
+  "createdAt": "2026-09-07T22:00:00.000Z",
+  "updatedAt": "2026-09-07T22:00:00.000Z"
+}

package/blueprints/edge-cloudflare-rate-limiting/contributions/user-stories/edge-cloudflare-rate-limiting-us-36106.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-rate-limiting-US-36106",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-rate-limiting-REQ-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Manifest schema validates every rule file against the shipped JSON Schema and refuses invalid shapes",
+  "asA": "operator on the applying project committing new rate-limit rule files under the elicited manifest directory",
+  "iWant": "the shipped JSON Schema to validate every rule file's shape (the seven required fields with the correct types) and the manifest-schema-validate probe to surface any file that violates the shape",
+  "soThat": "invalid manifest changes are caught in the fixture probe rather than at operator apply time against a live zone",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-36106-1",
+      "description": "Given the shipped rate-limit-rule JSON Schema (blueprints/edge-cloudflare-rate-limiting/contributions/schemas/rate-limit-rule.schema.json, draft-07), the manifest-schema-validate probe reads every manifest file in the fixture manifest directory and validates each against the schema; every valid file passes; a manifest file with a missing threshold field (simulated via SIMULATE_SCHEMA_INVALID=true) fails validation and the probe returns aggregateVerdict: fail with the offending field named in the detail.",
+      "given": "the cf-edge fixture with the two committed manifest files and the shipped JSON Schema",
+      "when": "the manifest-schema-validate probe validates every manifest file",
+      "then": "every valid file passes; the SIMULATE_SCHEMA_INVALID=true switch surfaces the missing threshold field and the aggregate verdict is fail",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-3701-edge-cloudflare-rate-limiting-manifest-schema"
+  ],
+  "createdAt": "2026-09-07T22:00:00.000Z",
+  "updatedAt": "2026-09-07T22:00:00.000Z"
+}

package/blueprints/edge-cloudflare-rate-limiting/contributions/user-stories/edge-cloudflare-rate-limiting-us-36107.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-rate-limiting-US-36107",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-rate-limiting-REQ-004",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Drift-audit records carry metadata-only fields (ruleId, clientIpHash, outcome, timestamp) with no full IP, no body, no user agent",
+  "asA": "operator on the applying project reading drift-audit reports and rate-limit event records through the applied logging companion",
+  "iWant": "every drift-audit record and every rate-limit event record to carry only metadata-safe fields (ruleId, clientIpHash, outcome, timestamp, plus the drift diff fields where applicable), never a full client IP, never a request body, never a user agent string",
+  "soThat": "the audit trail is safe to store, forward and read without additional PII scrubbing at the audit sink",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-36107-1",
+      "description": "The event-secrecy probe drives a synthetic drift-audit payload constructed from a fixture rule and a fake live-zone response; every record on the sink carries only {ruleId, clientIpHash, outcome, timestamp} plus (for drift records) a diff array with the schema-safe fields; the probe asserts NO full IP (regex 4-octet dotted quad or v6 group), NO request body key, NO user-agent key; the SIMULATE_EVENT_LEAK_IP=true switch injects a full IP into the drift record and the probe returns aggregateVerdict: fail with the leaked key named in the detail.",
+      "given": "the shipped drift-audit runner and a synthetic input pair",
+      "when": "the event-secrecy probe drives the runner and inspects the resulting records",
+      "then": "every record carries only the metadata-safe fields; SIMULATE_EVENT_LEAK_IP=true surfaces a leaked key and the aggregate verdict is fail",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-3703-edge-cloudflare-rate-limiting-drift-audit-runner"
+  ],
+  "createdAt": "2026-09-07T22:00:00.000Z",
+  "updatedAt": "2026-09-07T22:00:00.000Z"
+}

package/blueprints/edge-cloudflare-rate-limiting/contributions/user-stories/edge-cloudflare-rate-limiting-us-36108.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-rate-limiting-US-36108",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-rate-limiting-REQ-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Manifest-presence probe refuses a missing manifest file and names the missing file in the detail",
+  "asA": "operator on the applying project accidentally deleting or moving a manifest file under the elicited manifest directory",
+  "iWant": "the manifest-presence probe to surface the missing file at fixture probe time rather than at operator apply time against a live zone",
+  "soThat": "a manifest under-population defect is caught in the CI probe rather than lingering until an operator notices a missing rule at the dashboard",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-36108-1",
+      "description": "Given the cf-edge fixture with the SIMULATE_MANIFEST_MISSING=true switch, one committed manifest file is treated as absent by the probe; the manifest-presence probe returns aggregateVerdict: fail with the missing file's basename named in the detail; without the switch the probe passes and both manifest files are inspected.",
+      "given": "the cf-edge fixture with two committed manifest files and the SIMULATE_MANIFEST_MISSING=true switch",
+      "when": "the manifest-presence probe scans the fixture manifest directory",
+      "then": "the probe returns aggregateVerdict: fail and the missing file basename is present in the detail",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-3701-edge-cloudflare-rate-limiting-manifest-schema"
+  ],
+  "createdAt": "2026-09-07T22:00:00.000Z",
+  "updatedAt": "2026-09-07T22:00:00.000Z"
+}

package/blueprints/edge-cloudflare-rate-limiting/docs/topics.md

@@ -0,0 +1,68 @@
+# edge-cloudflare-rate-limiting blueprint coordination vocabulary
+
+This file is the edge-cloudflare-rate-limiting half of the cross-blueprint contract. The Phase 1 conflict detector matches scope:global ADR topics by EXACT string equality, and AC ids are unnamespaced by the 0.4.4 grammar. Any blueprint intended to compose with this one must reuse these exact strings and respect these bands.
+
+## Global ADR topics this blueprint contributes (exact strings)
+
+| Topic string | edge-cloudflare-rate-limiting contribution | Origin | Composition note |
+|---|---|---|---|
+| `edgeThrottleContract` | ADR-3701-edge-cloudflare-rate-limiting-throttle-contract | Minted by this blueprint. Names the wire-shape contract for the project-wide edge throttle; the shipped answer is Cloudflare WAF rate-limiting rules per `https://developers.cloudflare.com/waf/rate-limiting-rules/`. | The one project-wide decision on the edge throttle at the shipped-shape boundary. A future non-Cloudflare sibling (Fastly rate-limits, Vercel Edge Config throttles) would contribute the same topic string with a different answer, forcing a DELIBERATE conflict the operator resolves with a project-level ADR. |
+
+The edge-cloudflare-rate-limiting blueprint claims one global topic (minted here, shipped as the Cloudflare WAF rate-limiting rules manifest and drift-audit). ADR-3702 layering, ADR-3703 manifest shape and ADR-3704 drift-audit cadence do not contribute global topics; a composing blueprint that holds an opinion on either authors its own project-level ADR.
+
+Rules for new topics: lower camel case, one concept per topic, no version suffixes. A topic names the decision area, not the chosen answer.
+
+## Id number bands (registry bootstrap)
+
+This table is maintained shelf-wide across every blueprint's `docs/topics.md`. Rows are recorded at ship, never predicted.
+
+| Blueprint | US band | ADR/TAC suffix block | Status | Global topics |
+|---|---|---|---|---|
+| application-spa | 1101-1899 | 2xx | shipped v1.3.0 | `clientRouting`, `theming`, `clientState`, `errorEnvelope`, `authModel` |
+| application-api-rest | 2101-2899 | 3xx | shipped v1.0.0 | `errorEnvelope`, `authModel`, `apiVersioning`, `logging` |
+| security-auth-magic-link | 3101-3899 | 5xx | shipped v1.2.0 | `authModel` |
+| email-smtp-resend | 4101-4899 | 4xx | shipped v1.0.0 | none |
+| hello-panel (walkthrough exemplar) | 4101-4899 | 4xx | doc-reserved; teaching exemplar in `packages/rcf-lite/docs/blueprint-authoring-walkthrough.md`, not shipped as a blueprint directory | `operatorPanel` |
+| persistence-data-sqlite | 5101-5899 | 6xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
+| delivery-ci-workflows | 6101-6899 | 7xx | shipped v2.0.0 (renamed from ci-pipeline) | `ciGates`, `strictCoverageGate`, `releaseArtefacts` |
+| observability-essentials | 7101-7899 | 8xx | shipped v2.0.0 | `statusPageContract` |
+| security-secrets-management | 8101-8899 | 9xx | shipped v1.0.1 | `secretsSource` |
+| security-auth-clerk | 9101-9899 | 10xx | shipped v1.0.0 | `authModel` |
+| security-auth-oauth2 | 10101-10899 | 11xx | shipped v1.0.0 | `authModel` |
+| security-auth-keycloak | 11101-11899 | 12xx | shipped v1.0.0 | `authModel` |
+| deploy-cloudflare-workers | 12101-12899 | 13xx | shipped v1.2.0 | `deploymentTarget` |
+| persistence-data-d1 | 13101-13899 | 14xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
+| observability-probe-endpoints | 14101-14899 | 15xx | shipped v1.1.0 | `healthProbes`, `readinessSemantics` |
+| observability-logging | 15101-15899 | 16xx | shipped v1.0.0 | `logging` |
+| application-error-handling | 16101-16899 | 17xx | shipped v1.0.0 | `errorHandling` |
+| application-datatable | 17101-17899 | 18xx | shipped v1.0.0 | none |
+| application-charts | 18101-18899 | 19xx | shipped v1.0.0 | none |
+| application-dashboard | 19101-19899 | 20xx | shipped v1.0.0 | none |
+| application-notifications-in-app | 20101-20899 | 21xx | shipped v1.0.0 | none |
+| application-admin-console | 21101-21899 | 22xx | shipped v1.1.0 | `adminConsoleSignInSurface` |
+| application-empty-error-states | 22101-22899 | 23xx | shipped v1.0.0 | none |
+| application-file-upload | 23101-23899 | 24xx | shipped v1.0.0 | none |
+| application-forms-wizard | 24101-24899 | 25xx | shipped v1.0.0 | none |
+| application-account-settings | 25101-25899 | 26xx | shipped v1.0.0 | none |
+| application-onboarding-tour | 26101-26899 | 27xx | shipped v1.0.0 | none |
+| persistence-data-postgres | 27101-27899 | 28xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
+| object-storage-s3 | 28101-28899 | 29xx | shipped v1.0.0 | `objectStorageContract` |
+| messaging-queue-cloudflare | 29101-29899 | 30xx | shipped v1.0.0 | `deliverySemantics` |
+| jobs-background | 30101-30899 | 31xx | shipped v1.0.0 | `backgroundJobModel` |
+| platform-cloudflare-kv | 31101-31899 | 32xx | shipped v1.0.0 | `keyValueStoreContract` |
+| platform-cloudflare-cron-triggers | 32101-32899 | 33xx | shipped v1.0.0 | `scheduledTriggerContract` |
+| platform-cloudflare-durable-objects | 33101-33899 | 34xx | shipped v1.0.0 | `strongConsistencyCellContract`, `websocketHubContract` |
+| edge-cloudflare-access | 34101-34899 | 35xx | shipped v1.0.0 | `edgeAuthenticationGate` |
+| edge-cloudflare-turnstile | 35101-35899 | 36xx | shipped v1.0.0 | `humanVerificationGate` |
+| edge-cloudflare-rate-limiting | 36101-36899 | 37xx | shipped v1.0.0 | `edgeThrottleContract` |
+
+US 36101-36108 sit at the LOW end of the 36101-36899 band on purpose (watchpost run-4 lesson). ADR/TAC suffixes for this blueprint use the 3701-3799 block, continuing the shelf pattern.
+
+## Shared expectations for future composing blueprints
+
+- Reuse `edgeThrottleContract` exactly as spelled here when your blueprint holds an opinion on the edge throttle contract; contribute your own scope:global ADR on that string and let composition surface the pairing.
+- Consumer blueprints reading the `edgeRateLimit` capability declared on `blueprint.json` per section 6a of `blueprint-authoring.md` obtain the shipped rate-limit surface at apply time via the capability-declaration mechanism.
+
+## Deliberate-conflict statement
+
+This blueprint's ADR-3701 on `edgeThrottleContract` is the first shipped answer to a topic that will conflict, by design, with future non-Cloudflare siblings. Applying `edge-cloudflare-rate-limiting` alongside such a sibling would raise a `globalAdrTopic` conflict the operator resolves via one of the four documented resolutions (adopt one, keep the existing one, author a project-level supersede ADR, or `--resolve <topic>=project:<ADR-id>` on the add).

package/blueprints/edge-cloudflare-rate-limiting/guide/edge-cloudflare-rate-limiting.md

@@ -0,0 +1,88 @@
+# edge-cloudflare-rate-limiting guide
+
+Round 6 T-6 of the Cloudflare-first blueprint line. Ships zone-level rate limiting as an edge gate in front of Worker handlers. The rule set is a local manifest the applying project commits, and an operator applies it to the live Cloudflare zone through either a wrangler command flow or the Cloudflare dashboard flow, both walked below.
+
+## Manifest
+
+The applying project holds its rate-limit rule set as one JSON file per rule under the elicited `rate-limit-rules-dir` (default `cloudflare/rate-limits/`) per ADR-3703. Every file matches the shipped JSON Schema (`contributions/schemas/rate-limit-rule.schema.json`, draft-07) and carries the seven Cloudflare WAF rate-limiting rules documented fields per `https://developers.cloudflare.com/waf/rate-limiting-rules/`.
+
+Example (`cloudflare/rate-limits/public-api-per-ip.json`):
+
+```
+{
+  "id": "public-api-per-ip",
+  "expression": "(http.request.uri.path matches \"^/api/\")",
+  "threshold": 60,
+  "period": 60,
+  "characteristics": ["ip.src", "cf.colo.id"],
+  "action": "block",
+  "duration": 60,
+  "description": "Per-IP-per-colo throttle on /api/*; the (N+1)th request in 60s is blocked for 60s."
+}
+```
+
+The zone id is elicited (`rate-limit-zone-id`) and stored through the applied `secretsManagement` companion; a manifest file never inlines a zone id or an API token.
+
+## Management surface
+
+The blueprint ships no committed script that writes rules to the live zone. The operator applies each rule through one of two documented flows, or both. The elicited `rate-limit-management-surface` value records the choice.
+
+### wrangler flow
+
+The wrangler flow uses the Cloudflare API through a hand-run command sequence. The steps for one rule are:
+
+1. Set `CLOUDFLARE_API_TOKEN` (and `CLOUDFLARE_ACCOUNT_ID` for the account scope) in the operator's environment. Store both through the applied `secretsManagement` companion; never commit them to the git tree.
+2. Load the elicited zone id: `export CF_ZONE_ID=$(cat rcf/blueprints/edge-cloudflare-rate-limiting.applied.json | jq -r .elicits.rateLimitZoneId)` or read it from the applied vault seam.
+3. Fetch the existing rate-limiting ruleset id for the zone via the wrangler-installed API-fetch helper: `wrangler api curl "/zones/${CF_ZONE_ID}/rulesets?phase=http_ratelimit" --method GET` and note the `id` on the returned ruleset (create one if none exists per the vendor doc).
+4. For each rule file, `POST` the rule shape to the ruleset's `/rules` endpoint. The rule body is built from the manifest file by mapping each field one-to-one: `expression`, `action`, and a `ratelimit` object carrying `characteristics`, `period`, `requests_per_period` (from `threshold`), and `mitigation_timeout` (from `duration`).
+5. Verify by listing the ruleset again and confirming every manifest rule appears with the expected fields.
+
+The vendor doc `https://developers.cloudflare.com/waf/rate-limiting-rules/` names the endpoint shape verbatim; the wrangler flow is a hand-run reproduction of that shape.
+
+### Cloudflare dashboard flow
+
+The dashboard flow applies each rule through the Cloudflare zone dashboard. The steps for one rule are:
+
+1. Open the target zone in the Cloudflare dashboard.
+2. Navigate to Security -> WAF -> Rate limiting rules.
+3. Click Create rule; give the rule the manifest file's `id` as the operator-facing name.
+4. In When incoming requests match, set the Custom filter expression to the manifest `expression` (Edit expression toggle to paste raw).
+5. In Then take action, set the action to the manifest `action` (Block, Managed challenge, JS challenge or Log). Set the Duration to the manifest `duration` in seconds.
+6. In With the following properties, set the counting period to the manifest `period` seconds, the requests per period to the manifest `threshold`, and the characteristics to the manifest `characteristics` array (each string mapped to the dashboard's Same request property selectors).
+7. Save the rule. Repeat for every file in the manifest directory.
+
+Both flows produce the same shape on the live zone; the operator picks the flow that fits the project's operating discipline. The elicited `rate-limit-management-surface` records which flow the operator committed to at apply time.
+
+## Composition with security-auth-magic-link
+
+Per ADR-3702, when both `edge-cloudflare-rate-limiting` and `security-auth-magic-link` apply on the same project, the zone-level rate rule layers OVER the per-email application rule. The two rules operate on different characteristic sets and are additive:
+
+| Rule | Characteristic set | Where it runs |
+| --- | --- | --- |
+| Zone rule (this blueprint) | IP-per-URL (e.g. `ip.src` + `http.request.uri.path`) | Cloudflare edge, before any origin Worker code |
+| Application rule (magic-link) | per-email per-minute | Origin Worker mint-surface handler |
+
+Copy-paste example (applying both blueprints in the same project):
+
+```
+rcf define blueprint add ./blueprints/edge-cloudflare-rate-limiting \
+  --answer rate-limit-rules-dir=cloudflare/rate-limits \
+  --answer rate-limit-zone-id=<vault-ref> \
+  --answer rate-limit-management-surface=both \
+  --answer rate-limit-drift-audit-cadence=daily
+
+rcf define blueprint add ./blueprints/security-auth-magic-link \
+  --answer magic-link-mint-rate-limit=5perMinute
+```
+
+The applied recorder records both blueprints so the operator sees the two-rule shape at apply time.
+
+## Drift audit
+
+The blueprint ships a scheduled drift-audit runner realisation in the `cf-edge` fixture at `packages/rcf-lite/test/fixtures/cf-edge/src/drift-audit-runner.mjs`. The runner exports `createDriftAuditRunner({env, eventSink, fetch, clock, cadence, manifestLoader})` per TAC-3703 and fetches the live rules on the elicited zone via `https://api.cloudflare.com/client/v4/zones/{zone_id}/rulesets`, diffs field-by-field against the local manifest, and constructs one drift-audit record per mismatched rule with the metadata-only shape `{ruleId, clientIpHash, outcome, timestamp, diff}`. No record carries a full client IP, a request body or a user agent (event-secrecy discipline per REQ-005 and AC-36107-1).
+
+The elicited `rate-limit-drift-audit-cadence` per ADR-3704 picks `off` (runner not wired), `daily` (24-hour cadence, `recommendedDefault`), or `hourly`.
+
+## Runtime observable and CI
+
+Per spec section 3.1 and ruling 6, the runtime observable for `AC-rateLimiting-overThresholdBlocks` (US-36103/AC-36103-1) is the real-account burst probe. In CI without `CI_HAS_CLOUDFLARE_ACCOUNT` and `CF_RATE_LIMIT_URL`, the probe records `accountBoundSkipped: true` and aggregates to `pass`; this IS the accepted CI verdict. The three local probes (manifest presence, manifest schema validate, event secrecy) always run and always gate the ship.

package/blueprints/edge-cloudflare-turnstile/CHANGELOG.md

@@ -0,0 +1,20 @@
+# Changelog
+
+All notable changes to `edge-cloudflare-turnstile` are recorded here. The shape follows Keep a Changelog and Semantic Versioning per the blueprint authoring standard.
+
+## 1.0.0 (2026-09-07)
+
+### Added
+
+- v1.0.0 mint of the `edge-cloudflare-turnstile` blueprint, category `edge`, capabilities `["humanCheck"]`. Ships a client widget mount, a server-side siteverify verifier that POSTs to `https://challenges.cloudflare.com/turnstile/v0/siteverify` with the elicited secret, a refuse-if-token-missing guard on every elicited surface, and a composition hook into `security-auth-magic-link` mint surface.
+- 5 REQs (`edge-cloudflare-turnstile-REQ-001..005`), 8 USs (`edge-cloudflare-turnstile-US-35101..35108`), 3 TACs (`TAC-3601` widget mount, `TAC-3602` server verifier plus token-required guard, `TAC-3603` magic-link hook), 3 ADRs (`ADR-3601` scope-global on new topic `humanVerificationGate` with `standardsTraceClause: Cloudflare Turnstile siteverify endpoint documented shape`; `ADR-3602` widget mode enum elicit with `recommendedDefault: managed`; `ADR-3603` refuse shape 400 with error-code body and no sitekey leak).
+- 4 Node-only probes under `contributions/probes/`: `secret-shape-scan` (source-tree AST scan asserts `TURNSTILE_SECRET` is only read through the env facade and refuses non-test secret literals), `siteverify-fixture` (drives the LIVE `challenges.cloudflare.com/turnstile/v0/siteverify` endpoint with the pinned always-pass and always-fail Cloudflare test secrets and asserts `success:true` and `success:false` respectively), `guard-shape-scan` (source scan plus live missing-token POST against every guarded surface), `event-secrecy` (asserts every event record carries `{sitekeyHash, outcome, timestamp}` keys only; no token, no secret leak).
+- 1 Playwright probe pack (`probe-packs/edge-cloudflare-turnstile.pack.mjs`) with 4 surface-observable checks per spec section 3.2: `AC-turnstile-widgetRendered` (widget mounts, iframe/script from the Cloudflare Turnstile origin only, `cf-turnstile-response` token populated, no third-party script), `AC-turnstile-serverVerified-pass` (`/api/submit` 200 on always-pass secret), `AC-turnstile-serverVerified-fail` (`/api/submit` 400 on always-fail secret with `errorCodes` and no sitekey leak), `AC-turnstile-magicLinkGuard` (mint refuses missing-token and always-fail-secret with 400 and no mint side-effect).
+- 4 elicited parameters on `blueprint.json`: `turnstile-sitekey`, `turnstile-secret` (routed through `security-secrets-management` when applied), `turnstile-widget-mode` (enum default `managed`), `turnstile-guarded-surfaces`.
+- `suggestedCompanions`: `logging` (for the metadata-only event sink retention), `errorHandling` (for the verifier failure boundary), `secretsManagement` (for the paired sitekey and secret).
+- Ships the dedicated pack fixture at `packages/rcf-lite/test/fixtures/probe-pack-edge-cloudflare-turnstile/` per spec section 3.3. The fixture pins the Cloudflare public test keys documented at `https://developers.cloudflare.com/turnstile/troubleshooting/testing/` as environment defaults so the pack runs without real Turnstile credentials.
+- Anatomy test at `packages/rcf-lite/test/blueprint/edge-cloudflare-turnstile-anatomy.test.js` covers TS-120..127 on the T-5 repo-chain slice.
+
+### Known limitations
+
+- No account-bound probe. Cloudflare Turnstile documents its endpoint and test keys as public; the live siteverify calls in the shipped probes route through Cloudflare with no operator account required. A real-account variant would gate on a specific applying-project sitekey and secret pair; the shipped test-key runs cover the wire-shape contract.

package/blueprints/edge-cloudflare-turnstile/README.md

@@ -0,0 +1,95 @@
+# edge-cloudflare-turnstile
+
+Cloudflare Turnstile as a CAPTCHA-alternative on public-facing forms. Ships the client widget mount, the server-side siteverify verifier (POST to `https://challenges.cloudflare.com/turnstile/v0/siteverify` with the elicited secret), a refuse-if-token-missing guard on every elicited surface, and a composition hook into the `security-auth-magic-link` mint surface.
+
+- Slug: `edge-cloudflare-turnstile`
+- Category: `edge`
+- Version: `1.0.0`
+- Capabilities: `["humanCheck"]`
+- Standards: Cloudflare Turnstile (`https://developers.cloudflare.com/turnstile/`), Cloudflare Turnstile testing (`https://developers.cloudflare.com/turnstile/troubleshooting/testing/`)
+
+## What this blueprint commits
+
+| REQ | Commits |
+|---|---|
+| `edge-cloudflare-turnstile-REQ-001` | Client widget mount: the elicited sitekey renders the Turnstile widget; the mount injects no third-party script beyond the Cloudflare Turnstile JS host. |
+| `edge-cloudflare-turnstile-REQ-002` | Server-side siteverify: POST to `https://challenges.cloudflare.com/turnstile/v0/siteverify` with the elicited secret; on `success:true` the handler proceeds; on `success:false` the handler rejects with 400. |
+| `edge-cloudflare-turnstile-REQ-003` | Refuse-if-token-missing guard on elicited surfaces: a submit without a token rejects with 400 before hitting downstream logic. |
+| `edge-cloudflare-turnstile-REQ-004` | Composition with `security-auth-magic-link`: when both are applied, the magic-link mint surface refuses a submit without a valid Turnstile token. |
+| `edge-cloudflare-turnstile-REQ-005` | Widget mode is an elicited enum: `managed`, `non-interactive`, `invisible` per Cloudflare's documented modes. `recommendedDefault: managed`. |
+
+## Contract at a glance
+
+- **Client widget mount** (TAC-3601) injects Cloudflare Turnstile JS from `https://challenges.cloudflare.com` and no other origin; renders the widget for the elicited sitekey; populates the hidden `Cf-Turnstile-Response` token field on submit.
+- **Server-side siteverify verifier** (TAC-3602) POSTs `{secret, response}` to `https://challenges.cloudflare.com/turnstile/v0/siteverify`. On `success:true` the handler proceeds. On `success:false` the handler rejects with 400 and the refusal body carries the documented `error-codes` value; the sitekey is never in the refusal body.
+- **Refuse-if-token-missing guard** (TAC-3602) is the sole reader of the `Cf-Turnstile-Response` payload field; a submit without a token rejects with `400 {"errorCode":"turnstile.token-missing"}` before any downstream handler runs.
+- **Composition with security-auth-magic-link** (TAC-3603) registers the magic-link mint route under the Turnstile guard so a mint submit reads through the same token check.
+- **Widget mode** (ADR-3602) is an elicited enum: `managed`, `non-interactive`, `invisible`. Default: `managed`.
+
+## Elicited parameters
+
+| Id | Purpose |
+|---|---|
+| `turnstile-sitekey` | Cloudflare Turnstile sitekey the widget renders with. Public per Cloudflare's testing docs when a test sitekey is applied. |
+| `turnstile-secret` | Cloudflare Turnstile secret the server-side verifier POSTs with. Delegated to `security-secrets-management` when applied. |
+| `turnstile-widget-mode` | Enum `managed` \| `non-interactive` \| `invisible`. `recommendedDefault: managed`. |
+| `turnstile-guarded-surfaces` | List of applied route ids the token-required guard registers on. |
+
+## Companions
+
+- **`suggestedCompanions[logging]`**: every siteverify call and every refuse-if-token-missing rejection writes through the applied logger.
+- **`suggestedCompanions[errorHandling]`**: siteverify network failure, malformed token, missing sitekey/secret build an internal error record.
+- **`suggestedCompanions[secretsManagement]`**: the paired sitekey and secret are stored in the operator's applied `secretsManagement` companion.
+
+## Composition
+
+- Consumes `security-secrets-management` for the sitekey/secret pair when applied.
+- Composes with `security-auth-magic-link` at the mint surface via `TAC-3603`.
+- Provides capability `humanCheck` per section 6a of `blueprint-authoring.md`.
+- One scope-global ADR (`ADR-3601`) on new topic `humanVerificationGate`. A future hCaptcha or reCAPTCHA sibling contributes the same topic string with a different answer and forces a deliberate operator-resolved conflict.
+
+## Probes and pack
+
+Four Node-only probes under `contributions/probes/`:
+
+| Probe | Anchors | Engine |
+|---|---|---|
+| `secret-shape-scan` | `AC-35107-1` | Source-tree AST scan over the pack fixture. |
+| `siteverify-fixture` | `AC-35102-1` | Live POST to `https://challenges.cloudflare.com/turnstile/v0/siteverify` with pinned Cloudflare public test secrets. |
+| `guard-shape-scan` | `AC-35104-1` | Source-tree scan plus a live missing-token POST against every guarded surface. |
+| `event-secrecy` | `AC-35108-1` | Live pass + fail runs through the verifier; asserts every event carries `sitekeyHash`, `outcome`, `timestamp` and no token or secret substring. |
+
+One Playwright pack at `probe-packs/edge-cloudflare-turnstile.pack.mjs` with four surface-observable checks: `AC-turnstile-widgetRendered`, `AC-turnstile-serverVerified-pass`, `AC-turnstile-serverVerified-fail`, `AC-turnstile-magicLinkGuard`. The pack ships no `appliesTo` gate; every fixture that applies the blueprint fires every check.
+
+The dedicated pack fixture at `packages/rcf-lite/test/fixtures/probe-pack-edge-cloudflare-turnstile/` pins the Cloudflare public test keys (documented at `https://developers.cloudflare.com/turnstile/troubleshooting/testing/`) as environment defaults so the pack runs without real Turnstile credentials.
+
+## Pinned Cloudflare public test keys
+
+Per Cloudflare's testing page (`https://developers.cloudflare.com/turnstile/troubleshooting/testing/`):
+
+| Sitekey | Behaviour |
+|---|---|
+| `1x00000000000000000000AA` | Always passes |
+| `2x00000000000000000000AB` | Always blocks |
+| `3x00000000000000000000FF` | Forces an interactive challenge |
+| `1x00000000000000000000BB` | Invisible widget, always passes |
+| `2x00000000000000000000BB` | Invisible widget, always blocks |
+
+| Secret | Behaviour |
+|---|---|
+| `1x0000000000000000000000000000000AA` | Always passes on siteverify |
+| `2x0000000000000000000000000000000AA` | Always fails on siteverify |
+| `3x0000000000000000000000000000000AA` | Token already spent |
+
+These keys are public per Cloudflare's documentation; they are safe to pin as fixture defaults and are not operational secrets.
+
+## Risks
+
+1. Client-side widget mounts a third-party script. The `AC-turnstile-widgetRendered` pack check pins the mount to `https://challenges.cloudflare.com` only and fails if any other origin is contacted (see the `?break=other-origin` negative proof in the fixture `proof/` directory).
+2. Test sitekeys are the only always-green option for CI. The guide names the pass, block and forced-interactive modes per Cloudflare's testing page so an operator can pick a mode for staging.
+
+## Standards trace
+
+- Cloudflare Turnstile: `https://developers.cloudflare.com/turnstile/`
+- Cloudflare Turnstile testing: `https://developers.cloudflare.com/turnstile/troubleshooting/testing/`
+- Cloudflare Turnstile siteverify endpoint: `https://challenges.cloudflare.com/turnstile/v0/siteverify`