rcf-lite 0.22.0 → 0.24.0

package/blueprints/edge-cloudflare-access/contributions/user-stories/edge-cloudflare-access-us-34101.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-access-US-34101",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-access-REQ-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Fixture-signed JWT validates and principal reduces onto request.auth",
+  "asA": "shelf consumer applying the edge-cloudflare-access v1.0.0 blueprint on a Workers project using the cf-edge fixture",
+  "iWant": "the Cf-Access-Jwt-Assertion header validated against the fixture Access JWKS on every request, the principal reduced into request.auth as {email, sub, groups} and the downstream handler observes 200 with the reduced principal fields",
+  "soThat": "the Worker only ever sees authenticated principals and downstream code reads a single stable seam for identity",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-34101-1",
+      "description": "The JWT validator reads Cf-Access-Jwt-Assertion, verifies against the fixture JWKS (RS256, kid rotation supported by the per-kid cache), reduces the principal into request.auth as {email, sub, groups} and the downstream handler receives a 200 with the reduced principal fields exposed on request.auth.",
+      "given": "a Worker fetch handler wired with createAccessValidator(...).middleware and a fixture-signed JWT presented in the Cf-Access-Jwt-Assertion header",
+      "when": "the request dispatches through the validator",
+      "then": "the validator resolves, attaches {email, sub, groups} onto request.auth and delegates to the handler which returns 200 with the reduced principal reflected on the response body",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-3501-edge-cloudflare-access-jwt-validator"
+  ],
+  "createdAt": "2026-09-07T16:00:00.000Z",
+  "updatedAt": "2026-09-07T16:00:00.000Z"
+}

package/blueprints/edge-cloudflare-access/contributions/user-stories/edge-cloudflare-access-us-34102.json

@@ -0,0 +1,28 @@
+{
+  "usId": "edge-cloudflare-access-US-34102",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-access-REQ-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Missing, expired or mis-signed JWT rejects 401 with a metadata-only audit event",
+  "asA": "shelf consumer applying the edge-cloudflare-access v1.0.0 blueprint on a Workers project using the cf-edge fixture",
+  "iWant": "requests carrying a missing, expired or mis-signed JWT to reject with 401 and emit exactly one metadata-only audit event on the shipped audit sink",
+  "soThat": "unauthenticated traffic cannot reach the downstream handler and every reject is observable without leaking the token value",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-34102-1",
+      "description": "The three reject subcases (missing header, expired exp, mis-signed) each return HTTP 401 and emit exactly one audit event whose keys are drawn from {email, outcome, timestamp, path} with no token substring, no header names beyond path, and no additional keys.",
+      "given": "a Worker fetch handler wired with createAccessValidator(...).middleware and one of the three reject subcases",
+      "when": "the request dispatches through the validator",
+      "then": "the validator returns 401 and emits one audit event whose outcome is drawn from {missing, expired, invalid} with the allowed-key shape",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-3501-edge-cloudflare-access-jwt-validator",
+    "TAC-3504-edge-cloudflare-access-audit-sink"
+  ],
+  "createdAt": "2026-09-07T16:00:00.000Z",
+  "updatedAt": "2026-09-07T16:00:00.000Z"
+}

package/blueprints/edge-cloudflare-access/contributions/user-stories/edge-cloudflare-access-us-34103.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-access-US-34103",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-access-REQ-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Sole-reader guarantee: src/jwt-validator.mjs is the only module reading the Cf-Access-Jwt-Assertion header",
+  "asA": "shelf consumer applying the edge-cloudflare-access v1.0.0 blueprint on a Workers project using the cf-edge fixture",
+  "iWant": "only src/jwt-validator.mjs to dereference the Cf-Access-Jwt-Assertion header string in the applied source tree",
+  "soThat": "the validator is the single seam and a stray header read in the applied code is a defect the AST scan catches",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-34103-1",
+      "description": "The sole-reader scan walks the fixture applied source root (src/**/*.mjs), strips comments and string literals, and finds exactly one live-source occurrence of the header string Cf-Access-Jwt-Assertion, in src/jwt-validator.mjs. Any other live-source occurrence in a shipped module fails the probe (SIMULATE_NON_VALIDATOR_HEADER=true injects a second hit and the probe fails).",
+      "given": "the cf-edge fixture applied source tree",
+      "when": "the sole-reader-scan probe walks src/**/*.mjs",
+      "then": "the only live-source hit for Cf-Access-Jwt-Assertion is in src/jwt-validator.mjs",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-3501-edge-cloudflare-access-jwt-validator"
+  ],
+  "createdAt": "2026-09-07T16:00:00.000Z",
+  "updatedAt": "2026-09-07T16:00:00.000Z"
+}

