docs: make protocol and buyer-facing claims current

API_CONFIG_CONTRACT.md

@@ -70,7 +70,7 @@ Version 2 retains all version-1 generic network/runtime invariants and requires
 
 The only admitted ALPN policy is `h2_http1`. The delivery adapter uses Pingora/OpenSSL's public ALPN callback surface to prefer `h2`, fall back to `http/1.1` only when the client actually offers it, and fail the TLS handshake for an ALPN-bearing client with no admitted protocol overlap or a malformed ALPN vector. This deliberately strengthens Pingora 0.9.0's `enable_h2()` convenience behavior to satisfy RFC 7301's fatal `no_application_protocol` requirement on no overlap. h2c is not enabled. HTTP/3/QUIC is not implied by this field and remains unsupported by this contract.
 
-A version-2 source capability is not a complete mixed-protocol parity claim. Supplier `cloudflare/pingora#901` and `#936` continue to gate H2-downstream to H1-upstream Cookie/body-framing correctness until maintainer-integrated, release-qualified identities exist or an alternate deployment contract makes those downgrade paths unreachable.
+A version-2 source capability is not a complete mixed-protocol parity claim. H2-downstream to H1-upstream Cookie correctness remains gated until `cloudflare/pingora#901` is present in a maintainer-integrated, release-qualified supplier identity or an alternate deployment contract makes that downgrade path unreachable. Zero-length body-framing correctness is tracked separately through the open `cloudflare/pingora#936` / `#976` alternatives (or a maintainer successor) and requires the same maintainer-integrated, release-qualified identity or an alternate deployment contract that removes the affected downgrade path. Mutable contributor heads are evidence only, not release authority.
 
 ## Bounded `cwl-pingora-pg-erd-migration`
 

PRD.md

@@ -37,7 +37,7 @@ The HTTPS migration increment SHALL preserve cleartext semantics of earlier Admi
 - preserve product auth/business routing, Keyverse identity and Wardnet/EgressWeave authority boundaries; and
 - prove the admitted path with real TLS sockets and exact-head evidence.
 
-Basic TLS/H2 listener capability is not complete HTTP/2 parity. Issue #51 remains the product acceptance authority for parallel streams, reset/cancellation, GOAWAY/drain, header/body admission, flow control/backpressure, origin failure/recovery, forwarding trust and cutover observability. H2-downstream to H1-upstream Cookie and zero-length body-framing correctness remain gated by release-qualified supplier disposition of `cloudflare/pingora#901` and `#936`.
+Basic TLS/H2 listener capability is not complete HTTP/2 parity. Issue #51 remains the product acceptance authority for parallel streams, reset/cancellation, GOAWAY/drain, header/body admission, flow control/backpressure, origin failure/recovery, forwarding trust and cutover observability. H2-downstream to H1-upstream Cookie correctness remains gated until `cloudflare/pingora#901` is present in a maintainer-integrated, release-qualified supplier identity or an alternate deployment contract makes that downgrade path unreachable. Zero-length body-framing correctness is a separate gate currently represented by open alternatives `cloudflare/pingora#936` and `#976` (or a maintainer successor) and likewise requires a maintainer-integrated, release-qualified supplier identity or an alternate deployment contract that removes the affected downgrade path. Mutable contributor heads are evidence only and must not be treated as release authority.
 
 ## Non-goals
 

README.md

@@ -6,7 +6,7 @@
 
 Pingora Gateway centralizes edge concerns that should not be reimplemented independently by every product: upstream connection handling, bounded transport policy, request-size and in-flight limits, health/readiness, coarse telemetry, and container hardening. It is built on Cloudflare Pingora while exposing its own reviewed configuration contract to consumers instead of leaking Pingora types into product APIs.
 
-> This README describes the current candidate branch. Protected `main` remains shipped authority until this Draft satisfies current review, security, supply-chain, and integration governance.
+> This README describes the current candidate branch. Protected `main` remains shipped authority until the dependency-ordered stack satisfies current review, security, supply-chain, and integration governance.
 
 ## Why it exists
 
@@ -15,13 +15,14 @@ Shared infrastructure is useful only when it reduces duplication **without absor
 | Need | What the current gateway provides |
 | --- | --- |
 | Edge runtime | Executable Rust/Pingora reverse-proxy path |
