# Cycle 2 Step 16 — Deferred deploy + manual revocations

**Created**: 2026-05-12T01:44:00Z (autodev Step 16, planning-only outcome)
**Cycle**: 2

This file tracks deploy-related work that could not complete this cycle because each
item depends on action outside this workspace.

---

## L-AZ-498-DEPLOY — UI tile-swap prod cutover (cross-workspace gate)

**What is blocked**: prod deploy of the UI changes from cycle 2 batch 11 that route
the map's `<TileLayer>` through the suite's own `satellite-provider` (`/tiles/{z}/{x}/{y}`)
with same-origin cookie auth. The image will build cleanly today (the source change is in
`dev`), but cutting prod traffic over before satellite-provider's auth migration lands
will break the map for all users.

**Cross-workspace prerequisite**: a separate AZAION ticket on the **satellite-provider**
workspace must publish a cookie-auth variant of `GET /tiles/{z}/{x}/{y}` AND deploy that
change to all environments the UI is promoted into (dev / stage / prod). Today the UI
sets `crossOrigin="use-credentials"` on tile images, but the server still expects an
`Authorization: Bearer ...` header (which Leaflet `<img>` requests cannot send).

**Replay procedure** (run at the start of the next cycle's Step 16, or sooner on user
request):

1. Verify the satellite-provider workspace has merged the cookie-auth change to dev,
   stage, and main equivalents.
2. Verify the satellite-provider deploys are live in each environment (smoke check:
   `curl --cookie ... https://<host>/tiles/0/0/0` returns 200 with `Content-Type: image/jpeg`).
3. Run the UI tile-render smoke check: `bunx playwright test e2e/tests/infrastructure.e2e.ts -g "tile"`
   against each environment.
4. Build + push the UI image (the Woodpecker pipeline already does this on every `dev`
   push; cycle 2 commit `f7dd6c9` is on `dev` as of 2026-05-12).
5. Promote: `dev → stage → main` per the standard branch model
   (`_docs/02_document/deployment/ci_cd_pipeline.md` §1).
6. Post-deploy verification: load `/flights` on each environment, pan the map, watch
   network panel — every `/tiles/...` request returns 200 and the request is sent with
   the auth cookie attached.

**Escalation**: if the satellite-provider ticket is still not landed by the next cycle's
Step 16 review, surface to the user via Choose A/B/C/D — the gate cannot be silently
bypassed because doing so produces a visibly broken map in production.

---

## L-AZ-499-OWM-REVOKE — OpenWeatherMap key revocation

**What is blocked**: closing AZ-499 acceptance criterion AC-7 (and the equivalent
project-wide AC-42), which requires the OWM key `335799082893fad97fa36118b131f919`
that was previously committed to the repo to be revoked at the OWM dashboard.

**Why this can't be done from this workspace**: revocation requires authenticated
access to `https://home.openweathermap.org/api_keys` — a third-party UI that cannot
be automated from CI without storing OWM credentials, which is out of scope.

**Replay procedure** (manual, requires user):

1. Sign into `https://home.openweathermap.org/api_keys`.
2. Locate the key `335799082893fad97fa36118b131f919`.
3. Disable / regenerate / delete it. Capture evidence: dashboard screenshot OR a
   timestamped URL showing the key is no longer active.
4. Attach the evidence to Jira ticket **AZ-499** (or to the parent epic if the user
   prefers).
5. Transition AZ-499 to **Done** in Jira.
6. Delete this leftover entry once steps 1–5 are complete.

**Compensating control already in place**: `STC-SEC1C` (in `scripts/check-banned-deps.mjs`
+ `tests/security/banned-deps.json`) prevents the literal value from re-entering the
source tree.

---

## L-AZ-501-GOOGLE-REVOKE — Google Geocode key revocation

**What is blocked**: closing AZ-501 acceptance criterion AC-6 (and the project-wide
AC-43), which requires the Google Geocode key `AIzaSyAhvDeYukuyWVrQYbRhuv91bsi_jj5_Iys`
that was previously committed in `mission-planner/src/config.ts` to be revoked at the
Google Cloud Console.

**Why this can't be done from this workspace**: same reason as AZ-499 — revocation
requires authenticated access to `https://console.cloud.google.com/google/maps-apis/credentials`,
which cannot be automated.

**Replay procedure** (manual, requires user):

1. Sign into `https://console.cloud.google.com/google/maps-apis/credentials`.
2. Locate the key `AIzaSyAhvDeYukuyWVrQYbRhuv91bsi_jj5_Iys`.
3. Restrict the key to no APIs / no referrers (effectively revoke) OR regenerate it.
   Capture evidence: dashboard screenshot OR a timestamped URL showing the
   restriction.
4. Attach the evidence to Jira ticket **AZ-501**.
5. Transition AZ-501 to **Done** in Jira.
6. Delete this leftover entry once steps 1–5 are complete.

**Compensating control already in place**: `STC-SEC1D` (registered in `scripts/run-tests.sh`
under `run_static`, with the literal in `tests/security/banned-deps.json` →
`google_key_in_source`) prevents the literal value from re-entering the source tree.