Password-protect HTML publishing by default

• Add an auth-worker source asset under html-page/assets/; have deploy.sh copy it to ~/.claude/html-plans/_worker.js before every deployment.
• Generate a route-policy map for every archived HTML page. Each canonical path is either public or carries a salted password verifier; the index resources have a hard-coded public policy.
• Parse Basic authorization defensively using the fixed username page. Verify per-page passwords against a salted verifier, compare fixed-length digests, and never log credentials or authorization headers. Generated passwords carry high entropy; user-supplied weak passwords remain weak.
• Return 401 with WWW-Authenticate: Basic and a short plain-text body showing curl --user "page:PASSWORD" URL, plus the interactive alternative curl --user page URL. Use a distinct realm derived from the page path so browsers do not confuse different pages’ cached credentials.
• Normalize paths using new URL(request.url).pathname and cover both the source .html path and Pages’ extensionless canonical URL. Do not use substring or suffix allowlists.
• Forward authorized requests with env.ASSETS.fetch(request), then clone protected responses with private, no-store caching headers.
• Add local tests for public index/manifest, an explicitly public page, generated and supplied page passwords, wrong credentials, missing registry entries, GET/HEAD, encoded-path attempts, and unknown paths.

• Document the same input contract in html-page, html-plan, and html-handoff: password=<value> sets the human password; password= requests a new random password; access=public disables password protection for that page. Reject a non-empty password combined with access=public.
• For a new page, omitted password has the same secure default as password=: the script generates a cryptographically random URL-safe password. For an existing page, omitted access arguments preserve its current policy; password= explicitly rotates it to a newly generated password.
• Use explicit deployment flags: --password-file <path>, --random-password, or --public. Never place a password directly in the process command line or environment. The skill passes a supplied value through a mode-0600 temporary file and deletes that file after registration.
• Maintain ~/.config/html-page/auth.json under a mode-0700 directory with mode-0600 permissions. It records each canonical URL’s access mode and human password so generated passwords can be recovered and policies can be rebuilt.
• Any agent with only URL + password can run curl --user "page:PASSWORD" URL. The unauthenticated 401 response advertises that contract so an unfamiliar agent can discover it. When process visibility matters, curl --user page URL prompts for the password instead.
• Return a compact share capsule after deployment containing only the canonical URL, ACCESS=protected|public, and password when protected; the fixed username is discoverable from the 401 response. For a generated password, show it once and state that it is also stored in the restricted origin registry. A public capsule contains no password.
• Treat the page password as the intentional capability being shared with the reader. Require a separately generated password per page by default, warn against reusing personal passwords or one password across pages, and reject accidental reuse of a generated password.
• The publishing workflow must not store plaintext credentials in skill files, the HTML archive, pages.json, Git, its own process arguments, or deployment logs. A receiving agent may deliberately use the direct curl --user "page:PASSWORD" interoperability form.

# Works on any computer with only the link and password
curl --fail-with-body --user "page:PASSWORD" \
  https://miro-plans-xps13.pages.dev/pages/some-page

# Alternative: curl prompts for the password instead of putting it in argv
curl --fail-with-body --user page \
  https://miro-plans-xps13.pages.dev/pages/some-page

• Update deploy.sh to register or preserve the target page’s access policy, generate the worker/map before build-index.sh, refuse deployment when the registry is absent or invalid, and keep public index generation unchanged.
• Generate a _routes.json that excludes only the intentionally public index resources from Function invocation and includes every other path. Set each Pages project’s quota behavior to fail closed; Cloudflare warns that fail-open mode can serve static assets when the Functions quota is exhausted.
• Replace the current unconditional 200 check with policy-aware checks: index is 200; protected page is 401 without credentials and 200 with its password; public page is 200 without credentials.
• Disable the ngrok fallback once protected publishing becomes the default. Restoring it with equivalent authentication is deferred until Miro actually needs that fallback.
• Update the skills so random protection is the default, access=public is the explicit per-page opt-out, titles remain public, and agent handoff includes the standard curl command. Changing an existing protected page to public must be reported prominently with the final URL.

1. Build an access-policy entry with a distinct generated password for every existing page before deploying the worker. Store the passwords in the restricted registry.
2. Deploy to one project first. Test its canonical URL and deployment-specific alias: index and manifest public; protected bodies 401; deliberately public bodies 200; browser login and direct Basic-Auth curl both work.
3. Inventory older deployment and branch aliases once. Replace any undeletable branch-head deployment with a gated version, then—after explicit approval—delete superseded unauthenticated deployments. Cloudflare keeps preview aliases reachable and does not allow deleting the latest deployment for a branch.
4. Document that password rotation and public→protected revocation apply immediately to the current deployment only. When historical deployment URLs matter, remove or independently gate every older deployment carrying the superseded policy before declaring revocation complete.
5. Allow rollback only to a deployment that contains the authentication gate and an acceptable access-policy map. A pre-auth or superseded-public deployment is not a valid rollback target.
6. After the desktop project is proven, treat XPS13 and battlebox as a separate fleet-rollout decision. The public combined index may continue listing those sites during the pilot; do not claim their page bodies are protected until separately verified.

Migration references: persistent preview aliases, branch-head deletion restriction, delete a Pages deployment, and Pages rollback behavior.

• defer Capacity report, 80% alerts, and automated age/count cleanup. Manual inspection and Cloudflare’s supported deployment-delete command are enough initially.
• defer Curl wrapper, site-wide bearer credentials, and automatic registry synchronization. Add only if direct URL + per-page password sharing proves insufficient.
• defer Authenticated ngrok fallback and a custom logout endpoint. Keep the fallback disabled and document Basic Auth’s browser logout limitation.
• defer Cloudflare Access migration. Revisit when individual identity, MFA, revocation, or audit logs become requirements.

Capacity model: Cloudflare’s current Free-plan limits are 20,000 files per Pages site, 25 MiB per individual asset, and 500 builds/deploys per month. It documents unlimited active preview deployments and no cumulative byte-storage quota for Pages. This machine’s current archive is 379 files / 67 MB; its largest file is about 9.5 MB. Deleting pages helps the per-site file count; it does not fix the monthly deploy quota or an individual file over 25 MiB. References: Pages limits, automated old-deployment deletion, Functions pricing and Free quota, and Cloudflare Access service tokens.