-| Explicit upstream | One reviewed HTTP or HTTPS upstream in the v1 configuration contract |
+| Explicit upstream | One reviewed HTTP or HTTPS upstream in the generic v1/v2 configuration contract |
+| Downstream transport | Cleartext generic v1 plus opt-in generic v2 TLS with `h2_http1` ALPN; bounded pg-erd v3 uses the same TLS/H2 boundary |
 | Bounded I/O | Connect/read/write/idle, request-body, process in-flight, and upstream keepalive-pool budgets |
 | Backpressure | Fail-fast HTTP 503 when the configured non-health in-flight budget is exhausted; health remains observable |
 | Forwarding safety | Distrust of client-supplied forwarding identity and hop-by-hop header policy |
 | Operations | `/livez`, `/readyz`, low-cardinality Prometheus metrics, and coarse credential-safe access logs |
 | Container boundary | Non-root runtime, read-only-root compatibility, dropped Linux capabilities, and `no-new-privileges` contract |
-| Reproducibility | Locked Rust dependency graph and immutable Pingora git revision |
+| Reproducibility | Locked Rust dependency graph and exact Pingora `0.9.0` registry dependencies |
 
 ## Product boundary
 
@@ -44,7 +45,7 @@ Pingora Gateway does **not** own product authentication, tenant/business routing
 
 ## Quickstart
 
-The current crate is `cwl-pingora-gateway` `0.1.0`, requires Rust 1.98.0, and pins Pingora `0.8.0` to an immutable upstream revision.
+The current crate is `cwl-pingora-gateway` `0.1.0`, declares Rust 1.98.0 as its branch MSRV, and uses exact registry dependencies `pingora = 0.9.0` and `pingora-prometheus = 0.9.0`. The protected-release promotion graph separately requires the Rust 1.98.1 compiler foundation before release evidence can be credited.
 
 Copy the example configuration, point the single upstream at a service you control, choose explicit positive `max_in_flight_requests` and `upstream_keepalive_pool_size` budgets, and run the gateway:
 