package/blueprints/edge-cloudflare-access/contributions/user-stories/edge-cloudflare-access-us-34104.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-access-US-34104",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-access-REQ-002",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Access application declared with elicited hostname or self-hosted-app id and elicited policy shape",
+  "asA": "operator applying the edge-cloudflare-access v1.0.0 blueprint",
+  "iWant": "the blueprint to elicit either an Access application hostname or a self-hosted-app id (one of the two), plus a policy shape from the enum",
+  "soThat": "the apply record captures the exact Access application declaration the operator will issue in the Zero Trust dashboard or over the API",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-34104-1",
+      "description": "blueprint.json elicits access-application-host (kind string) and access-selfhosted-app-id (kind string; the operator supplies exactly one), plus access-audience (kind string), access-jwks-url (kind string), access-policy-shape (kind enum with options email-domain, service-token-only, service-token-plus-email-domain, group-membership; recommended default email-domain) and access-bypass-service-auth-id (kind string; blank disables break-glass). Applying the blueprint records the elicited values on rcf/blueprints/edge-cloudflare-access.applied.json.",
+      "given": "the blueprint.json elicits block",
+      "when": "the apply verb runs against a fixture project",
+      "then": "rcf/blueprints/edge-cloudflare-access.applied.json carries the elicited values plus appliedCapabilities=[zeroTrustGate]",
+      "testable": true,
+      "scope": "library"
+    }
+  ],
+  "tacIds": [
+    "TAC-3502-edge-cloudflare-access-application-declaration"
+  ],
+  "createdAt": "2026-09-07T16:00:00.000Z",
+  "updatedAt": "2026-09-07T16:00:00.000Z"
+}

package/blueprints/edge-cloudflare-access/contributions/user-stories/edge-cloudflare-access-us-34105.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-access-US-34105",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-access-REQ-003",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Guide walks the operator through the Zero Trust dashboard AND documents the API alternative",
+  "asA": "operator applying the edge-cloudflare-access v1.0.0 blueprint",
+  "iWant": "the guide to walk me through issuing the Zero Trust policy on the Cloudflare dashboard AND to document the alternative API path",
+  "soThat": "the policy issuance flow is unambiguous whether I use the dashboard or the API",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-34105-1",
+      "description": "The shipped guide/edge-cloudflare-access.md carries a section Zero Trust dashboard walk-through with numbered steps naming each screen; and a section API alternative with a curl example against https://api.cloudflare.com/client/v4/accounts/{account_id}/access/apps/{app_id}/policies; the vendor URL https://developers.cloudflare.com/cloudflare-one/policies/access/ is cited from ADR-3501 and the guide.",
+      "given": "the shipped guide file",
+      "when": "the anatomy test greps for the two section headings, the curl example and the vendor URL",
+      "then": "each string matches at least once in the file",
+      "testable": true,
+      "scope": "library"
+    }
+  ],
+  "tacIds": [
+    "TAC-3503-edge-cloudflare-access-policy-shape"
+  ],
+  "createdAt": "2026-09-07T16:00:00.000Z",
+  "updatedAt": "2026-09-07T16:00:00.000Z"
+}

