rcf-lite 0.22.0 → 0.24.0

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`

package/blueprints/edge-cloudflare-turnstile/blueprint.json

@@ -0,0 +1,161 @@
+{
+  "slug": "edge-cloudflare-turnstile",
+  "version": "1.0.0",
+  "category": "edge",
+  "capabilities": [
+    "humanCheck"
+  ],
+  "suggestedCompanions": [
+    {
+      "role": "logging",
+      "reason": "Every siteverify call and every refuse-if-token-missing rejection writes through the applied logger; a logging companion supplies the sink factory."
+    },
+    {
+      "role": "errorHandling",
+      "reason": "A siteverify network failure, a malformed token or a missing sitekey and secret constructs an internal error record; an error-handling companion supplies the record factory and the boundary."
+    },
+    {
+      "role": "secretsManagement",
+      "reason": "The paired TURNSTILE_SITEKEY and TURNSTILE_SECRET are stored in the operator applied secretsManagement companion; the applied vault seam receives the elicited values at apply time and injects them at deploy."
+    }
+  ],
+  "elicits": [
+    {
+      "id": "turnstile-sitekey",
+      "prompt": "Cloudflare Turnstile sitekey the widget renders with. See https://developers.cloudflare.com/turnstile/ for issuing. Test sitekeys are pinned in the shipped fixture per https://developers.cloudflare.com/turnstile/troubleshooting/testing/.",
+      "kind": "string",
+      "default": ""
+    },
+    {
+      "id": "turnstile-secret",
+      "prompt": "Cloudflare Turnstile secret the server-side verifier posts to siteverify with. Never inline; stored via the applied secretsManagement companion or your environment.",
+      "kind": "string",
+      "default": ""
+    },
+    {
+      "id": "turnstile-widget-mode",
+      "prompt": "Cloudflare Turnstile widget mode per ADR-3602 and https://developers.cloudflare.com/turnstile/. managed (recommendedDefault; Cloudflare decides when to show the challenge); non-interactive (always shows a non-interactive challenge); invisible (mounts an invisible widget).",
+      "kind": "enum",
+      "options": [
+        "managed",
+        "non-interactive",
+        "invisible"
+      ],
+      "default": "managed"
+    },
+    {
+      "id": "turnstile-guarded-surfaces",
+      "prompt": "List of applied route ids the token-required guard registers on. Every guarded surface refuses missing-token submits with 400 before any downstream handler runs.",
+      "kind": "string",
+      "default": ""
+    }
+  ],
+  "contributions": [
+    {
+      "id": "edge-cloudflare-turnstile-REQ-001",
+      "kind": "req",
+      "path": "requirements/edge-cloudflare-turnstile-req-001.json"
+    },
+    {
+      "id": "edge-cloudflare-turnstile-REQ-002",
+      "kind": "req",
+      "path": "requirements/edge-cloudflare-turnstile-req-002.json"
+    },
+    {
+      "id": "edge-cloudflare-turnstile-REQ-003",
+      "kind": "req",
+      "path": "requirements/edge-cloudflare-turnstile-req-003.json"
+    },
+    {
+      "id": "edge-cloudflare-turnstile-REQ-004",
+      "kind": "req",
+      "path": "requirements/edge-cloudflare-turnstile-req-004.json"
+    },
+    {
+      "id": "edge-cloudflare-turnstile-REQ-005",
+      "kind": "req",
+      "path": "requirements/edge-cloudflare-turnstile-req-005.json"
+    },
+    {
+      "id": "edge-cloudflare-turnstile-US-35101",
+      "kind": "us",
+      "path": "user-stories/edge-cloudflare-turnstile-us-35101.json"
+    },
+    {
+      "id": "edge-cloudflare-turnstile-US-35102",
+      "kind": "us",
+      "path": "user-stories/edge-cloudflare-turnstile-us-35102.json"
+    },
+    {
+      "id": "edge-cloudflare-turnstile-US-35103",
+      "kind": "us",
+      "path": "user-stories/edge-cloudflare-turnstile-us-35103.json"
+    },
+    {
+      "id": "edge-cloudflare-turnstile-US-35104",
+      "kind": "us",
+      "path": "user-stories/edge-cloudflare-turnstile-us-35104.json"
+    },
+    {
+      "id": "edge-cloudflare-turnstile-US-35105",
+      "kind": "us",
+      "path": "user-stories/edge-cloudflare-turnstile-us-35105.json"
+    },
+    {
+      "id": "edge-cloudflare-turnstile-US-35106",
+      "kind": "us",
+      "path": "user-stories/edge-cloudflare-turnstile-us-35106.json"
+    },
+    {
+      "id": "edge-cloudflare-turnstile-US-35107",
+      "kind": "us",
+      "path": "user-stories/edge-cloudflare-turnstile-us-35107.json"
+    },
+    {
+      "id": "edge-cloudflare-turnstile-US-35108",
+      "kind": "us",
+      "path": "user-stories/edge-cloudflare-turnstile-us-35108.json"
+    },
+    {
+      "id": "TAC-3601-edge-cloudflare-turnstile-widget-mount",
+      "kind": "tac",
+      "path": "tacs/tac-3601-edge-cloudflare-turnstile-widget-mount.json"
+    },
+    {
+      "id": "TAC-3602-edge-cloudflare-turnstile-server-verifier",
+      "kind": "tac",
+      "path": "tacs/tac-3602-edge-cloudflare-turnstile-server-verifier.json"
+    },
+    {
+      "id": "TAC-3603-edge-cloudflare-turnstile-magic-link-hook",
+      "kind": "tac",
+      "path": "tacs/tac-3603-edge-cloudflare-turnstile-magic-link-hook.json"
+    },
+    {
+      "id": "ADR-3601-edge-cloudflare-turnstile-verifier-contract",
+      "kind": "adr",
+      "path": "adrs/adr-3601-edge-cloudflare-turnstile-verifier-contract.json",
+      "scope": "global",
+      "topic": "humanVerificationGate",
+      "recommendedDefault": true,
+      "elicited": false,
+      "standardsTraceClause": "Cloudflare Turnstile siteverify endpoint documented shape"
+    },
+    {
+      "id": "ADR-3602-edge-cloudflare-turnstile-widget-mode",
+      "kind": "adr",
+      "path": "adrs/adr-3602-edge-cloudflare-turnstile-widget-mode.json",
+      "recommendedDefault": true,
+      "elicited": true,
+      "standardsTraceClause": "Cloudflare Turnstile documented widget modes"
+    },
+    {
+      "id": "ADR-3603-edge-cloudflare-turnstile-refuse-shape",
+      "kind": "adr",
+      "path": "adrs/adr-3603-edge-cloudflare-turnstile-refuse-shape.json",
+      "recommendedDefault": true,
+      "elicited": false,
+      "standardsTraceClause": "Cloudflare Turnstile documented error codes"
+    }
+  ]
+}

package/blueprints/edge-cloudflare-turnstile/contributions/adrs/adr-3601-edge-cloudflare-turnstile-verifier-contract.json

@@ -0,0 +1,14 @@
+{
+  "adrId": "ADR-3601-edge-cloudflare-turnstile-verifier-contract",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "Human verification gate: Cloudflare Turnstile with server-side siteverify (scope global, new topic humanVerificationGate)",
+  "context": "An applying project that mounts a public-facing form (contact, subscribe, magic-link mint, low-cost-per-request public API) needs a human verification gate that keeps unattended bots off the form. Cloudflare Turnstile is the CF-native answer: a client widget that emits a response token and a server-side siteverify endpoint (https://challenges.cloudflare.com/turnstile/v0/siteverify) that returns success:true or success:false with error-codes per https://developers.cloudflare.com/turnstile/. Every applied Worker needs one project-wide answer to the humanVerificationGate topic; a future non-Cloudflare sibling (hCaptcha, reCAPTCHA) would conflict on the same topic by design.",
+  "decision": "The shipped v1.0.0 default is Cloudflare Turnstile with server-side siteverify. The verifier POSTs {secret, response} to https://challenges.cloudflare.com/turnstile/v0/siteverify per the Cloudflare Turnstile documented endpoint shape. On success:true the handler proceeds; on success:false the handler rejects 400 with the error-codes value in the refusal body. The humanVerificationGate topic scope is global on this blueprint; the topic string is humanVerificationGate (lower camel case, one concept per topic, no version suffix). Standards trace clause: Cloudflare Turnstile siteverify endpoint documented shape.",
+  "consequences": "The applying project inherits Cloudflare Turnstile documented widget-and-siteverify contract per https://developers.cloudflare.com/turnstile/. A future hCaptcha or reCAPTCHA sibling contributes the same humanVerificationGate topic with a different answer, forcing a DELIBERATE operator-resolved conflict at the project ADR level. The pack fixture pins Cloudflare public test keys per https://developers.cloudflare.com/turnstile/troubleshooting/testing/ so the pack does not need real Turnstile credentials to run.",
+  "alternativesConsidered": [],
+  "createdAt": "2026-09-07T20:00:00.000Z",
+  "updatedAt": "2026-09-07T20:00:00.000Z"
+}

package/blueprints/edge-cloudflare-turnstile/contributions/adrs/adr-3602-edge-cloudflare-turnstile-widget-mode.json

@@ -0,0 +1,14 @@
+{
+  "adrId": "ADR-3602-edge-cloudflare-turnstile-widget-mode",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "Widget mode is elicited as an enum (managed, non-interactive, invisible); recommendedDefault managed",
+  "context": "Cloudflare Turnstile documents three widget modes per https://developers.cloudflare.com/turnstile/: managed (Cloudflare decides when to show a challenge, minimising user friction), non-interactive (always renders a non-interactive challenge for uniform behaviour) and invisible (mounts an invisible widget). Each mode is a per-surface operational profile; the elicit forces the operator to name the intent.",
+  "decision": "Widget mode is elicited (elicited: true). Values: managed, non-interactive, invisible per Cloudflare Turnstile documented modes. recommendedDefault: managed. The applied-sidecar records the operator answer per applying surface. Standards trace clause: Cloudflare Turnstile documented widget modes.",
+  "consequences": "The elicitation forces an explicit answer on every apply. The pack fixture accepts ?mode=<managed|non-interactive|invisible> and pins the invisible-widget test sitekeys (1x00000000000000000000BB and 2x00000000000000000000BB per https://developers.cloudflare.com/turnstile/troubleshooting/testing/) alongside the managed pass/fail sitekeys so every mode is exercised on the gate.",
+  "alternativesConsidered": [],
+  "createdAt": "2026-09-07T20:00:00.000Z",
+  "updatedAt": "2026-09-07T20:00:00.000Z"
+}

package/blueprints/edge-cloudflare-turnstile/contributions/adrs/adr-3603-edge-cloudflare-turnstile-refuse-shape.json

@@ -0,0 +1,14 @@
+{
+  "adrId": "ADR-3603-edge-cloudflare-turnstile-refuse-shape",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "Refuse-if-token-missing status is 400 with an error-code body (no sitekey leak); siteverify failure carries the documented error-codes value",
+  "context": "Cloudflare Turnstile siteverify returns {success: false, error-codes: [...]} on failure per https://developers.cloudflare.com/turnstile/. The applying project needs a stable refusal shape that never leaks the sitekey, the secret or the response token into an error body or event record.",
+  "decision": "Refuse-if-token-missing status is 400. Refusal body carries a stable error-code: turnstile.token-missing for the guard branch, or the Cloudflare error-codes[0] for the siteverify-failure branch. Refusal body never carries the sitekey, the secret or the response token value. Standards trace clause: Cloudflare Turnstile documented error codes.",
+  "consequences": "The 400 status is machine-observable at every applied surface; downstream observability records the outcome by error-code, not by sitekey. Event records ship {sitekeyHash, outcome, timestamp} only; the event-secrecy probe asserts this shape (AC-35108-1).",
+  "alternativesConsidered": [],
+  "createdAt": "2026-09-07T20:00:00.000Z",
+  "updatedAt": "2026-09-07T20:00:00.000Z"
+}