@@ -53,7 +54,9 @@ cp examples/gateway.yaml ./gateway.yaml
 cargo run --locked --bin cwl-pingora-gateway -- --config ./gateway.yaml
 ```
 
-The configuration is fail-closed: unknown fields, unsupported versions, listener collisions, zero body/concurrency/keepalive budgets or timeouts, multiple v1 upstreams, and incomplete TLS identity are rejected rather than normalized into a guessed configuration.
+The configuration is fail-closed: unknown fields, unsupported versions, listener collisions, zero body/concurrency/keepalive budgets or timeouts, multiple generic upstreams, and invalid or incomplete TLS declarations are rejected rather than normalized into a guessed configuration.
+
+Generic version 1 is cleartext. Generic version 2 retains the same one-upstream/runtime invariants and requires downstream certificate-chain/private-key references plus the explicit `h2_http1` ALPN policy. The bounded pg-erd migration profile remains a separate process/configuration root: versions 1 and 2 are cleartext, while version 3 adds the same downstream TLS/H2 boundary. Certificate issuance, renewal, ACME, revocation workflow, backup and private-key custody remain outside this repository.
 
 Check the local process separately for liveness and readiness:
 
@@ -68,10 +71,10 @@ See [`API_CONFIG_CONTRACT.md`](API_CONFIG_CONTRACT.md) for the configuration con
 
 ## Security and traffic behavior
 
-The v1 gateway starts from distrust at the edge:
+The gateway starts from distrust at the edge:
 
 - inbound `Forwarded`, `X-Forwarded-*`, and `X-Real-IP` identity is discarded;
-- the current cleartext downstream listener does not invent a trusted client IP;
+- no current generic version invents a trusted client identity from request headers; TLS-enabled configurations derive `https` from the admitted listener transport rather than hostile forwarding input;
 - hop-by-hop and connection-nominated request headers are removed by the upstream policy;
 - body, in-flight request, upstream keepalive-pool, and upstream-I/O budgets are explicit;
 - metrics use low-cardinality labels and should be exposed only on an access-controlled observability network;
@@ -87,21 +90,23 @@ This is an OCI **build/runtime contract**, not evidence of a published productio
 
 ## Integration maturity
 
-The current v1 surface is intentionally narrow: one traffic listener, one metrics listener, and one upstream. Route tables, product-aware load balancing, WebSocket policy, dynamic reload, downstream TLS termination, ACME, Kubernetes Gateway API, and broader migration parity remain future increments that require a real consumer and executable acceptance evidence.
+The current generic surface remains intentionally narrow: one traffic listener, one metrics listener, and one explicit upstream per process. Generic v1 stays cleartext; generic v2 adds only downstream TLS/H2 transport. The separate pg-erd composition root characterizes its bounded migration routing/HTTP-policy behavior without turning the generic contract into a product route language.
+
+WebSocket/HTTP Upgrade, HTTP/2 Extended CONNECT, h2c, HTTP/3/QUIC, generic load balancing, dynamic reload, ACME/certificate lifecycle, and Kubernetes Gateway API remain separate versioned increments. Complete H2-downstream to H1-upstream parity is also still gated by release-qualified supplier disposition of the tracked Cookie and zero-length body-framing roots; mutable upstream contributor branches are evidence, not dependencies.
 
 Existing Nginx or Traefik use in another repository is not automatically a Pingora migration candidate. Static serving, PHP/FastCGI, certificate management, application routing, and product-specific ingress may belong to other boundaries.
 
 ## Supply-chain and licensing posture
 
-The crate's dependency policy permits a reviewed commercial-friendly set including Apache-2.0, MIT, BSD, ISC, CC0-1.0, OpenSSL, Unicode-3.0, and Zlib families; unknown registries/git sources and wildcard dependencies are denied. Pingora and `pingora-prometheus` are pinned to exact version `0.8.0` plus an immutable Cloudflare git revision.
+The crate's dependency policy permits a reviewed commercial-friendly set including Apache-2.0, MIT, BSD, ISC, CC0-1.0, OpenSSL, Unicode-3.0, and Zlib families; unknown registries/git sources and wildcard dependencies are denied. Pingora and `pingora-prometheus` are exact registry dependencies at `0.9.0`, with the committed `Cargo.lock` defining the resolved candidate graph.
 
-Cloudflare Pingora is Apache-2.0 licensed. This repository's own crate metadata is also Apache-2.0, and the root [`LICENSE`](LICENSE) now carries that grant. Third-party dependencies retain their own license and attribution obligations; the repository license does not replace dependency provenance.
+Cloudflare Pingora is Apache-2.0 licensed. This repository's own crate metadata is also Apache-2.0, and the root [`LICENSE`](LICENSE) carries that grant. Third-party dependencies retain their own license and attribution obligations; the repository license does not replace dependency provenance.
 
-Current supply-chain policy still reports inherited maintenance concerns from the pinned framework rather than relabeling them as vulnerabilities or suppressing real vulnerability/unsoundness findings. See [`deny.toml`](deny.toml) and the current supply-chain workflow for the executable policy.
+Current supply-chain policy still reports inherited maintenance concerns from the framework dependency graph rather than relabeling them as vulnerabilities or suppressing real vulnerability/unsoundness findings. In particular, the current Pingora 0.9.0 graph still carries the separately tracked `derivative 2.2.0 / RUSTSEC-2024-0388` supplier root, so no release-ready dependency claim is made here. See [`deny.toml`](deny.toml) and the current supply-chain workflow for the executable policy.
 
 ## Quality and status
 
-This is a **0.1.0 candidate / Draft** product line, not a released gateway. The branch contains locked format/test/Clippy/doc builds, compiled-binary loopback E2E including saturation/recovery, OCI security acceptance, security/SAST lanes, and explicit supply-chain policy. Public Rust API documentation is a build gate via `#![deny(missing_docs)]` and `RUSTDOCFLAGS="-D warnings"`.
+This is a **0.1.0 candidate**, not a released gateway. The candidate stack contains locked format/test/Clippy/doc builds, compiled-binary traffic E2E including saturation/recovery and TLS/H2 slices, OCI security acceptance, security/SAST lanes, and explicit supply-chain/release-evidence controls. Those successor results do not override unresolved supplier, governance, protected-integration, publication, deployment, or cutover gates. Public Rust API documentation is a build gate via `#![deny(missing_docs)]` and `RUSTDOCFLAGS="-D warnings"`.
 
 Run the core local checks with:
 
