Rename PANGOLIN_ACCESS_TOKEN_* to SITE_AUTH_TOKEN_*

.github/workflows/deploy-site.yml

@@ -62,10 +62,9 @@ jobs:
       environment: ${{ inputs.environment }}
     permissions:
       contents: read
-    # Cross-repo, so secrets: inherit does not apply, and the names differ from what this repo stores.
-    # PANGOLIN_ACCESS_TOKEN_ID/PANGOLIN_ACCESS_TOKEN forward as the hub task's generic SITE_AUTH_TOKEN_ID/SITE_AUTH_TOKEN.
-    # Production maps both to empty, since neither secret is set there, which the hub task's own assert step treats as a public site.
+    # Cross-repo, so secrets: inherit does not apply.
+    # Production maps both auth-token secrets to empty, since neither is set there, which the hub task's own assert step treats as a public site.
     secrets:
       DEPLOY_SSH_PRIVATE_KEY: ${{ secrets.DEPLOY_SSH_PRIVATE_KEY }}
-      SITE_AUTH_TOKEN_ID: ${{ secrets.PANGOLIN_ACCESS_TOKEN_ID }}
-      SITE_AUTH_TOKEN: ${{ secrets.PANGOLIN_ACCESS_TOKEN }}
+      SITE_AUTH_TOKEN_ID: ${{ secrets.SITE_AUTH_TOKEN_ID }}
+      SITE_AUTH_TOKEN: ${{ secrets.SITE_AUTH_TOKEN }}

ENVIRONMENT.md

@@ -69,8 +69,8 @@ Held on the `production` and `staging` environments. The deploy workflow reads n
 | `DEPLOY_SSH_USER` | variable | the confined deploy account |
 | `DEPLOY_SSH_KNOWN_HOSTS` | variable | the pinned host key. A variable rather than a secret, deliberately, since it is public by nature |
 | `DEPLOY_SSH_PRIVATE_KEY` | secret | the deploy key, held behind an `rrsync` forced command |
-| `PANGOLIN_ACCESS_TOKEN_ID` | secret | as above, for an environment behind the gate |
-| `PANGOLIN_ACCESS_TOKEN` | secret | as above |
+| `SITE_AUTH_TOKEN_ID` | secret | as above, for an environment behind the gate. `.github/actions/deploy/action.yml` reads it as `PANGOLIN_ACCESS_TOKEN_ID` for `check-live-urls.sh` |
+| `SITE_AUTH_TOKEN` | secret | as above, bridged to `PANGOLIN_ACCESS_TOKEN` the same way |
 
 **`SITE_BASE_URL` being read twice is the trap worth knowing.** A wrong value bakes the wrong address into every canonical tag and then runs the full URL contract against that same wrong address, so the deploy verifies itself and passes. Its generic name is the hub's own `deploy-site-task.yml` interface, since that task is not Hugo-specific. Blog's own scripts and `OPERATIONS.md` keep reading `HUGO_BASEURL`, which the deploy hook bridges from `SITE_BASE_URL` in one place.
 

TODO.md

@@ -195,7 +195,7 @@ Secrets and variables, per environment. The App-token pair is repository-scoped
 | `DEPLOY_SSH_PRIVATE_KEY` | secret |
 | `DEPLOY_SSH_HOST`, `DEPLOY_SSH_USER`, `DEPLOY_SSH_KNOWN_HOSTS` | variable |
 | `SITE_BASE_URL` | variable |
-| `PANGOLIN_ACCESS_TOKEN_ID`, `PANGOLIN_ACCESS_TOKEN` | secret, staging only |
+| `SITE_AUTH_TOKEN_ID`, `SITE_AUTH_TOKEN` | secret, staging only |
 | `CODEGEN_APP_CLIENT_ID`, `CODEGEN_APP_PRIVATE_KEY` | secret, both stores |
 
 `DEPLOY_SSH_PRIVATE_KEY` holds the same key in both environments, per the decision above. The environment split still carries the base URL, the SSH endpoint, and the staging-only token pair, so it is not decorative.

spec/secrets.json

@@ -30,13 +30,13 @@
       "DEPLOY_SSH_HOST",
       "DEPLOY_SSH_USER",
       "DEPLOY_SSH_KNOWN_HOSTS",
-      "HUGO_BASEURL"
+      "SITE_BASE_URL"
     ],
     "secretsNote": "The 'secrets' and 'variables' lists are required in every environment named above. 'environmentSecrets' names what one environment carries and another does not, so a name audit does not read a staging-only credential as missing from production. Staging keeps its auth gate on and production answers unauthenticated, so the access token exists on staging alone and checks/check-live-urls.sh sends no credential where the pair is absent.",
     "environmentSecrets": {
       "staging": [
-        "PANGOLIN_ACCESS_TOKEN_ID",
-        "PANGOLIN_ACCESS_TOKEN"
+        "SITE_AUTH_TOKEN_ID",
+        "SITE_AUTH_TOKEN"
       ],
       "production": []
     },