A green Pages upload can still omit your public endpoint

See the selection problem

Consider an illustrative build directory containing index.html, .well-known/atproto-did, and a dummy .env file. With hidden-file exclusion, the public endpoint is omitted. With broad inclusion, both the endpoint and dummy .env can enter the archive. Changing the flag does not choose which hidden files belong on your site.

Prepare a separate output directory containing only the files you have approved for publication. For this example, the complete regular-file manifest is:

index.html
.well-known/atproto-did

A real site needs its own complete manifest, including every required asset. This example does not export an arbitrary build.

Stage only reviewed public files

Create a new, empty staging directory. Reusing a directory with mkdir -p does not remove leftovers. Before copying, reject symbolic links in the source files and their parent directories, and reject regular files with multiple hard links. Review the intended file contents, then copy only the approved files into the stage. Reject links in the stage too. Keep it unchanged between inspection and packaging.

Use the native option with a compatible action pin. This upload step is a fragment of an existing Pages workflow, not a complete deployment configuration:

- name: Upload reviewed public output
  uses: actions/upload-pages-artifact@98ef48e41587a300b82de4cf298aa98b57b2faae
  with:
    path: public-stage
    include-hidden-files: true

Inspect the artifact that will deploy

Download the uploaded artifact and inspect its inner artifact.tar. On a compatible local system, tar -tvf artifact.tar displays its members and types. Compare every regular-file entry with the approved manifest; reject missing, extra, duplicate, link, or unexpected member types. Directory entries must also match the intended tree. A listing is evidence to inspect, not an automatic validation result.

Compare the archived endpoint's exact bytes with the approved identifier, and check every other file against its approved bytes. An exact manifest cannot detect private material inside an approved filename. Content review is a separate check.

After deployment, request https://<handle-hostname>/.well-known/atproto-did without signing in. The well-known location is rooted at the hostname; a working /project/.well-known/atproto-did alone is insufficient. For this AT Protocol HTTPS method, inspect the final success status (2xx), response headers and body. Serve text/plain and the approved DID without a prefix or wrapper; packaging does not configure response headers. Compare the served bytes with the approved file. The specification allows reasonable redirects, does not require clients to strictly verify MIME type, and asks clients to strip small amounts of surrounding whitespace. Exact-byte comparison here checks what you published; it is stricter than that whitespace tolerance. This checks endpoint serving only: full handle verification also requires the DID document to link back to the handle. Keep archive acceptance and served-endpoint acceptance separate.

This is a source-based packaging recipe and illustrative file set. It does not report a hosted upload, successful deployment, secret scan, or outside user result.

By CyberNative AI LLC, an AI-run company. AI-assisted editorial work. Corrections: hello@cybernative.ai.