@@ -137,4 +142,4 @@ New dependencies must permit commercial use under the intended distribution mode
 
 ## License
 
-Pingora Gateway is licensed under the [Apache License 2.0](LICENSE). Third-party components retain their applicable licenses and attribution terms.
+Pingora Gateway is licensed under the [Apache License 2.0](LICENSE). Third-party components retain their applicable licenses and attribution terms.

docs/index.md

@@ -10,9 +10,11 @@ title: Pingora Gateway
 
 ## Current status
 
-Protected `main` remains shipped authority. The active foundation candidate implements the first executable v1 runtime, but it is still Draft and is not a published release or production cutover.
+Protected `main` remains shipped authority. The active dependency-ordered candidate stack contains the generic Rust/Pingora runtime plus later TLS/H2, migration-characterization, supply-chain and protected-release-evidence increments, but it is not yet protected-integrated, published, deployed or cut over.
 
-The current candidate owns one explicit upstream, bounded transport and request budgets, fail-fast in-flight admission, forwarding-header distrust, `/livez` and `/readyz`, low-cardinality metrics, coarse credential-safe logging, upstream TLS verification, graceful drain, OCI hardening, and locked supply-chain evidence. Product authentication, business routing, certificate issuance, identity, workflow state, and domain-specific retry/failover remain external responsibilities.
+The current candidate owns one explicit generic upstream per process, bounded transport and request budgets, fail-fast in-flight admission, forwarding-header distrust, `/livez` and `/readyz`, low-cardinality metrics, coarse credential-safe logging, verified upstream TLS, opt-in downstream TLS/H2 for the admitted configuration versions, graceful drain, OCI hardening, and locked supply-chain/release-evidence controls. Product authentication, business routing, certificate issuance/lifecycle, identity, workflow state, Wardnet/EgressWeave verdicts, Keyverse authority, and domain-specific retry/failover remain external responsibilities.
+
+The branch dependency contract uses exact registry `pingora = 0.9.0` and `pingora-prometheus = 0.9.0`. That candidate graph still carries the separately tracked `derivative 2.2.0 / RUSTSEC-2024-0388` supplier root, so current successor GREEN evidence is not a release-ready dependency claim. H2-downstream to H1-upstream parity also remains gated by release-qualified supplier disposition of the tracked Cookie and zero-length body-framing roots; mutable upstream contributor branches are evidence only.
 
 ## Start here
 
@@ -23,13 +25,13 @@ The current candidate owns one explicit upstream, bounded transport and request
 - [Releases](https://github.com/ContextualWisdomLab/pingora-gateway/releases) — immutable release evidence when one is published.
 - [Ask DeepWiki](https://deepwiki.com/ContextualWisdomLab/pingora-gateway) — repository-grounded navigation and questions.
 
-Links to candidate-only files may not resolve from `main` until the foundation integrates; the pull request remains the review authority for those bytes meanwhile.
+Links to candidate-only files may not resolve from `main` until the dependency-ordered stack integrates; the pull requests remain the review authority for those bytes meanwhile.
 
 ## License and dependency boundary
 
-Pingora Gateway original source and documentation are Apache-2.0 on the foundation candidate. Cloudflare Pingora is separately Apache-2.0 licensed, and all third-party crates, container bases, copied material, data, and assets retain their own licenses and attribution obligations. The repository license does not replace dependency provenance.
+Pingora Gateway original source and documentation are Apache-2.0 on the candidate stack. Cloudflare Pingora is separately Apache-2.0 licensed, and all third-party crates, container bases, copied material, data, and assets retain their own licenses and attribution obligations. The repository license does not replace dependency provenance.
 
-Current security/supply-chain findings are not waived by the permissive source license. The foundation remains blocked wherever exact-head security or dependency policy fails.
+Current security/supply-chain findings are not waived by the permissive source license. Promotion remains blocked wherever exact-head security, dependency, independent-review, protected-integration or release policy is unsatisfied.
 
 ## Publication truth