package/blueprints/edge-cloudflare-access/contributions/user-stories/edge-cloudflare-access-us-34106.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-access-US-34106",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-access-REQ-004",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Audit event carries only email, outcome, timestamp and path with no token value or headers",
+  "asA": "shelf consumer applying the edge-cloudflare-access v1.0.0 blueprint on a Workers project using the cf-edge fixture",
+  "iWant": "the audit sink to receive only metadata-only records for every validate-pass and validate-reject",
+  "soThat": "the audit trail is observable without leaking the JWT, its signature bytes or any request header value",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-34106-1",
+      "description": "After 5 validate-pass and 5 validate-reject requests the audit sink holds 10 records each carrying exactly {email, outcome, timestamp, path}; the serialised JSON of every record contains no substring of the JWT (header, payload or signature), no Authorization value and no header names beyond path.",
+      "given": "the shipped createAccessValidator wired with a spy audit sink and 10 requests (5 pass, 5 reject)",
+      "when": "the requests dispatch through the validator",
+      "then": "10 sink records, each with allowed keys only, none containing forbidden substrings",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-3504-edge-cloudflare-access-audit-sink"
+  ],
+  "createdAt": "2026-09-07T16:00:00.000Z",
+  "updatedAt": "2026-09-07T16:00:00.000Z"
+}

package/blueprints/edge-cloudflare-access/contributions/user-stories/edge-cloudflare-access-us-34107.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-access-US-34107",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-access-REQ-005",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Break-glass posture: an elicited bypass-service-auth pair authenticates CI automation",
+  "asA": "operator running CI-signed automation against an Access-gated Worker",
+  "iWant": "an elicited bypass-service-auth token pair that the validator recognises and passes through as an authenticated principal",
+  "soThat": "CI can hit the gated Worker without a browser flow while every bypass leaves a distinct audit trace",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-34107-1",
+      "description": "When the request presents the elicited service-auth id and secret (as CF-Access-Client-Id and CF-Access-Client-Secret headers), the validator observes the pair, records outcome=bypass in the audit event with the metadata-only shape, and delegates to the handler as authenticated with request.auth.email='service:'+id. Break-glass is disabled unless the elicited pair is applied.",
+      "given": "the createAccessValidator wired with an elicited bypass-service-auth pair and a request presenting the paired headers",
+      "when": "the request dispatches through the validator",
+      "then": "the handler receives request.auth with the service principal and the audit sink records outcome=bypass with allowed keys only",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-3501-edge-cloudflare-access-jwt-validator"
+  ],
+  "createdAt": "2026-09-07T16:00:00.000Z",
+  "updatedAt": "2026-09-07T16:00:00.000Z"
+}

package/blueprints/edge-cloudflare-access/contributions/user-stories/edge-cloudflare-access-us-34108.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-access-US-34108",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-access-REQ-006",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Admin-console composition: the sign-in surface flips per applied capability set",
+  "asA": "shelf consumer applying both edge-cloudflare-access and application-admin-console v1.1.0",
+  "iWant": "the admin-console sign-in surface to flip to Access-gated when zeroTrustGate is applied, and to fall back to the local security-auth-* surface otherwise",
+  "soThat": "the composition is deterministic and no local login form leaks into an Access-gated deployment",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-34108-1",
+      "description": "Two applied combinations are exercised on the extended admin-console fixture: with ?caps=principalDirectory,roleModel,auditLog,zeroTrustGate the sign-in surface renders [data-surface=access-gated] and no [data-surface=local-login] is present; with ?caps=principalDirectory,roleModel,auditLog the sign-in surface renders [data-surface=local-login] and no [data-surface=access-gated] is present. Both combinations exercise the shipped pack check AC-21815-1 on application-admin-console.pack.mjs (pack check fires only on the gated combination).",
+      "given": "the extended admin-console pack fixture with the two caps combinations",
+      "when": "the pack runs against each combination",
+      "then": "AC-21815-1 fires on the gated combination and passes; the existing v1.0.0 surface renders on the non-gated combination and its own checks pass",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-3502-edge-cloudflare-access-application-declaration"
+  ],
+  "createdAt": "2026-09-07T16:00:00.000Z",
+  "updatedAt": "2026-09-07T16:00:00.000Z"
+}

package/blueprints/edge-cloudflare-access/contributions/user-stories/edge-cloudflare-access-us-34109.json

