Dashboard and app documentation update plan

I want one clear starting point for the dashboards and apps. JASMIN (data.gamb2le.co.uk) is the primary service. Data-ocean keeps its development dashboard and a separate, read-only operational API for app fallback. A client using that fallback does not change which host owns the scientific writers.

This page is the documentation plan and a dated progress record for the 24 October 2026 cleanup. I keep the procedures with their code and link them here, so the portal does not become a second copy of each runbook. The September register remains the historical organisation-wide baseline.

Where each answer belongs

Question	Canonical source and documentation	What I update there
Which host is primary, and what does development serve?	aurora-cloud-infra: production and development	Host roles, public routes and data ownership.
How do I release or recover a dashboard?	Release procedure, failover runbook	Exact presentation and writer revisions, deployment checks and rollback.
What may the apps use when JASMIN is unavailable?	Operational mobile mirror	Dedicated route, manifest role, read-only data paths and acceptance checks.
What do the dashboard and API actually show?	aurora_cloud_dashboard documentation	Data products, endpoint contracts, freshness labels and presentation behaviour.
How do I build and release the iOS app?	aurora-dashboard-ios README, release guide	Default-server migration, fallback, app checks and TestFlight evidence.
How do I build and release the Android app?	aurora-dashboard-android README, parity record, internal testing	Default-server migration, fallback, device checks, signing and Play evidence.
What has actually been deployed and checked?	Dated infrastructure record	Observed service revisions, source/product/mirror times, capacity, gaps and remaining work.
How do those pages reach the website?	Portal publishing guide	Repository includes, the Cloudflare build and a check of the published page.

The published entry point is gamb2le.pages.dev. Source links above deliberately follow main; release evidence below names exact revisions. Live freshness belongs in Operations and dated checks, not in an undated claim that a stream is healthy.

What is done

Completed code and documentation changes are on main. The servers use an exact reviewed release from main; unfinished scientific experiments and their original working checkouts remain recoverable.

Part	Current checkpoint and evidence
Dashboard and API	JASMIN is primary. Release prod-20261024.3 serves revision 1a588513a6f715f2159d0f65c41b857f1ccca9d3 on both hosts and the dedicated mirror. Power, Operations, cameras and development forecasts rendered. A later summary-wording change is on main at ebaf1a3 and is not deployed. Reader release record.
Operational mirror	The separate anonymous API identifies itself as live-mirror, keeps browser links on JASMIN and excludes development forecasts from app fallback. Twelve routes passed; seven actual media objects matched the primary; both Android endpoint contracts passed. Mirror contract and checks.
Infrastructure	Reader isolation, canonical ocean observations, BLE and WXcam repairs, the capacity guards and recovery-bundle preservation are on main. The approved ocean volume increase to 1,200 GiB completed at 07:28; 223 GiB was available afterward and all three readers remained active. JASMIN now uses its existing 4,096 GiB share allocation. The reviewed GWS transfer fix is on main at 612151b; its deployment is still pending. Storage and archive record, shared GWS delivery.
iOS	Version 0.13.2 (28) is Testing in the existing four-person internal group, with two installed-build rows. Checks passed: 55 unit tests, nine iPhone UI tests, nine iPad UI tests and live JASMIN checks of the exact released source in Simulator. The signed TestFlight package and Debug Simulator evidence are recorded separately. Build 28 release record.
Android	App changes and signing records are on main. The 45 unit tests, 15 emulator tests and both live endpoint contracts passed. Existing Play ownership, version code 1 and the four-person internal list are verified. Local and hosted signed bundles for version 0.14.0 (5) passed independent package, version and certificate checks. Google's replacement-key activation remains unverified. Signing and release record.
Documentation	The ownership map, app records and publishing guide are on main. The complete local build of the portal and its eight included repositories passed. After the budget was corrected, publication run 40081230695 succeeded at 09:16 UTC. The simplified plan and its linked operational mirror runbook were checked on the public site. Publishing procedure.

The primary and mirror manifests still reported the expected roles and release at 09:59, with matching power and weather sample times. Current stream status belongs in Operations. The ASFS directory-size estimate warning, historical radar gap and Menapia archive-access failure stay visible in the dated evidence; a working dashboard does not clear them.

Work still open

1. Android upload-key reset and release. I approved a replacement upload key for this same app on 24 October because the old password could not be recovered. The old key is preserved. The replacement is saved securely, the four existing CI signing values are configured, and both signed bundles are verified. After the reported reset submission, check Google's confirmation, acceptance and effective date before releasing. Google's app-signing key and existing users stay unchanged. Follow the release procedure and record preparation, reset acceptance, signed bundle, upload and tester availability separately. No new Android beta has been uploaded.
2. iOS installed-device checks. The iPad fixture run and live checks of the exact released source in Simulator have passed. Complete the remaining checks on an installed TestFlight device, including video playback, using the release guide. Controlled routing tests cover fallback and return to primary; no real public-service outage was induced or verified in the live session.
3. Radar capacity and archive acceptance. I want this to work within the existing allocation. The JASMIN share now uses all 4,096 GiB already allocated to the tenant, gaining 96 GiB without a quota increase. The proposed quota request was declined and its unsent draft removed. No request was sent. Review the available space across the existing filesystems and continuing growth before choosing the final layout. The reviewed closed-day relocation remains deferred. All five days are staged and verified; the original paths and files remain intact. A reviewed withdrawal tool is on main if those temporary copies need to be removed. A preserved, old ASS mirror is being assessed for a lossless move to the existing root disk instead. The raw GWS timer is temporarily paused while its current transfer drains for the reviewed shared-delivery fix; restore its recorded state after deployment. Check actual free space and fresh native backlog after any storage change, allowing for seven future days after that backlog is delivered. Keep native backfill behind its capacity gate and retention behind its separate archive acceptance. The dated archive record owns the detailed evidence; the accepted dashboard and mobile mirror do not clear these gates.
4. Menapia flight-archive access. Resolve the expired credentials through the existing flight source procedure and verify a fresh source-to-archive copy. Current UAS MQTT telemetry is a separate stream and does not show that flight-archive access has recovered.

Checks I repeat for later releases

For later changes I keep the procedures in their owning repositories and repeat the relevant evidence:

• Merge the code and its documentation into main. For a presentation release, record the exact old/new reader revisions and scientific writer revision in the infrastructure record. Check the manifest, a rendered browser view, representative media and source/product ages; retain any gaps.
• Recheck the operational mirror contract after a relevant server change: schema, role, data, media and lag. Keep development forecasts outside automatic operational fallback and archive acceptance separate.
• Follow each app's release guide and record source/tag, version/build, artifact digest, upload, processing, tester availability and functional checks as separate facts.
• Follow the publishing guide, confirm the strict production build succeeds, then open the changed public page and one linked runbook. Update this dated plan after a release milestone; keep the detailed deployment evidence with its code.

For this documentation pass, the portal source rollback point is the annotated tag rollback-primary-docs-matrix-20261024. It preserves the page sources, not server configuration or observation data.