chore(deploy): retire AWS/GCP pipeline; deploy production on release tags

The apex has served from the Cloudflare worker since the 2026-07-08 cutover, so
the nginx image and the AWS ECS / GCP deploy workflows no longer serve anything —
they existed as the rollback path during the soak. Merging this ends that soak:
rollback afterwards means redeploying an older worker version, not repointing at
AWS.

deploy.yml gains the @polygonlabs/meta release-tag trigger, deferred from the
cutover PRs until wrangler owned the domain: production now deploys in lockstep
with the npm publish, so the CDN and the package (two surfaces of one network/
tree) cannot drift. Merging the Version Packages PR is the deliberate
promote-to-prod step; push-to-master still deploys staging and dispatch remains
the escape hatch.

Also collapses the cutover-era comments in wrangler.toml and CLAUDE.md to the
steady state, pointing at the apps-team-ops service-hosting-migration runbook for
the migration process itself.

A root CHANGELOG.md is introduced with this as its 1.0.0 entry, documenting the
endpoint's consumer-visible changes (Cloudflare hosting, real 404s, read-only
CORS surface, cache header, /network/index.js removal).

Author: MaximusHaximus

.github/taskdef/dev-taskdef.yaml

@@ -3,19 +3,23 @@ name: Deploy to Cloudflare
 # Trunk-based deployment. master is the only branch.
 #
 #   - staging:    every push to master (trunk) deploys staging
-#                 (static-cf.polygon.technology, a custom_domain on a fresh
-#                 hostname). Trunk is always deployable, so staging tracks trunk.
-#   - production: workflow_dispatch ONLY, for now. The apex cutover sequence is
-#                 documented in wrangler.toml [env.production]: dispatch once to
-#                 create the worker → land custom_domain → SPEC swaps DNS in the
-#                 CF dashboard → dispatch to verify ownership. The ordering makes
-#                 a stray production dispatch harmless at every step. Once the
-#                 domain is wrangler-owned, re-add a release-tag trigger here so
-#                 prod auto-deploys on each @polygonlabs/meta release.
+#                 (static-staging.polygon.technology). Trunk is always deployable, so
+#                 staging tracks trunk.
+#   - production: the @polygonlabs/meta release tag, pushed by the release bot
+#                 when the Version Packages PR merges, deploys production
+#                 (static.polygon.technology) in lockstep with the npm publish.
+#                 The CDN and the npm package serve the same network/ tree, so
+#                 gating prod on the release keeps them from drifting; merging
+#                 the Version Packages PR is the deliberate promote-to-prod step.
+#                 (The release commit also re-deploys staging — a harmless
+#                 idempotent no-op.)
+#   - dispatch:   manual escape hatch for either env (rollback / re-deploy).
 on:
   push:
     branches:
       - master
+    tags:
+      - '@polygonlabs/meta@*'
   workflow_dispatch:
     inputs:
       environment:
@@ -50,12 +54,32 @@ jobs:
 
       - run: pnpm install --frozen-lockfile
 
-      # dispatch → chosen env; a push to master → staging.
-      - run: >
-          pnpm exec wrangler deploy --env ${{
-            github.event_name == 'workflow_dispatch' && github.event.inputs.environment
-            || 'staging'
-          }}
+      # dispatch → chosen env; a tag push → production; a push to master → staging.
+      # Deliberately plain bash rather than a ${{ }} ternary chain: GitHub
+      # expression short-circuiting silently falls through when a middle operand
+      # is falsy (e.g. an empty dispatch input), and shell if/else has no such
+      # trap. Anything unexpected exits 1 instead of deploying somewhere.
+      - name: Resolve target environment
+        id: target
+        env:
+          DISPATCH_ENV: ${{ github.event.inputs.environment }}
+        run: |
+          if [ "$GITHUB_EVENT_NAME" = "workflow_dispatch" ]; then
+            case "$DISPATCH_ENV" in
+              staging|production) ENV="$DISPATCH_ENV" ;;
+              *) echo "Unexpected dispatch environment: '$DISPATCH_ENV'" >&2; exit 1 ;;
+            esac
+          elif [ "$GITHUB_REF_TYPE" = "tag" ]; then
+            ENV="production"
+          elif [ "$GITHUB_REF" = "refs/heads/master" ]; then
+            ENV="staging"
+          else
+            echo "Unexpected ref for deploy: $GITHUB_REF ($GITHUB_REF_TYPE)" >&2; exit 1
+          fi
+          echo "resolved: $GITHUB_EVENT_NAME $GITHUB_REF -> $ENV"
+          echo "environment=$ENV" >> "$GITHUB_OUTPUT"
+
+      - run: pnpm exec wrangler deploy --env ${{ steps.target.outputs.environment }}
         env:
           CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CF_WORKER_ACCOUNT_ID }}
           CLOUDFLARE_API_TOKEN: ${{ secrets.CF_WORKER_API_TOKEN }}

.github/taskdef/prod-taskdef.yaml