@@ -0,0 +1,27 @@
+{
+  "usId": "edge-cloudflare-access-US-34109",
+  "prdId": "PRD-001",
+  "reqId": "edge-cloudflare-access-REQ-006",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Real-account gated URL round-trip against a scheduled Access-configured hostname",
+  "asA": "HQ operator running the real-account gated-URL smoke against a scheduled Access-configured hostname",
+  "iWant": "the probe to fire against the hostname when the env vars are present and record accountBoundSkipped when not",
+  "soThat": "the mechanism-reach claim is proven on a real Cloudflare Access instance without ever failing the shelf gate on the absence of an account",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-34109-1",
+      "description": "With CI_HAS_CLOUDFLARE_ACCOUNT=true and CF_ACCESS_HOST=<hostname>, a plain fetch against https://<hostname>/ follows the redirect chain and terminates at an https://<team>.cloudflareaccess.com/ URL (the Access UI). Without either env var the probe records accountBoundSkipped=true and aggregateVerdict=pass per spec section 3.5.",
+      "given": "the run-real-account-gated-url.mjs probe shim and the two env vars",
+      "when": "the probe runs",
+      "then": "in the CI-with-account path the redirect chain reports cloudflareaccess.com as terminal; in the without-env path accountBoundSkipped is true",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-3502-edge-cloudflare-access-application-declaration"
+  ],
+  "createdAt": "2026-09-07T16:00:00.000Z",
+  "updatedAt": "2026-09-07T16:00:00.000Z"
+}

package/blueprints/edge-cloudflare-access/docs/topics.md

@@ -0,0 +1,68 @@
+# edge-cloudflare-access blueprint coordination vocabulary
+
+This file is the edge-cloudflare-access 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-access contribution | Origin | Composition note |
+|---|---|---|---|
+| `edgeAuthenticationGate` | ADR-3501-edge-cloudflare-access-jwt-gate | Minted by this blueprint. Names the wire-shape contract for the project-wide edge authentication gate; the shipped answer is a Cloudflare Access Zero-Trust JWT-assertion gate per https://developers.cloudflare.com/cloudflare-one/policies/access/. | The one project-wide decision on the edge authentication gate at the shipped-shape boundary. A future non-Cloudflare sibling (Google Cloud IAP, AWS Verified Access, Duo Beyond) 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-access blueprint claims one global topic (minted here, shipped as the Cloudflare Access JWT-assertion gate). ADR-3502 identity provider, ADR-3503 policy scope and ADR-3504 audit retention do not contribute global topics; a composing blueprint that holds an opinion on any of them 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.0.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 34101-34109 sit at the LOW end of the 34101-34899 band on purpose (watchpost run-4 lesson). ADR/TAC suffixes for this blueprint use the 3501-3599 block, continuing the shelf pattern.
+
+## Shared expectations for future composing blueprints
+
+- Reuse `edgeAuthenticationGate` exactly as spelled here when your blueprint holds an opinion on the edge authentication gate contract; contribute your own scope:global ADR on that string and let composition surface the pairing.
+- Consumer blueprints reading the `zeroTrustGate` capability declared on `blueprint.json` per section 6a of `blueprint-authoring.md` obtain the Access-gated composition at apply time via the T-5 visual-round capability-declaration mechanism.
+
+## Deliberate-conflict statement
+
+This blueprint's ADR-3501 on `edgeAuthenticationGate` is the first shipped answer to a topic that will conflict, by design, with future non-Cloudflare siblings. Applying `edge-cloudflare-access` 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-access/guide/edge-cloudflare-access.md

