ui/_docs/_process_leftovers/2026-05-12_az-498-deploy-and-key-revocations.md

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.