docs: publish and verify the GitHub Pages buyer surface

[seonghobae]

Finding

Fresh repository metadata on 2026-09-12 still reports has_pages: false, while docs/index.md is maintained as the buyer-facing Pages source and the product-development contract requires GitHub.io publication to be verified rather than inferred from checked-in Markdown.

The source/workflow half remains PR #98. Earlier repaired exacts proved direct HTTPS transport, zero redirects, real curl success, exact HTTP 200, source-SHA marker equality, and rendered-root digest verification. Fresh review found one more evidence-integrity gap in exact 2780f08f53c36f7f367a043b1097e13449552596: the verifier fetched public index-sha256.txt and then treated that public value as the expected digest. A cache-skewed state with a fresh source-sha.txt but stale index-sha256.txt plus matching stale / could therefore satisfy the predicate.

Current #98 exact is 0342fbda2c0e4f97d412d12d4a025fdffd46b599. Test-first 352c39c441e204c1a7ce15821b58e93bc49f1a67 requires build-origin digest authority; 95084621c54fae4f707969b8e3a868066bcbf082 computes the exact rendered _site/index.html digest, writes it into the Pages artifact, exports the same value as a build-job output, and passes it through the workflow DAG to deploy; 0342fbda2c0e4f97d412d12d4a025fdffd46b599 records the RCA and recovery boundary. Public index-sha256.txt must now equal that trusted build-origin value, and the fetched root bytes must hash to the same value. The public site is no longer allowed to define its own expected digest.

A checked-in workflow—even after source repair—is not publication evidence. The repository itself still has Pages disabled, protected main has not admitted #98, no protected-main Pages deployment has run, and no public GitHub.io source/root identity has been verified.

Boundary

This is documentation/publication authority only. Do not claim protected integration, immutable product release, gateway deployment or edge cutover merely because Pages is published. Do not publish mutable PR-head content as a released product state. Dedicated source writers retain their lanes; the Pages workflow is a normal reviewed source change and may publish only an admitted protected revision.

Acceptance

• Preserve GitHub Actions publication from an admitted protected main revision with exact source-SHA and rendered-root binding unless a reviewed successor explicitly supersedes it.
• Integrate the Pages source/workflow through normal dependency-ordered protected governance; do not transfer predecessor/head GREEN or review credit across movement.
• Enable GitHub Actions as the repository Pages publishing source through the correct repository-owner/admin path.
• Publish docs/index.md from an admitted protected revision and record the deployment/source SHA.
• Fetch the returned deployment URL directly over HTTPS. /source-sha.txt, /index-sha256.txt, and the root must each complete successfully with exact HTTP 200; redirects are not accepted as publication evidence.
• Require marker body == protected source SHA, build-origin root digest syntax == 64 lowercase hex, public digest body == build-origin digest, and SHA-256 of the fetched root bytes == that same build-origin digest.
• Keep candidate/open-PR documentation clearly distinct from protected/released/cutover claims.
• Preserve the recovery model: a bad documentation deployment is recovered by a reviewed forward/revert commit on protected history and a new protected-source deployment, not by publishing an arbitrary PR head.

Current evidence

• Repository metadata: has_pages: false on the fresh 2026-09-12 read.
• Current protected main: f8b4c99b8e5d3de79af1ff0c00c0c8fd63b52991.
• docs: add protected GitHub Pages publication lane #98: exact 0342fbda2c0e4f97d412d12d4a025fdffd46b599, open/Ready/mergeable. Exact-head CI 34680605405, Supply Chain 34680605333, Release Reproducibility 34680605311, PgErd bounded-origin capacity 34680605316, and TLS H2 Performance 34680605315 are all terminal success. Exact-current technical review 5185751327 found no further writer-safe defect and review threads are empty.
• No independent APPROVED exists for the current exact.
• Buyer-facing documentation corrections remain staged in docs: make protocol and buyer-facing claims current #93; deeper Pingora traceability remains staged separately in docs: revalidate Pingora 0.9.0 traceability #96. None is protected publication evidence yet.
• Public repository description remains stale (repository is a scaffold only, no implementation yet); repo metadata: replace stale scaffold-only public description #94 remains the separate repository-metadata admin owner path.

Keep this issue open until repository-owner enablement, dependency-ordered protected integration, actual protected-source deployment, and public direct-response source plus build-origin rendered-root identity verification all exist.

[seonghobae]

Source/workflow half is now technically closed for independent review in PR #98 at exact db93bb100faa37da1525f1dc0d6e246c7286b8ef, based on #93 exact 175b831895a58791c5243778c508b17c25f14e46.

The earlier exact 891156096cff7692694aab74afe5036025c4863f reached all five writer-owned gates GREEN, but deeper review found a real publication-evidence integrity defect before protected integration: the workflow checked that the initial Pages page_url started with HTTPS, then used unconstrained curl --location. Hostile characterization proved an HTTPS endpoint could redirect /source-sha.txt to HTTP and the historical command would accept the expected marker. #98 was returned to Draft; the ordinary-forward repair now constrains both public requests and every redirect to HTTPS with --proto '=https' --proto-redir '=https', structural tests require those controls on both requests, and TRACEABILITY records the downgrade RCA.

No predecessor evidence was transferred. Current exact independently completed CI 34670282108, Supply Chain 34670282112, TLS H2 Performance 34670282095, PgErd bounded-origin capacity 34670282140, and Release Reproducibility 34670282161 with terminal success. Exact-current technical COMMENT review 5185049147 found no further writer-safe defect and review threads are empty. #98 is therefore Ready for independent review; this is not an independent APPROVED review or protected integration.

Repository metadata still reports has_pages:false. Exact actions/configure-pages@45bfe0192ca1faeb007ade9deae92b16b8254a0d keeps enablement=false by default and documents that enablement requires a non-GITHUB_TOKEN credential with administration+Pages write authority for a GitHub App. This issue remains open until repository-owner administration enables GitHub Actions as the Pages source, #98 is dependency-ordered into protected main, the manual protected-main deployment succeeds, and the public HTTPS /source-sha.txt value is verified against that protected source SHA. No product release/deployment/cutover credit follows from Pages publication.

[seonghobae]

Owner/admin step executed on 2026-09-13: GitHub Pages was enabled for this repository with GitHub Actions as the publishing source.

POST /repos/ContextualWisdomLab/pingora-gateway/pages  {"build_type":"workflow"}
GET  /repos/ContextualWisdomLab/pingora-gateway/pages  → build_type=workflow, html_url=https://contextualwisdomlab.github.io/pingora-gateway/, https_enforced=true, status=null

What this does and does not prove:

• It only removes the has_pages: false admin blocker. No deployment has run: protected main@f8b4c99 carries no Pages workflow, so status is null and the site URL serves nothing yet.
• Publication evidence still requires docs: add protected GitHub Pages publication lane #98's workflow to be admitted on protected main through normal dependency-ordered governance, a protected-source deployment run, and the direct-HTTPS 200 checks on /source-sha.txt, /index-sha256.txt and / with build-origin digest equality exactly as listed in the acceptance above.
• Nothing here transfers GREEN or review credit to docs: add protected GitHub Pages publication lane #98 or claims release/cutover state.

Remaining acceptance items stay open on this issue; the stack writer keeps ownership of #98.