@@ -0,0 +1,180 @@
+# edge-cloudflare-access guide
+
+## When to reach for this blueprint
+
+You reach for `edge-cloudflare-access` when your Workers project
+needs an authenticated edge (only authenticated principals reach
+the origin Worker), when you have adopted the Zero Trust posture,
+and when you want a vendor-neutral seam (`request.auth`) between
+Cloudflare's Access edge and your downstream handlers.
+
+If you are shipping a fully-public Worker (no authentication at all),
+this blueprint is not for you. If you are running a security-auth-*
+blueprint inside the Worker (in-app authentication), you probably
+also want Cloudflare Access as a second layer to keep unauthenticated
+traffic off the origin; the composition is straightforward.
+
+## Composition with application-admin-console
+
+Applying `application-admin-console` v1.1.0 alongside this blueprint
+flips the admin-console sign-in surface (`/admin/sign-in`):
+
+- With `zeroTrustGate` in the applied capability set (this
+  blueprint declares it): the sign-in page renders
+  `[data-surface=access-gated]` with no local form.
+- Without `zeroTrustGate` (this blueprint not applied): the
+  sign-in page renders `[data-surface=local-login]` with the local
+  `security-auth-*` form unchanged from v1.0.0.
+
+The Q4 default (spec section 5.4.1) is: consumption is OPTIONAL.
+The v1.1.0 admin-console remains backward-compatible with every
+v1.0.0 deployment.
+
+## Elicited parameters at apply
+
+- `access-application-host` OR `access-selfhosted-app-id`: pick
+  exactly one. The dashboard walk-through follows the hostname
+  path when the first is set and the self-hosted-app id path
+  when the second is set.
+- `access-audience`: the JWT audience tag the Access policy issues.
+  Every JWT the validator accepts must carry this string as its
+  `aud` claim.
+- `access-jwks-url`: the JWKS endpoint URL the validator fetches.
+  Cloudflare Access publishes this at
+  `https://<team>.cloudflareaccess.com/cdn-cgi/access/certs`.
+- `access-policy-shape` (default `email-domain`): one of the four
+  values in the enum below.
+- `access-bypass-service-auth-id`: leave blank to disable
+  break-glass. When set, the paired secret is delegated to the
+  applied `secretsManagement` companion.
+
+## Policy shape enum
+
+| Shape | What it allows | Suited to |
+| --- | --- | --- |
+| `email-domain` | Any principal whose email ends `@<domain>` on the Access-managed identity provider. | Solo, small team, workspace-wide access on a company domain. |
+| `service-token-only` | Only the elicited bypass-service-auth pair; no browser principals. | CI-only endpoints (webhooks, ingest APIs). |
+| `service-token-plus-email-domain` | Either the paired service-auth or an on-domain email principal. | Endpoints reached by CI AND humans. |
+| `group-membership` | Only principals whose identity-provider group claim contains an elicited group name (Okta, Entra ID, Google Groups). | Enterprise SSO with role-based access. |
+
+The Cloudflare edge enforces the shape before a request reaches
+the origin Worker; the shipped validator receives the JWT the
+Access edge signs and verifies the audience, the expiry and the
+signature.
+
+## Zero Trust dashboard walk-through
+
+Screen-by-screen path for a fresh Cloudflare account. Vendor URL:
+`https://developers.cloudflare.com/cloudflare-one/policies/access/`.
+
+1. Sign in to `dash.cloudflare.com` and select your account.
+2. In the left nav, open `Zero Trust`. If the dashboard prompts
+   you to create a team, do so with the elicited team name (the
+   `<team>` in `https://<team>.cloudflareaccess.com/`).
+3. In the Zero Trust dashboard, open `Access` -> `Applications`,
+   then `Add an application`.
+4. Pick `Self-hosted` (both for hostname-scoped applications and
+   for self-hosted-app id-based applications).
+5. Enter the application name (`admin.example.com` for the
+   hostname path or the app id string for the self-hosted-app id
+   path), the session duration (default 24h is fine for an
+   internal console) and the application domain (the hostname
+   the Worker binds to).
+6. On the `Add policies` screen, `Add a policy`.
+7. On the policy screen, pick the `Action` (`Allow` for the
+   principal set the shape names above), then add one `Include`
+   selector matching the shape:
+   - `email-domain`: `Include -> Email ending in` -> your domain.
+   - `service-token-only`: `Include -> Service Auth Token` -> the
+     token generated in `Zero Trust` -> `Access` -> `Service Auth`.
+   - `service-token-plus-email-domain`: add both selectors.
+   - `group-membership`: `Include -> IdP Group name` -> the group
+     the elicited identity-provider claims.
+8. Save the policy, save the application. The dashboard prints
+   the `Application audience tag` at the top of the application
+   card; copy it verbatim into the `access-audience` elicit
+   answer on apply.
+9. Confirm the JWKS endpoint at
+   `https://<team>.cloudflareaccess.com/cdn-cgi/access/certs`
+   returns a valid JWKS document; copy the URL into the
+   `access-jwks-url` elicit answer.
+
+The blueprint is now ready to apply on the Worker project.
+
+## API alternative
+
+If you prefer to script the policy issuance rather than click
+through the dashboard, use the Cloudflare API. Vendor URL:
+`https://developers.cloudflare.com/cloudflare-one/policies/access/`.
+
+```
+curl -X POST \
+  https://api.cloudflare.com/client/v4/accounts/{account_id}/access/apps/{app_id}/policies \
+  -H "Authorization: Bearer $CF_API_TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "name": "Access policy for admin.example.com",
+    "decision": "allow",
+    "include": [
+      { "email_domain": { "domain": "example.com" } }
+    ],
+    "session_duration": "24h"
+  }'
+```
+
+Replace the `include` block with the shape you picked from the
+enum. The `app_id` is the value the dashboard printed when the
+application was created; the `account_id` is the standard
+Cloudflare account id from your account settings. The endpoint is
+idempotent when the policy name matches an existing policy per
+Cloudflare's documented semantics.
+
+## Break-glass posture
+
+Set `access-bypass-service-auth-id` at apply to enable break-glass.
+The paired secret is delegated to the applied `secretsManagement`
+companion via `security-secrets-management`; the CI runner then
+supplies both values as `CF-Access-Client-Id` and
+`CF-Access-Client-Secret` headers on every request that would
+otherwise fail Access at the browser boundary. The validator
+observes the pair, records `outcome: bypass` on the audit sink
+with the metadata-only shape, and delegates to the handler with
+`request.auth.email = 'service:'+id`.
+
+The break-glass code path is disabled unless an elicited pair is
+applied; a request presenting the paired headers when no pair is
+elicited is rejected as `missing` (fall through to the JWT path).
+
+## Composed apply-line
+
+One project, admin-console v1.1.0 plus edge-cloudflare-access
+v1.0.0, `email-domain` policy shape:
+
+```
+rcf define blueprint add application-admin-console --version 1.1.0
+rcf define blueprint add edge-cloudflare-access --version 1.0.0 \
+  --answer access-application-host=admin.example.com \
+  --answer access-audience=<audience-copied-from-dashboard> \
+  --answer access-jwks-url=https://<team>.cloudflareaccess.com/cdn-cgi/access/certs \
+  --answer access-policy-shape=email-domain
+```
+
+The admin-console applies first (its `principalDirectory`
+requirement is met by whatever `security-auth-*` you have
+applied). The Access blueprint applies second, records
+`zeroTrustGate` on `rcf/blueprints/edge-cloudflare-access.applied.json`,
+and the admin-console's next surface render picks the Access-gated
+branch on `/admin/sign-in`.
+
+## Standards trace
+
+- `ADR-3501-edge-cloudflare-access-jwt-gate` carries
+  `standardsTraceClause: Cloudflare Access policy actions and rule
+  selectors` per
+  https://developers.cloudflare.com/cloudflare-one/policies/access/.
+- `ADR-3503-edge-cloudflare-access-policy-scope` carries the same
+  clause.
+- `ADR-3502-edge-cloudflare-access-identity-provider` and
+  `ADR-3504-edge-cloudflare-access-audit-retention` carry the
+  sentinel `generic enterprise practice` (no vendor documentation
+  constrains identity provider or audit retention).

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