@@ -0,0 +1,38 @@
+# Changelog
+
+Repo-level changelog for the `static.polygon.technology` HTTP endpoint and the
+repository's tooling. The `@polygonlabs/meta` npm package has its own
+changesets-managed changelog at
+[`packages/meta/CHANGELOG.md`](./packages/meta/CHANGELOG.md).
+
+## 1.0.0 — 2026-07-08
+
+First changelog entry, marking the endpoint's move to Cloudflare.
+
+### Changed
+
+- `static.polygon.technology` is now served from Cloudflare Workers static
+  assets. The nginx Docker image and its AWS ECS / GCP deploy pipelines are
+  removed (`Dockerfile`, `nginx.conf`, `deployment.yml`, `build_and_deploy.yml`,
+  `deployment_gcp.yml`, `.github/taskdef/`). The image was internal deploy
+  tooling only — it was never published to a public registry. Self-hosting the
+  content needs nothing more than a static file server pointed at `network/`;
+  the retired nginx setup remains available in git history.
+- Deployment is trunk-based via `wrangler` (`.github/workflows/deploy.yml`):
+  pushes to `master` deploy staging (`static-staging.polygon.technology`), and
+  `@polygonlabs/meta` release tags deploy production, in lockstep with the npm
+  publish.
+- Missing paths now return a real `404`. The retired nginx config served the
+  health-check HTML page with `200` for any unknown path.
+- CORS advertises the endpoint's actual read-only surface:
+  `Access-Control-Allow-Methods: GET, OPTIONS` (previously also `POST`, plus
+  `Authorization`/`Content-Type` allow-headers for a write/auth surface that
+  never existed).
+- Responses now carry `Cache-Control: public, max-age=300`.
+
+### Removed
+
+- `/network/index.js` (a CommonJS `Network` class predating the
+  `@maticnetwork/meta` 2.x package split) is no longer served. Use the
+  [`@polygonlabs/meta`](./packages/meta/) npm package for typed access, or
+  fetch the JSON tree directly.

.github/taskdef/staging-taskdef.yaml

@@ -30,27 +30,30 @@ Two public surfaces driven from one source JSON tree at the repo-root
    live in `public/_headers`.
 
    `deploy.yml` is trunk-based: every push to `master` deploys
-   **staging** (`static-cf.polygon.technology`, a `custom_domain` on a
-   fresh hostname, where wrangler can create the DNS record itself).
-   **Production** is `workflow_dispatch`-only. The apex cannot be bound
-   from CI while its externally-managed record exists — `custom_domain`
-   fails with Cloudflare error 100117, our CI token lacks
-   `Zone:DNS:Edit` to override, and zone routes fail likewise (SPEC has
-   tried) — so the cutover is the four-step process documented in
-   `wrangler.toml` `[env.production]`: dispatch to create the worker,
-   land `custom_domain = true`, SPEC swaps the DNS record onto the
-   worker in the CF dashboard (zero downtime), dispatch to verify
-   wrangler owns the domain. The ordering makes a stray production
-   dispatch harmless at every step. Once ownership is verified, a
-   release-tag trigger can be re-added so prod auto-deploys on each
-   `@polygonlabs/meta` release. See the apps-team-ops
-   Cloudflare-migration runbook for the full rationale.
-
-   The legacy nginx-on-ECS origin (`Dockerfile`, `nginx.conf`,
-   `deployment.yml`, `build_and_deploy.yml`) and the staged GCP path
-   (`deployment_gcp.yml`) are kept as rollback until the apex DNS is
-   cut over to Cloudflare, then removed in a follow-up PR. The apex DNS
-   cutover and the AWS/GCP teardown are manual infra steps.
+   **staging** (`static-staging.polygon.technology`); the `@polygonlabs/meta`
+   release tag (pushed by the release bot when the Version Packages PR
+   merges) deploys **production** (`static.polygon.technology`) in
+   lockstep with the npm publish — merging that PR is the deliberate
+   promote-to-prod step, and gating prod on the release keeps the CDN
+   and the npm package (two surfaces of one `network/` tree) from
+   drifting. `workflow_dispatch` is the manual escape hatch for either
+   environment.
+
+   If this hostname (or any live hostname) ever needs to move to a
+   different host, follow the apps-team-ops `service-hosting-migration`
+   runbook — wrangler cannot bind a hostname whose DNS record already
+   exists elsewhere, and the working process is documented there.
+
+## Changelog
+
+Maintain the root [`CHANGELOG.md`](./CHANGELOG.md) whenever a change
+fundamentally alters the repository's capabilities — what the running
+service serves or how (endpoint behaviour, status codes, headers, paths
+added/removed), the API surface consumers depend on, or the deployment/
+hosting mechanism that drives the static site. It is hand-maintained and
+scoped to the repo/HTTP endpoint; routine content updates under
+`network/` don't need an entry, and `packages/meta` has its own
+changesets-managed changelog.
 
 ## Codegen flow