@@ -0,0 +1,10 @@
+# edge-cloudflare-rate-limiting changelog
+
+## 1.0.0 (round 6 T-6, 2026-09-07)
+
+- First shipped version. Zone-level rate limiting as an edge gate in front of Worker handlers per the ratified `cloudflare-round-6-spec-2026-09-06.md` section 5.6.
+- Five REQs, eight USs, three TACs, four ADRs. Twenty contributions total.
+- Ships the local rate-limit rules manifest schema (draft-07), the operator-facing management surface guide with both wrangler and dashboard flows, the drift-audit runner realisation on the `cf-edge` fixture and the composition ADR with `security-auth-magic-link`.
+- Mints capability `edgeRateLimit` and global topic `edgeThrottleContract` (ADR-3701, scope global).
+- Four Node-only probes: `manifest-presence`, `manifest-schema-validate`, `event-secrecy`, `real-account-burst-and-429`. The last carries `accountBound: true` and records `accountBoundSkipped: true` in CI without `CI_HAS_CLOUDFLARE_ACCOUNT` per spec section 3.5 and ruling 6.
+- `cf-edge` fixture extended additively: `cloudflare/rate-limits/example.json`, `cloudflare/rate-limits/api-writes.json`, `src/drift-audit-runner.mjs`, three induced-failure switches (`SIMULATE_MANIFEST_MISSING`, `SIMULATE_SCHEMA_INVALID`, `SIMULATE_EVENT_LEAK_IP`).

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

@@ -0,0 +1,73 @@
+# edge-cloudflare-rate-limiting
+
+Zone-level rate limiting as an edge gate in front of Worker handlers, configured through a local manifest the applying project commits and applies to the live Cloudflare zone via a documented wrangler or dashboard flow. Ships v1.0.0 of the round-6 T-6 track per `projects/blueprint-library/specs/cloudflare-round-6-spec-2026-09-06.md` section 5.6.
+
+- **Category:** `edge`.
+- **Capability provided:** `edgeRateLimit`.
+- **Global topic minted:** `edgeThrottleContract` (ADR-3701, scope global).
+- **Suggested companions:** `logging`, `errorHandling`, `secretsManagement`.
+
+## The five REQs
+
+| Id | What it commits |
+| --- | --- |
+| REQ-001 | Local rules manifest: one JSON file per rule under the elicited `rate-limit-rules-dir` (default `cloudflare/rate-limits/`) carries the seven documented fields. |
+| REQ-002 | Operator-facing management surface: a documented wrangler or Cloudflare-dashboard flow the operator runs to apply the manifest to the live zone. No committed script. |
+| REQ-003 | Over-threshold behaviour: over the rule limit within the period, the (N+1)th and subsequent requests within the elicited duration return 429 with `Retry-After` and `Cf-Ray`; the origin never sees them. |
+| REQ-004 | Drift audit: an opt-in scheduled runner reads live zone rules via the Cloudflare API and diffs against the local manifest, constructing metadata-only records per REQ-005 event-secrecy. |
+| REQ-005 | Composition with `security-auth-magic-link`: the zone rule sits OVER the per-email application rule per ADR-3702 layering. |
+
+## Elicited parameters
+
+- `rate-limit-rules-dir` (default `cloudflare/rate-limits`): where the applying project commits manifest files.
+- `rate-limit-zone-id` (default empty): the Cloudflare zone id the rules apply to. Never inlined in a manifest file; stored via the applied `secretsManagement` companion.
+- `rate-limit-management-surface` (default `both`): `wrangler`, `dashboard`, or `both`. Records the operator's flow choice; the guide walks both.
+- `rate-limit-drift-audit-cadence` (default `daily`): `off`, `daily`, `hourly`. Per ADR-3704.
+
+## Manifest shape (TAC-3701)
+
+The shipped JSON Schema at `contributions/schemas/rate-limit-rule.schema.json` (draft-07) names the seven required fields per `https://developers.cloudflare.com/waf/rate-limiting-rules/`:
+
+| Field | Type | Meaning |
+| --- | --- | --- |
+| `id` | string | Stable operator-facing rule id (kebab-case). Used as `ruleId` in drift-audit records. |
+| `expression` | string | Cloudflare WAF rules-language expression scoping the rule. |
+| `threshold` | integer >=1 | Requests permitted per period on the characteristic set. |
+| `period` | integer >=1 | Window in seconds the threshold applies over. |
+| `characteristics` | string[] (non-empty) | Characteristic strings the rule keys on (e.g. `ip.src`, `cf.colo.id`). |
+| `action` | enum | `block`, `challenge`, `log`, `managed_challenge`. |
+| `duration` | integer >=1 | Block window in seconds the (N+1)th and subsequent requests are refused for. |
+
+`additionalProperties: false`; a `description` field is optional.
+
+## Probes
+
+Four Node-only probes under `contributions/probes/`; three run in CI, one is account-bound and skips per ruling 6.
+
+| Probe | Anchor AC | `accountBound` | What it drives |
+| --- | --- | --- | --- |
+| `manifest-presence.mjs` | AC-36101-1 (also AC-36108-1 under `SIMULATE_MANIFEST_MISSING=true`) | false | Reads `cf-edge/cloudflare/rate-limits/`, asserts every file parses, carries the seven required fields and holds no plaintext secret. |
+| `manifest-schema-validate.mjs` | AC-36106-1 | false | Validates every manifest file against the shipped JSON Schema. Under `SIMULATE_SCHEMA_INVALID=true` writes a scratch file missing `threshold` and fails. |
+| `event-secrecy.mjs` | AC-36107-1 | false | Drives the shipped drift-audit runner realisation with a synthetic manifest and a fake fetch; asserts every drift record carries only `{ruleId, clientIpHash, outcome, timestamp, diff}`. Under `SIMULATE_EVENT_LEAK_IP=true` the runner injects a full IP and the probe fails. |
+| `real-account-burst-and-429.mjs` | AC-36103-1 | true | Fires an in-process burst against `CF_RATE_LIMIT_URL` under `CI_HAS_CLOUDFLARE_ACCOUNT=true` and asserts the (N+1)th and subsequent responses return 429 with `Retry-After` and `Cf-Ray`. Without either env var records `accountBoundSkipped: true` and aggregates to `pass` per spec section 3.5 and ruling 6. |
+
+### Ruling 6 restated
+
+Spec section 1, verbatim: "If the rate-limiting real-account burst probe is not CI-feasible, ship with the local manifest AC and mark the burst check account-bound skipped." Without `CI_HAS_CLOUDFLARE_ACCOUNT` the CI verdict for `real-account-burst-and-429` is `accountBoundSkipped: true` and this IS the accepted verdict; the aggregate flips to `pass`. The local manifest ACs (AC-36101-1, AC-36106-1, AC-36107-1) always run and always gate the ship.
+
+## Composition with `security-auth-magic-link` (ADR-3702)
+
+When both blueprints apply, the zone-level rate rule (characteristic set: IP-per-URL) sits at the CF edge and refuses the (N+1)th request for the elicited duration before it reaches the origin; the `security-auth-magic-link` per-email application rate limiter (characteristic set: per-email per-minute) continues to run on requests that pass the edge gate at the mint-surface. The two rules operate on different characteristic sets and are additive, not overlapping. See the guide for a copy-paste example.
+
+## Standards trace
+
+- ADR-3701: `Cloudflare WAF rate-limiting rules documented shape` (`https://developers.cloudflare.com/waf/rate-limiting-rules/`).
+- ADR-3702, ADR-3703, ADR-3704: `generic enterprise practice`.
+
+## Vendor citations
+
+- Cloudflare WAF rate-limiting rules: `https://developers.cloudflare.com/waf/rate-limiting-rules/` (documents `expression`, `threshold`, `period`, `characteristics`, `action`, `duration`; fetched 200 on 2026-09-07 for the round-6 T-6 ship).
+
+## Known mechanism-reach gaps
+
+- The over-threshold observable (AC-36103-1) is only proven at the runtime seam with a real Cloudflare account. In CI without `CI_HAS_CLOUDFLARE_ACCOUNT` the probe records `accountBoundSkipped: true` per ruling 6; the local manifest and event-secrecy ACs cover source-observable correctness.